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

Retention depends on the Service. For the Inference API, we do not retain prompt or response content after the response is returned. 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. External tools and providers have their own processing boundaries.

Does prompt caching change what is retained?

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

Retained information includes account and authentication data, billing records, usage metrics, security logs, deployment metadata, and support communications. We keep personal data only as long as needed for the purposes in the Privacy Policy, unless a longer period is required for legal, tax, accounting, security, fraud-prevention, dispute-resolution, backup, or operational reasons. Do not include prompts, file contents, API keys, or other sensitive material in support emails; those channels are outside the confidential inference path.

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. The one thing outside the enclave that touches a device is the iOS app's anonymized Sentry crash reports, which are limited to crash diagnostics and never include 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 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:

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. 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. Enclaves are stateless, so there is no stored ciphertext sitting on a disk 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.

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?

Our Privacy Policy contains a dated statement about government requests. It should not be treated as a real-time indicator of whether a request has occurred or as a guarantee of notice. Legal disclosure and notification are governed by the Privacy Policy and applicable law.

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. This FAQ does not promise an alternative notification mechanism where notice is prohibited or would be futile.

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. 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. 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 and page fetch

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. The enclave boundary protects processing within Tinfoil; it does not make information sent to those providers invisible to them.

What does the web search or page-fetch provider see?

The current web-search tools send search queries to Exa and retrieve page text through Exa Contents. Exa receives the query or requested URL. 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 are covered by a Zero Data Retention agreement with Exa. That agreement is a contractual protection, not enclave isolation at the provider. Query text and URLs can themselves contain sensitive information. See the current web-search and MCP web-search documentation for the tool behavior and options.

Can the search provider identify which user issued a query?

We do not send your Tinfoil account identifier or your device's IP address to the search provider. 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.

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 separately 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 relevant supervisory authorities no later than 72 hours after becoming aware of the incident where the GDPR applies, 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, payment card data outside our payment processors, or other regulated data unless we have a written agreement that expressly permits and governs that use. 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 encrypted state irrecoverable, 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. 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.
• 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 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?

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.