Security and Privacy FAQ

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

In short

Tinfoil is built so we do not need to see your AI interaction content to run the service.

Prompts, completions, uploaded files, embeddings, and tool-call payloads are processed exclusively inside secure hardware enclaves. They are never retained on disk, logged, or accessible to Tinfoil, our infrastructure providers, or our subprocessors. As a matter of policy, no AI interaction content ever leaves the enclave boundary, regardless of what features, integrations, or subprocessors we add in the future.
The Tinfoil SDKs independently verify on every connection that the enclave is running the exact open-source code and model weights we publish, by comparing a hardware-rooted attestation chain against measurements published to public transparency logs.
We retain a minimal set of usage metadata (input tokens, output tokens, model name, timestamp) for billing and operations. We operate under technically enforced Zero Data Retention for AI interaction content: it is impossible for us to retain it because we cannot inspect it in transit, in memory, or at rest. The keys required to read prompts and completions never leave the enclave's hardware boundary.
For deeper technical reading, see our primer on secure enclaves, how verification works in Tinfoil, and attestation architecture.

1. Data and privacy

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

What does Tinfoil actually see when I send a request?

Tinfoil sees network metadata (source IP, destination IP, packet timing, byte counts) and per-request billing metadata (input token count, output token count, model name, timestamp). 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. All of that 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?

For the content of your AI interactions: none. The two setups below both keep prompts and responses out of third-party hands. Where they differ is who else sees network metadata 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. 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?

No. The following are never retained: prompts, completions, uploaded files as plaintext, embeddings, tool-call payloads, request bodies, response bodies, intermediate inference traces, or error traces containing user content. No request or response body data ever leaves the security boundary of the attested secure enclave. More broadly, our policy is that nothing derived from your request content is ever retained outside the enclave, so any data we add in the future that would qualify is by construction not retained.

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

No. Enclaves are stateless 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.

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, encrypted Chat backups) is documented in Privacy Policy § 9 (Retention and deletion).

Beyond per-request token counts and billing, we also retain: aggregate request counters on API keys (used for rate limiting; counts only, not request content); dashboard access events for sign-in and account-management actions (handled by Clerk and our application logs); and support records in emails you send to us: ticket threads and email conversations retained in Resend, Google Workspace, and Slack under their respective retention policies. Because support records pass through providers that do not run inside enclaves, we strongly recommend not including prompts, file contents, or other sensitive material in emails you send to us (see §8, operational failure modes).

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.

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 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 never touches Tinfoil's infrastructure, our subprocessors, or 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.

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:

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

If any of these checks fail, the SDK refuses to send data. 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?

No. The only 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. No other middleware, proxy, or load balancer in the request path sees plaintext.

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-pro, confidential-kimi-k2-6, 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?

Only account-level information and ciphertext blobs we cannot read. The full list of data categories (account data, billing data, usage metadata, API key metadata, IP addresses, container deployment metadata, and encrypted ciphertext blobs we hold but cannot decrypt) is documented in Privacy Policy § 7 (Legal requests and government access). As of the effective date of that policy, Tinfoil has received zero government requests for personal data.

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. Enclaves are stateless, so there is no stored ciphertext sitting on a disk that we could hand over either. There are no operational, debug, support, or abuse-monitoring paths that bypass the enclave boundary.

For 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?

Yes. Our Privacy Policy currently states that Tinfoil has received zero government requests for personal data. If we ever receive a compelled request, we will remove the canary. We plan to publish periodic transparency reports as well.

Will you notify users before disclosing data?

Yes — unless legally prohibited (for example, by a gag order). We will also challenge any request we believe is overbroad or unlawful, and where lawful we will notify affected users before complying. The warrant canary in our Privacy Policy exists precisely for the gag-order case: even if we are barred from sending direct notice, removing the canary signals that a compelled request has been received.

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?

No subprocessor receives plaintext AI interaction content. The full list of subprocessors and what each one sees (hosting and CDN providers, authentication, billing, metrics storage, error reporting, support tooling, analytics, and the web search provider) is documented in Privacy Policy § 6 (Who we share information with).

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. Encryption keys are derived on your device and are never sent to us or to the storage provider, so neither Tinfoil nor the storage provider can decrypt them.

5. Web search

Web search is the one feature where information leaves the enclave's confidentiality boundary. We've gone to significant lengths to minimize the resulting exposure.

When I enable web search in Tinfoil Chat, what does the search provider see?

Our search provider, Exa, sees the search query (a short string generated by a model running inside the enclave). Exa does not see who you are, your IP, or your account identifier. We have a Zero Data Retention agreement with Exa covering all search queries. Tinfoil does not see the content of these queries either. The full design is in our blog post on private AI web search.

Can the search provider identify which user issued a query?

No. All search queries from all Tinfoil users across all models flow through the same search enclave with a single shared API key, creating an anonymity set. The provider sees only that "some Tinfoil user" triggered a search — not who.

One important caveat: if Tinfoil and the search provider were both compelled and chose to collude under a warrant, a timing correlation attack could in principle link specific users to specific queries (the conversation content would still remain protected by the enclave). Our current user base is small enough that this would be viable. Web search is opt-in and can be disabled at any time, even on a per-message basis.

What stops a search query from leaking personal information?

Search queries are generated by a safety-trained model that avoids including personal information in tool calls, and every outgoing query is additionally screened by a guardrail model before it leaves the enclave. Queries flagged as containing PII are blocked or masked before they leave the enclave. The full design, evaluation, and trade-offs are documented in our blog post on private AI web search.

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

Web search has weaker guarantees than pure inference because we cannot put a third-party search index inside our enclaves. If you need the same level of confidentiality as pure inference, leave web search disabled. The toggle is per-conversation in Chat and per-message via the API.

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. We offer a Data Processing Agreement including Standard Contractual Clauses where applicable. 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.

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

HIPAA compliance for a subset of models is in progress. Practically, this means we have signed a BAA with the underlying cloud provider and implemented the corresponding administrative and technical safeguards (2FA, encryption at rest, access controls). Both HIPAA and non-HIPAA models run in secure enclaves. These compliance frameworks are largely orthogonal to confidential computing and concern access controls and infrastructure practices. FERPA and region-specific data processing terms are available under enterprise contracts. Contact privacy@tinfoil.sh to discuss.

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.

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. Only Tinfoil-operated MCP servers (for example, our confidential web search agent) run inside attested enclaves.
Storing API keys insecurely on your client. Tinfoil cannot recover or rotate keys you've already leaked.

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.
Denial of service: our cloud providers control resource allocation and can throttle or terminate enclave access.
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 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?

From a pure technical perspective, Tinfoil is engineered to hide all sensitive user data submitted into the system, and the enclave is stateless. No staff member or subprocessor can compel us to produce plaintext prompts or completions because the cryptographic material required to decrypt them never leaves the hardware boundary.

Whether that is sufficient for a specific legal regime (HIPAA, attorney-client privilege, GDPR special categories, etc.) is a legal question more than a technical one, and the legal frameworks around confidential computing are still evolving.

Raw content vs. sanitized summaries: from a security standpoint, both receive identical protection inside the enclave. If you want belt-and-suspenders separation, you can keep raw entries local and send only sanitized summaries, but that is a policy choice and not a technical requirement that Tinfoil imposes on you.

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, no plaintext is retained, and no Tinfoil employee or subprocessor can read it. 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.