Security and Privacy FAQ

Detailed answers to the security questions we hear most often. If your question isn't covered, email contact@tinfoil.sh.

1. Data and privacy

What Tinfoil and our infrastructure providers can and cannot see when you use Chat, the Inference API, or Containers.

Do the chat safeguards mean data can leave the enclave?

One bit per conversation, in Tinfoil Chat only. The only thing that leaves the enclave is a violation flag and the conversation ID, attached to your account. The conversation content and the category of the violation stay inside the enclave. Safeguards apply only to Tinfoil Chat, not the Inference API or Containers. Read more on our safety and safeguards page.

What does Tinfoil actually see when I send a request?

Tinfoil sees the operational data needed to run the Services: account and authentication data, billing information, usage metrics, security logs, deployment and Container metadata, and support communications (see Privacy Policy § 3). For each request, this includes network metadata (source IP, destination IP, packet timing, byte counts), per-request billing metadata (input token count, output token count, model name, timestamp), and, in Tinfoil Chat only, safeguard violation flags (a per-conversation flag plus conversation ID). Tinfoil does not see prompts, completions, uploaded files, embeddings, tool-call payloads, request bodies, response bodies, intermediate inference traces, or error traces containing user content. More broadly, our design principle is that no AI interaction content ever leaves the enclave boundary, so anything derived from your request that isn't explicitly listed as visible to us is by construction not visible to us. Your AI interaction content is processed inside a secure hardware enclave with a decryption key that never leaves the enclave boundary. We also pad streaming responses so that network metadata is independent of plaintext chunk size.

What's the practical privacy difference between Tinfoil and self-hosting on my own hardware?

Both keep the content of your AI interactions out of third-party hands. They differ in who sees network metadata, what the protection relies on, and how much work you take on:

• On-prem: no third party sees anything, not the content and not the network metadata. You own the hardware, the updates, and the model.
• Tinfoil: our infrastructure providers (Cloudflare, AWS, GPU cloud providers, etc.) and Tinfoil itself see network metadata (source IP, packet timing, byte volume, the fact that you are talking to Tinfoil). Content stays inside the enclave and is not visible to us; that protection relies on security features built into AMD, Intel, and NVIDIA chips, whose limits we cover in section 9. You don't run the hardware, and the attestation chain gives you cryptographic assurance that the code and weights being served match what we publish.

Do you retain prompts, completions, uploaded files, or tool-call payloads?

Retention depends on the Service. For the Inference API, we do not retain prompt or response content after the response is returned, apart from temporary prompt caching in encrypted enclave memory. Chat may store encrypted backups of conversations and attachments for sync and history, with backup encryption keys held on your device. Containers are a shared-responsibility service: you control what your workload stores and are responsible for persistence, backup, and recovery.

We also retain Chat safeguard violation flags and conversation IDs for enforcement, not the conversation content from that safeguard process. The safety and safeguards page describes the current state.

Account, billing, usage, security, and support records have separate retention periods. See Privacy Policy § 9 for the retention schedule and legal, tax, security, backup, and other exceptions.

Does prompt caching change what is retained?

Only temporarily, in encrypted enclave memory. Prompt caching keeps the model's internal state for a prompt prefix in the GPU memory of the model enclave that served it, so a later request with the same prefix can skip recomputation. The cache is volatile enclave memory: it is never written to disk, never exported, and does not survive an enclave restart. Entries are evicted under memory pressure, typically within minutes when not reused. Cache entries are only reachable through a namespace derived from your API identity and a client-held user_cache_secret, so other customers cannot observe your cache. See the prompt caching documentation for lifetime and scoping details.

Is Inference API traffic moderated, filtered, or sent to anyone else?

No. API requests are not classified, moderated, or inspected by Tinfoil or any third party. The chat safeguards described above apply only to Tinfoil Chat. The only recipients of your plaintext are the attested router enclave and the attested model enclave it forwards to. The router makes outbound connections only to the Tinfoil control plane (for authentication, configuration, and token-count usage reporting), to model enclaves, and to the public release and certificate sources it needs to verify those enclaves. None of those connections carry request or response content. Optional web search and privacy-filter features are opt-in per request and have their own trust boundaries, described in section 5.

Are prompts or responses ever used for model training, tuning, or service improvement?

No. Inference enclaves never write prompts or responses to disk, and plaintext content does not leave the enclave at any point, so it cannot be used for training, fine-tuning, evaluation, or service improvement even if we wanted to. Where our Data Processing Addendum applies, it also contractually prohibits using AI input or output data to train, fine-tune, or develop models for our own purposes.

What metadata do you retain, and for how long?

The full retention schedule (per-request usage metadata, billing records, account data, IP and request logs (collected and managed by Clerk, our authentication provider), encrypted Chat backups) is documented in Privacy Policy § 9 (Retention and deletion).

Are plaintext contents ever captured in error traces, abuse monitoring, support tooling, or operational logs?

No. There are no debug, support, abuse-monitoring, or operational paths that capture plaintext request or response content. The enclave does not export plaintext to any external system, and this is verifiable in our published source code. Outside the enclave, the iOS app sends anonymized Sentry crash reports limited to crash diagnostics (never conversation content), and our websites use the analytics and advertising tools described in Privacy Policy § 5. None of these receive conversation content.

Tinfoil Chat stores encrypted backups. Who can decrypt them?

Only you. Encrypted Chat backups are stored across TigerData, Cloudflare R2, and AWS S3 buckets so you can sync conversations across devices, but they are encrypted with AES-256 symmetric keys held on your device. AES-256 is considered post-quantum-secure for symmetric encryption, so backup confidentiality does not depend on an assumption that large-scale quantum computers do not exist. Tinfoil does not have these keys and cannot decrypt the backups, including in response to legal process. If you enable passkey recovery, a wrapped, encrypted copy of your key is stored server-side so you can recover on a new device; the raw key is never stored by or accessible to Tinfoil. If you lose access to your device-held backup keys, we cannot recover them either.

Are files I upload treated the same as prompts?

Yes, whether you attach a file in Tinfoil Chat or send it as a file input via the API. The file is sent directly to the enclave and decrypted only inside enclave memory. The file's plaintext is never visible or accessible to Tinfoil or third parties, and never appears in our logs. In Chat, attached files are persisted alongside the conversation as encrypted blobs with keys held on your device, so neither Tinfoil nor our storage providers can read them, including in response to legal process. For the API, uploaded files are processed inside the enclave and not retained after the request completes, apart from temporary prompt caching in encrypted enclave memory.

2. Verification and attestation

How you can independently verify that you are talking to the code and weights we publish, on attested confidential hardware.

How can I verify that a Tinfoil enclave is actually running the code you say it is?

Each time the SDK connects to a Tinfoil enclave, it:

1. Fetches the hardware-signed attestation report from the enclave, which attests to the code running inside it.
2. Verifies the certificate chain of the attestation report back to the CPU vendor's root certificate (e.g., AMD for SEV-SNP).
3. Fetches the corresponding Sigstore bundle that was produced by a GitHub Actions build of our open-source code.
4. Compares the attestation measurements to the Sigstore-published measurements.
5. Opens a TLS session bound to the attested public key.

If any of these checks fail, the SDK refuses to send data. Attestation reflects enclave integrity and configuration at the time of connection. It is not a warranty that the underlying hardware is free of undisclosed vulnerabilities, and it does not replace your own security review (see Terms § 4). The full pipeline is documented in how verification works in Tinfoil and attestation architecture.

How do I know which exact model weights are running?

Attestation doesn't just cover the inference server code. It also covers the exact weights being served. We commit to a cryptographic fingerprint of the weights at build time, bind that fingerprint into the enclave's attestation, and enforce it at runtime so the enclave cannot read any block of weights that doesn't match. For public models, anyone can recompute the fingerprint from the published Hugging Face checkpoint and confirm it matches what the enclave attests to. Read the full design in How Tinfoil Proves Exactly What Model Is Running.

What does verification cover end-to-end?

On every connection, verification covers everything that runs between your request and the model: the boot software and operating system that bring up the enclave, the inference server itself, the exact model weights being served, the GPU being used in confidential compute mode, and the encryption key used to receive your request. If any of these don't match what we publish, the SDK refuses to connect. The full breakdown is in attestation architecture.

Can a middleware or proxy in front of the enclave observe my prompts or silently swap models?

For verified Tinfoil SDK connections, the component between the SDK and the served model is the Tinfoil model router, and the model router itself runs inside an attested enclave. It decrypts your request only inside enclave memory, looks up the model name you asked for in a configuration that is part of the attested measurement, and forwards the request to the corresponding model enclave over a verified channel. Because the model name to weights mapping is part of the attestation, the router cannot silently substitute a different model than the one you requested. The router is open source at confidential-model-router and its measurements are reproducible from source. Verified transport is designed to protect plaintext from intermediaries. This does not cover a third-party client or proxy to which you supply plaintext before it establishes the verified connection.

How can I see which model enclaves the router is actually sending my requests to?

The router publishes its current admitted enclave set at https://inference.tinfoil.sh/.well-known/tinfoil-proxy: for every model, the bound GitHub repository, the verified release tag, the expected measurement, and each enclave hostname with its attestation type and attested keys. Enclaves that failed verification are listed separately and never receive traffic. Every API response also carries a Tinfoil-Enclave header naming the enclave that served it. Because the manifest is served from inside the attested router, you can verify the router first and then treat the manifest as evidence. See inspecting the admitted enclave set.

Do all SDKs enforce the same checks?

All SDKs verify the hardware attestation, the Sigstore provenance of the release, the measurement match, and the binding of the connection keys to the attestation, and all refuse to send data on failure. Audit-time verification with the CLI is available regardless of which SDK your application uses.

How can I independently audit Tinfoil's claims?

Everything security-critical is open source. You can:

• Run the Tinfoil CLI to verify any live enclave endpoint from your terminal (e.g., tinfoil attestation verify) and write machine-readable audit logs.
• Embed the Verification Center in your own application to surface real-time enclave verification status to your users.
• Inspect the open-source code: the confidential VM image, the OVMF firmware, the model router, and our open-source SDKs (Python, JavaScript, Go, Rust, Swift).
• Inspect the per-model configuration repos, which follow the pattern github.com/tinfoilsh/confidential-<model-name> (for example, confidential-deepseek-v4-1-flash, confidential-kimi-k3, confidential-gpt-oss-120b). Each repo pins the exact CVM image, model-weight commitment, and resource configuration that the enclave boots with. The full list of model config repos is linked from each model's page in the model catalog.
• Inspect the confidential-websearch repo for the web search agent that runs inside its own enclave.
• Verify Sigstore bundles for every release through our GitHub organization.
• Run Modelwrap yourself to compute the expected weight commitment and compare it to what the enclave attests to.
• Decode TLS certificates for *.tinfoil.sh in public certificate transparency logs and verify the embedded attestation reports.
• For deeper background, read the secure enclave primer, how verification works in Tinfoil, and the attestation architecture docs.

3. Compelled disclosure and legal

What we could and could not produce under subpoena, court order, or other compelled legal process.

What can Tinfoil hand over if compelled by law enforcement?

We disclose personal data to law enforcement or government authorities only when we have a good-faith belief that disclosure is required by applicable law or legal process. Depending on what we retain, this can include account, billing, usage, security, support, and deployment records, as well as encrypted Chat backups that we cannot decrypt. Our approach to legal requests is documented in Privacy Policy § 7 (Legal requests and government access).

What is cryptographically inaccessible to Tinfoil, even under legal process?

Prompts, completions, uploaded files, embeddings, tool-call payloads, and API request/response bodies are inaccessible. The cryptographic material required to decrypt them never leaves the enclave's hardware boundary. Inference enclaves never write prompts or responses to disk, so there is no stored ciphertext of them that we could hand over either. There are no operational, debug, or support paths that bypass the enclave boundary. The only abuse-monitoring output that crosses it is the Tinfoil Chat safeguard violation flag: one flag and a conversation ID per flagged conversation, never conversation content.

The exception is Tinfoil Chat encrypted backups: we can be compelled to produce the ciphertext, but the encryption keys are held on your device and are not available to us.

Do you have a warrant canary?

No. Our Privacy Policy states how many government requests we had received as of its effective date; it isn't updated in real time.

Will you notify users before disclosing data?

If we are required by law to disclose the information, we will attempt to provide you with prior notice (unless we are prohibited or it would be futile) that a request for your information has been made in order to give you an opportunity to object to the disclosure. We will challenge requests we believe are overbroad or unlawful.

Could you be compelled to push a backdoored model, SDK, or enclave image?

The attestation chain makes a silent backdoor very hard. Every change to the enclave (kernel, firmware, container image, model weights, or config) changes the measurements in the attestation report. Because the expected measurements are produced by GitHub Actions builds of our public repos and committed to the Sigstore transparency log, a malicious enclave image would either fail SDK verification or be visible in the public log. The SDKs themselves are open source and published with cryptographic provenance signed by GitHub Actions, so a coerced SDK release would similarly be visible in the public package attestation log. We detail our defenses in Supply Chain Security - Part 1.

4. Subprocessors and trust boundaries

Who touches what, and where the enclave boundary actually sits.

Which subprocessors can see what data?

Confidential inference is designed to keep plaintext prompts and responses inaccessible to infrastructure providers during normal operation. Other providers process information needed to deliver the Services, such as authentication, billing, usage, support, and website analytics data. Search providers receive search queries, and page-fetch providers receive requested URLs. Provider roles are described in Privacy Policy § 6 (Who we share information with) and the subprocessor list at our Trust Center.

Where are encrypted Chat backups stored, and what does that storage provider see?

Encrypted Chat backups are stored across TigerData, Cloudflare R2, and AWS S3 buckets. They see opaque ciphertext blobs only. Your encryption key is generated on your device and stored only on your devices. Sync traffic passes through an attested sync enclave that uses the key transiently in secure hardware to encrypt your data, and never persists or logs the key. Neither Tinfoil nor the storage provider can decrypt your backups. If you enable passkey recovery, a wrapped, encrypted copy of the key is stored server-side so you can recover on a new device; the raw key is never stored by Tinfoil.

5. Web search, page fetch, and map lookups

Optional web search and page fetch run through secure enclaves in Chat and the API, including our MCP server, but require requests to external providers. Maps in Chat load directly on your device. The enclave boundary protects processing within Tinfoil; it does not make information sent to those providers invisible to them.

What does a web search, page-fetch, or maps provider see?

The current web-search tools send search queries to Exa and retrieve page text through Exa Contents; in Chat, page content may also be retrieved through context.dev, which receives only the requested URL. Search and fetch requests are sent from the enclave over TLS rather than directly from your device, and do not include your Tinfoil account identifier or your device's IP address. Search queries and requested URLs are covered by Zero Data Retention agreements with these providers. Those agreements are a contractual protection, not enclave isolation at the provider. Query text and URLs can themselves contain sensitive information. Maps are different: they load directly from Apple MapKit on your device, so Apple receives the map location and your device's IP address under Apple's privacy policy; Tinfoil never sees the map location. See the current web-search and MCP web-search documentation for the tool behavior and options.

Can these providers identify which user issued a query?

We do not send your Tinfoil account identifier or your device's IP address to the search or page-fetch providers. A shared enclave-held API key helps separate searches from user accounts, but this is not a guarantee of anonymity. A query or URL can identify you through its contents. Maps are the exception: they load directly from Apple MapKit on your device, so Apple receives your IP address along with the map location.

Network metadata and timing correlation can also create privacy risks, particularly if multiple parties combine information. Do not include information in a search query or requested URL that you are unwilling to share with the external provider.

What stops a search query from leaking personal information?

PII filtering can remove detected sensitive identifiers from outgoing search queries, but it is not a guarantee that every sensitive value will be detected or removed. In the API, the filter is opt-in per request. Direct MCP calls use server-configured defaults that callers can override. PII filtering does not apply to fetch URLs, so do not include sensitive values in them. Prompt-injection filtering is a separate control and does not guarantee that returned content is safe. See the filtering documentation for scope and configuration.

Should I use web search if I'm worried about privacy?

Web search and page fetch introduce external recipients that are not present in an inference-only request. If your confidentiality needs do not permit that sharing, do not enable these tools or send requests to the MCP web-search server. Review the data sent to any external integration rather than relying on enclave protection alone.

6. Supply chain and build integrity

How we harden the build, release, and distribution pipeline so attackers cannot quietly inject malicious code.

How do you protect against software supply chain attacks?

Our defenses in summary:

• All third-party GitHub Actions are pinned to commit hashes (not version tags), so an upstream tag rewrite cannot inject code into our pipelines.
• We use OIDC-based Trusted Publishing for npm and PyPI, eliminating long-lived API keys from CI.
• We run the Zizmor static analyzer on every release workflow.
• All Tinfoil organization members are required to have strong 2FA, with a company policy to prefer phishing-resistant methods.
• Vulnerability scanning runs nightly via govulncheck, uv audit, and npm audit.
• Dependency cooldowns are enabled where supported, giving upstream maintainers time to yank malicious releases before they can land in our repos.

See Supply Chain Security - Part 1 for a deep dive.

How can I verify a published SDK release?

Our npm and PyPI packages include cryptographic build provenance signed by GitHub Actions and published to the package repository's public attestation log. You can verify an npm package with:

npm audit signatures

or inspect the raw provenance for any version directly, for example:

curl -s "https://registry.npmjs.org/-/npm/v1/attestations/tinfoil@1.1.4" | jq .

Our Go modules are distributed directly from our GitHub repo, so verification reduces to the security of the Tinfoil GitHub organization (required 2FA, branch protection, tag protection).

What happens if a Tinfoil developer's GitHub account is compromised?

Branch protection rules prevent direct pushes to production branches; all changes require a reviewed PR. Tag protection rules prevent overwriting or deleting tags. Required 2FA, fine-grained PATs with minimum permissions, and Trusted Publishing reduce the blast radius. Any release would also produce a new provenance entry; changes to enclave code or measurements would be visible in the Sigstore transparency log and would cause SDK verification to fail until clients upgraded to the new expected measurements.

7. Compliance

What security and privacy certifications and agreements are available.

Do you offer a DPA?

Yes. Our Data Processing Addendum, including Standard Contractual Clauses where applicable, applies to personal data we process on behalf of business or Enterprise customers and is incorporated into the Terms. A signed DPA prevails over the online addendum. Contact privacy@tinfoil.sh.

Are you SOC 2 compliant?

Yes. We have completed a SOC 2 Type II examination covering security, availability, and confidentiality. The report is available through our Trust Center.

What happens if a security incident affects my personal data?

If a security incident affects your personal data, we will notify the relevant supervisory authority within 72 hours of becoming aware of it where required by the GDPR, and will notify you without undue delay where required by law. Our notice will explain what happened, what data was affected, the steps we are taking, and any precautions you can take. See Section 11 of the Privacy Policy.

Do you support HIPAA / BAA / FERPA / region-specific terms?

You may not use the Services to process Protected Health Information under HIPAA, or other data subject to laws that impose specific security, certification, or contractual obligations on service providers, unless we have a written agreement that expressly permits and governs that use (see Terms § 8). Ordinary personal data processed under our Data Processing Addendum and privacy laws such as the GDPR and CCPA is not restricted. Special category data, such as health information, is permitted only when it is incidental to your use, as defined in our DPA; otherwise it requires a written agreement. Tinfoil is not a HIPAA business associate unless we sign a Business Associate Agreement expressly covering the applicable Services. Confidential computing and SOC 2 do not, by themselves, authorize regulated use or establish compliance with every legal framework. Contact privacy@tinfoil.sh to discuss a BAA, FERPA-related requirements, or region-specific terms before submitting regulated data.

8. Operational failure modes

The most common ways a user can accidentally weaken Tinfoil's guarantees in practice.

Should I use the SDK or hit the REST API directly?

Use the SDK whenever possible. The Tinfoil SDKs (Python, JavaScript, Go, Rust, Swift) perform full attestation verification on every connection and refuse to send data if verification fails. Direct REST access still routes through the enclave but skips connection-time verification; you can only audit attestations post-hoc via certificate transparency. See the SDK overview for setup instructions in each language.

What about running a Tinfoil Container in debug mode?

Debug containers can expose interfaces (shells, ports) that defeat enclave isolation. If you connect via the SDK, a debug container will fail attestation and the SDK will refuse to send data. If you bypass the SDK and connect directly, no enclave guarantees can be made for that workload. Do not run production workloads in debug mode.

How are Container volumes and sandboxes protected?

Volume encryption is managed inside the secure enclave running your workload. Tinfoil operates the volume and may be able to detect access patterns, but the disk contents are designed to remain confidential. You are responsible for managing workload encryption keys securely. Sandboxes are accessible and encrypted with keys under your control, which you are responsible for keeping secret.

Who is responsible for Container backups and recovery?

You are responsible for your workload, configuration, credentials, data, logging, persistence, backup, checkpointing, and recovery. Tinfoil does not provide backup of in-enclave state and cannot recover, reconstruct, or provide access to your in-enclave data, secrets, or workload state. Suspension may interrupt a workload, and termination decommissions the Container and renders its in-memory state irrecoverable. Encrypted persistent volumes are not necessarily deleted with a Container; they are deleted when your account is deleted, as described in Section 7 of the Terms of Service.

Is it safe to send sensitive content via email or support tickets?

No. Email touches subprocessors like Google, Resend, and Slack and is not protected by enclave guarantees. Do not include prompts, file contents, API keys, or other sensitive data in support emails. If you have a security-critical support need, we are happy to set up a dedicated channel (e.g., Signal). Contact us via the contact page.

What other patterns should I avoid?

• Routing Tinfoil through a third-party client that doesn't perform attestation verification, which means you lose the cryptographic guarantee that the connection terminated in an enclave.
• Connecting external MCP servers (ones we don't run inside Tinfoil enclaves) and routing sensitive data through them. The MCP server itself lives outside the enclave boundary, so anything you send to it is governed by that server's operator, not by Tinfoil. Our MCP web-search server runs inside an attested enclave, but still sends queries and requested URLs to an external provider as described above.
• Storing API keys insecurely on your client. Do not share accounts or API keys. Protect credentials, revoke and replace compromised keys, and notify us promptly of suspected unauthorized account or API key use.

9. Threat model and limitations

What Tinfoil protects against, and what it deliberately doesn't.

What threats does Tinfoil protect against?

• Tinfoil employees seeing your prompts, completions, or uploaded files (we cannot, and have no path to)
• Tinfoil being compelled to disclose AI interaction content (we have nothing to disclose)
• Tinfoil using your prompts and responses for training (content does not leave the enclave, so there is no dataset to train on)
• Infrastructure providers (Cloudflare, AWS, GPU cloud providers, and other upstream operators) inspecting plaintext content (they see only ciphertext and metadata)
• A compromised hypervisor or root user on the host machine reading enclave memory (blocked by hardware memory encryption)
• A silent swap to a different model, different inference code, or different firmware (caught by attestation and Modelwrap; see our blog post on proving model identity)
• A man-in-the-middle by the host pretending to be the enclave (caught by TLS key binding to the attested key)

What threats does Tinfoil not protect against?

• Network metadata: source IP, packet timing, and byte volume are visible to our infrastructure providers.
• Hardware vulnerabilities: confidential computing depends on AMD, Intel, and NVIDIA hardware being correctly implemented. Researchers have demonstrated key extraction on AMD SEV-SNP and attestation forgery on Intel TDX under physical attack conditions (see tee.fail).
• Side-channel attacks (timing, power, EM emissions).
• I/O pattern leakage: an attacker observing memory access or I/O patterns may infer metadata.
• Customer misconfiguration and compromised credentials, such as leaked API keys.
• Denial of service: our cloud providers control resource allocation and can throttle or terminate enclave access. Tinfoil may also throttle, suspend, or terminate access as described in our Terms of Service.
• Compromise of your client device: if your laptop is compromised, plaintext is captured before it ever reaches the enclave.
• Anything that happens on your device after the response is received: post-response storage, screenshots taken by other apps, etc.

To learn more about how secure enclaves work and where their guarantees end, see the secure enclave primer in the docs.

What about physical attacks or new hardware vulnerabilities?

Hardware-level attacks are the most credible threat to confidential computing today. Tinfoil currently runs on AMD SEV-SNP and Intel TDX CPUs and NVIDIA Hopper / Blackwell GPUs in confidential compute mode. Public attacks against these platforms generally require physical access and significant resources. We actively monitor vendor advisories, public vulnerability disclosures, and confidential-computing research, and we update our firmware, CVM image, and supporting infrastructure on an ongoing basis as patches are released. The firmware version is included in the attestation report, so clients can detect known-vulnerable configurations and refuse to connect. To benefit from these updates, we recommend keeping the Tinfoil SDKs up to date in your applications. Newer SDK releases pin the latest expected measurements and tighten verification as the platform evolves.

Are legally sensitive raw inputs (journals, medical notes, financial records) appropriate for Tinfoil?

Technically, sensitive inputs get the same protection as everything else. Inference enclaves never write prompts or responses to disk, and the keys to decrypt them never leave the enclave hardware, so neither Tinfoil staff nor our subprocessors can read them, and we cannot be compelled to produce them.

If you handle this kind of data for an organization, some categories need a written agreement first. Protected Health Information under HIPAA requires a Business Associate Agreement, and special category data such as health information is permitted without one only when it is incidental to your use. See Terms § 8 and our Data Processing Addendum. Whether confidential computing satisfies other regimes, such as attorney-client privilege, is a question for your counsel.

Raw content and sanitized summaries get identical protection inside the enclave. Keeping raw entries local and sending only summaries is a policy choice, not a Tinfoil requirement.

Is Tinfoil appropriate for source code with secrets, infrastructure configurations, security datasets, or other highly sensitive material?

Yes — these are exactly the workloads Tinfoil is designed for. The same technical guarantees apply regardless of content type: data is decrypted only inside an attested enclave, inference prompts and responses are not retained beyond temporary prompt caching in encrypted enclave memory, and no Tinfoil employee or subprocessor can read it. Your use must still follow our Acceptable Use Policy, which, for example, prohibits developing or exploiting vulnerabilities to gain unauthorized access. We use Tinfoil internally for our own engineering and infrastructure work, including against our own source code and configs, so this is not a hypothetical use case for us. A few practical recommendations:

• Use the SDK so attestation verification runs on every connection, rather than direct REST access.
• Audit your own application for client-side logging. The enclave protects the request in transit and at inference time, but it cannot protect against an agent or wrapper script writing the prompt to a local log file before it leaves your machine.
• For tool-call patterns that reach out to external services, route only through Tinfoil-operated MCP servers (for example, our confidential web search), not third-party MCP servers.

Still have questions?

Email contact@tinfoil.sh.