A Prompt Is a Disclosure

Audience: Engineers who send confidential material to language models through a router, and the coding agents working in their repos.
Reading time: ~30 minutes.

Every call to a language model is a disclosure. The prompt goes to the router that forwards it and to the cloud that runs the model, two companies you probably don’t control, plus a third if the model searches the web. When the prompt carries confidential documents, meeting transcripts, CRM notes, or email under NDA with outside parties, each of those companies now holds someone else’s secrets, on whatever terms you agreed to. And those are only the calls your code makes. The coding agent that builds it and the assistants your users connect to it send their own.

The specifics here are OpenRouter’s, since it’s the router I measured, but the same questions apply to any model router or gateway and to any model vendor’s API you call directly: who sees the prompt, who keeps it and for how long, and what the terms let them do with it.

On OpenRouter, the baseline I’d recommend is short. Send every request with two routing fields that admit only endpoints OpenRouter lists as collecting no data and retaining nothing, and set the same policy on the account as a second layer. A model with no compliant endpoint fails loudly instead of routing around the policy, and every call records which endpoint served it. In practice Claude then runs on Amazon Bedrock or Google Vertex instead of Anthropic’s own API, at the same prices, with prompt caching intact. I measured all of that on a production account; the numbers are below.

It’s a chain of promises, not a technical guarantee (OpenRouter’s own DPA says as much about its providers), and abuse monitoring and legal holds survive zero retention everywhere. For a small firm’s internal work I think it’s the right baseline, and there are stronger tiers for workloads that need them.

You can also paste this page’s URL into a coding agent. The last section, For Your Coding Agent, is a set of rules an agent can check a repo against, the same trick as Prose as a Prompt. The rest is for people.

Who Sees a Prompt

The list of parties is longer than the API call suggests:

Anthropic isn’t on the list when Claude runs on a cloud. In Anthropic’s words, “On Amazon Bedrock and Google Cloud’s Agent Platform, the cloud provider is the data processor.” Anthropic is the processor for its own API, for Claude Platform on AWS, and for Foundry.

The list applies to your coding agent too, and it’s the row that’s easiest to miss. A coding agent reads whatever it’s pointed at: source, configs, query results, the documents you ask it to summarize. All of it goes to the agent’s model host under whatever plan the agent runs on, and none of the routing below is in the way. On a commercial plan the host is processing your data for you. On a personal plan you’re under consumer terms, where one setting usually decides whether your sessions train the next model.

Most consumer AI products have that setting, most ship with it on, and each belongs to the individual account, so no employer can set it for you. Claude’s is “Help Improve our AI models” under Settings, then Privacy: on, Claude and Claude Code sessions can train future models and are kept up to five years, de-identified; off, 30 days. ChatGPT’s is “Improve the model for everyone” under Data controls, and it covers Codex on a personal plan too. Google’s Gemini app calls it “Keep Activity,” GitHub Copilot’s individual plans have “Allow GitHub to use my data for AI model training” (on by default since April), and Perplexity has “AI Data Retention.” Cursor’s works the other way round: turn Privacy Mode on. Turn the rest off on any account that touches someone else’s material, and look again after the vendor’s next terms update. Know its limits, too: an opt-out only works going forward, rating or reporting a conversation can still send it for review, and sessions flagged by safety systems are kept regardless (at Anthropic, up to two years, with classifier scores up to seven).

The setting is the floor. Work on confidential data belongs under commercial terms (Team and Enterprise plans, the API, or your own cloud account), where the vendor doesn’t train on it by default. The court’s reasoning in Heppner, below, ran through Anthropic’s consumer terms. Claude Code reaches Bedrock or Vertex with an environment variable (CLAUDE_CODE_USE_BEDROCK=1 or CLAUDE_CODE_USE_VERTEX=1) plus that cloud’s credentials, and for Vertex a project id.

Keys leak the same way. Paste a router key into an agent’s prompt and it sits in the vendor’s transcript store, and in plaintext on your own disk (Claude Code keeps local transcripts 30 days by default). A key that has been in a prompt is a key to rotate.

If you serve an MCP connector, its results take a path the routing fields never see. A user who connects it to Claude or ChatGPT gets your search results and lookups dropped into their own conversation, under whatever plan that user has. The server’s only levers are what it returns and who can connect. A prompt is a disclosure in every direction.

Two Fields and a Header

Every request carries this:

"provider": {"data_collection": "deny", "zdr": true}

and this header:

X-OpenRouter-App-Visibility: hidden

Here’s what each field means in OpenRouter’s own words, from the provider-routing docs as I read them on October 20:

• data_collection: "deny" means “use only providers which do not collect user data.” The alternative, allow, permits “providers which store user data non-transiently and may train on it.” On its own this field is not a retention guarantee.
• zdr: true means “only be routed to endpoints that have a Zero Data Retention policy.” The per-request field “operates as an ‘OR’” with the account-wide setting, so code can add the restriction but can’t remove one the account sets.
• In-memory prompt caching “is not considered ‘retaining’ data,” so Claude’s prompt cache keeps working under zdr. I measured it, below.
• Tool backends aren’t filtered by zdr, with one documented exception: OpenRouter rejects the Firecrawl search engine under account-level zero retention.
• OpenRouter tracks a policy per endpoint, assumes an endpoint “both retains and trains on data” when it can’t establish one, and updates the public list when a provider’s policy changes. Its DPA adds that the listing reflects the provider’s own represented policy and “does not constitute OpenRouter’s guarantee of AI Model Provider compliance” (section 2.4(b)).

The header covers a different leak. HTTP-Referer and X-Title are OpenRouter’s app attribution, and OpenRouter publishes a public page per referer URL with the app’s name, origin URL, and daily per-model token volumes. There’s no prompt content on it, but there’s enough to tell the world which company runs how much of which model. X-OpenRouter-App-Visibility: hidden keeps a new app off those pages. It doesn’t touch an app that already exists; that takes a support ticket.

The fields ride on the request, in code, from one constant and one header builder that every call site uses. There’s no per-call option, so no caller can drop them, and a test pins both. The account settings are the second layer, for any key or proxy that forgets. The order matters: a provider’s promise only counts if the request can’t reach a provider without one.

OpenRouter Itself

OpenRouter is a party to every call whatever the routing says, so its own handling matters as much as the hosts’. Its terms and privacy policy were last updated August 31 and its DPA August 26.

It doesn’t store prompts or completions by default (“OpenRouter does not store your prompts or responses, unless you opt in”), though it keeps request metadata: token counts, latency, timestamps, the model, plus the user value you send and the request’s referer, user agent, and origin, all readable back through its generation API. It does read prompts briefly. Prompts are categorized by a model with a zero-retention policy and not stored afterwards (terms 6.5), and may pass automated risk classification before deletion “promptly following generation of the relevant Output” (DPA 2.4(a)). And it doesn’t train on them: “OpenRouter does not use your Inputs or Outputs for model training.”

Two opt-ins change that, and both stay off. Input & Output Logging keeps prompts and completions for at least three months, visible to your organization’s admins, for no discount. OpenRouter Use of Inputs/Outputs lets OpenRouter “use your prompt and completion data to improve the product,” and in exchange you get “a 1% discount on all model usage.” One percent! The terms (6.2) attach “a worldwide, perpetual, irrevocable” license to opting into “prompt logging,” including permission to “license or sell your User Content in anonymized form.” The terms and the FAQ use older names than the settings pages do, so I treat either opt-in as granting it and keep both off.

That makes the account itself a control plane. Input & Output Logging is a toggle under Observability that only an organization’s admins can flip, and once it’s on, those admins “can view stored prompt and response content for every request in the organization.” Broadcast, in the same settings, ships “the input messages and model output” to any of about twenty observability destinations, with a per-destination privacy mode that’s off unless you tick it. No request can see either setting, so the account’s admins belong on the who-sees list. Keep them few, have each turn on 2FA (SSO is Enterprise-only, and I found no way for an organization to require 2FA), and re-check the settings on a schedule.

A few smaller things matter for confidential work. The DPA exempts model providers from its 30-day notice of new subprocessors (section 5.2), so the routing policy, not the notice list, is what bounds them. The trust center lists SOC 2 Type 2 (undated) and a penetration-test report. Regional processing (eu.openrouter.ai, us.openrouter.ai) exists on Business and Enterprise plans, though account and billing data may still sit in the US. And the account itself can enforce zero retention per model group (Anthropic, OpenAI, Google, other), per guardrail, or per request, where a request “can only ensure ZDR is enabled, not override” the account. A guardrail, one per key or member, carries an allowed-provider list that acts as a ceiling, plus a spend cap. The account’s privacy settings always apply as a default guardrail.

What I Measured

Everything here ran on a production OpenRouter account and key, through the same request shape the code sends. About $1.20 in all.

Here’s how the models I use route under both fields. Claude goes to Bedrock or Vertex only:

Anthropic’s own endpoint, Azure, and Claude Platform on AWS aren’t zero-retention on OpenRouter for these models, and the refusal says so in as many words: “Filter by Data Policy removed azure/global, claude-on-aws, anthropic.” Pin a request to any of them under zdr and it fails.

The surprise was how small the pool gets. OpenRouter’s public zero-retention list carries six rows for each of these Claude models (Bedrock and Vertex, each with a global endpoint and two regional ones). Before the data policy applies, though, OpenRouter drops the regional endpoints (they carry a surcharge the request didn’t opt into) and the “fast” tier (also opt-in). For Opus 5.5 the routing funnel reads 11 endpoints, then 6 after the regional filter, 5 after the tier filter, and 2 after the data policy: Bedrock and Vertex, global. Fallback depth for Claude is two hosts on two clouds. That’s enough, but it isn’t eleven, and the list moves: an OpenRouter email quoted on Hacker News says zero-retention routing dropped Google-authored models on October 18, which nothing official confirms yet, and the live list still shows Gemini. If Claude on Vertex ever drops the same way, Claude’s fallback is one host.

Fable 5 is the casualty. It’s listed on Bedrock and Vertex too, but none of its endpoints is on the zero-retention list, and that’s by design upstream. Anthropic’s data-retention page says Claude Fable 5 and 5.1 “require 30-day data retention and are not available under ZDR unless expressly authorized by Anthropic,” and Bedrock runs Fable only in its aws_review mode, where content is kept up to 30 days and can be reviewed. If you’ve pinned Fable, that’s a model decision to make before the policy can apply. Don’t infer a model’s status from its hosts; read the list.

Also serving under both fields: Perplexity’s sonar, sonar-reasoning-pro, and sonar-deep-research, OpenAI’s gpt-5 and gpt-5-mini (on Azure), Google’s gemini-2.5-pro, DeepSeek’s deepseek-chat-v3.1, and Meta’s llama-4-maverick. Not serving: gemini-3-pro-preview and the deprecated grok-4.

The web plugin works under the policy as well. Per OpenRouter’s docs, it uses the model’s native search where the provider has one (Perplexity, Anthropic, Google, OpenAI) and Exa otherwise. With sonar-pro, the searches are Perplexity’s own. The plugin is deprecated in favor of the openrouter:web_search server tool.

Prompt caching was what I most expected to lose, and it survived. Two calls with the same long system prompt and a cache breakpoint, a write and then a read, at the same cost on both clouds:

A contract suite that runs every model call an application makes, on its production model and budget, passed 22 of 23 under the policy for $0.43, with every Claude call served from Bedrock and cache reads intact. The miss was a Perplexity lookup that failed twice in its first three runs, then passed 9 of the next 11 under the policy, against 10 of 10 without. I read it as Perplexity variance in a bad window, not the policy.

So what do you lose? For my workloads, nothing: every model I use but Fable, tool use, reasoning, the web plugin, and prompt caching all work at the same prices. What changes is that a model with no zero-retention endpoint is unavailable (Fable 5 today, and maybe a brand-new model until a cloud lists it), and each Claude model has two eligible endpoints out of the eight to eleven OpenRouter lists. I didn’t measure latency or rate limits at volume on Bedrock and Vertex, so compare your first big run against earlier ones.

It helps to be clear about what “Anthropic’s own endpoint” means here. It’s all inside OpenRouter. For each Claude model OpenRouter lists several hosts (Anthropic’s API, Bedrock, Vertex, Azure, Claude Platform on AWS), all running the same model. You don’t name Bedrock: you send two rules, and OpenRouter picks among the hosts that satisfy them. Only Bedrock and Vertex qualify for Claude on OpenRouter’s list, so that’s where the traffic lands, each one the other’s fallback. And the exclusion is about OpenRouter’s agreements rather than Anthropic. Vercel’s AI Gateway lists Anthropic’s own API as zero-retention.

Assumptions That Don’t Hold

Each of these sounds right, and each is wrong in a way only a request or the vendor’s own page reveals. It’s verification-first agentic coding applied to a vendor’s privacy docs: a code comment or a doc is a hypothesis until a request proves it.

• “Every model call goes through the router.” Your code’s do. The coding agent’s go straight to its own model host under its own plan, and an MCP connector’s results go to whatever model each user’s assistant runs.
• “deny means no retention.” It’s easy to read data_collection: deny as admitting only providers with no training and no retention. OpenRouter’s definition is narrower (“do not collect user data”), and zero retention is the separate zdr field.
• “The hidden header hides your apps.” It hides apps created with it. The ones that already existed stay public until OpenRouter support hides them.
• “Fable 5 is Anthropic-only.” Its 404 suggests it. Its endpoint list shows Bedrock and Vertex as well, and none of those endpoints is on the zero-retention list. The host isn’t the policy.
• “Each Claude model has six eligible endpoints.” That’s what the zero-retention list shows. The routing funnel shows the regional rows and the fast tier get filtered before the policy, leaving two.
• “A refusal can be recognized by its ‘data policy’ wording.” A pin conflict’s message names the data-policy filter too, while failing at the fallback filter. The ignore list and provider ceiling I recommend below are filters in the same funnel too, and would fail at steps of their own. Any failed routing step means the router refused.
• “A test pins it.” A test that copies the constant, changes the copy, and asserts the original unchanged can never fail. A test has to exercise the request the code actually sends, which is verification at the boundary in its plainest form.

Models Trained in China

Models trained in China are where this gets muddled, because “should we use DeepSeek?” is really two questions. One is where the prompt goes. The other is what the weights do once they have it. A host can fix the first and can’t touch the second.

Where the prompt goes depends entirely on who runs the model. Call DeepSeek’s own API and its privacy policy (updated February 10) says it will “directly collect, process and store your Personal Data in People’s Republic of China,” and use your inputs to “train and improve our technology.” China’s 2017 National Intelligence Law requires companies to “support, assist, and cooperate with state intelligence work” (as quoted in a House committee letter this April). Call the same open weights on Bedrock and none of that applies. AWS runs each model provider’s software in deployment accounts AWS owns: “Model providers don’t have any access to those accounts,” so “they don’t have access to Amazon Bedrock logs or to customer prompts and completions.” Azure says the same for serverless catalog models (“Microsoft doesn’t share these prompts and outputs with the model provider”). Bedrock’s catalog today includes DeepSeek V3.2, Kimi K3, several Qwen3 models, GLM 5.3, and MiniMax M2.5. For data flow, Kimi K3 on Bedrock is in the same position as Claude on Bedrock.

What the weights do travels with them. NIST’s Center for AI Standards and Innovation (CAISI) evaluated DeepSeek in September 2025 by downloading the weights from Hugging Face and running them on its own servers, never touching DeepSeek’s API, and still concluded that “CCP censorship is built directly into DeepSeek models.” The finding I care more about for this platform is agent hijacking: agents built on R1-0528 were “12 times likelier than evaluated U.S. frontier models (GPT-5 and Opus 4) to follow malicious instructions designed to derail them from user tasks,” and tried to exfiltrate login credentials in 37% of cases against 4% for the US models. (In fairness, OpenAI’s own open-weight gpt-oss matched R1-0528 on phishing hijacks, at 48%, so some of that gap is open versus closed frontier rather than China versus the US.) CrowdStrike tested the raw R1 weights and found vulnerable code in 19% of cases at baseline and 27.2% when the same task was framed as being for a system in Tibet; the effect survived distillation into a Llama-70B.

Post-training doesn’t reliably scrub it either. Perplexity’s de-censored R1 1776 looked clean, until researchers got “CCP-aligned refusals” back out of its quantized version. And backdoor research (Anthropic’s Sleeper Agents, and the finding that as few as 250 poisoned documents can plant one) shows trained-in triggers are plausible and can survive safety training, though nobody has shown one in these models, and CAISI says plainly it didn’t test for them.

Censorship on Tibet is a curiosity for most business software. Twelve times the hijack rate is not, for an agent that reads documents outside parties wrote. That’s Simon Willison’s lethal trifecta, with a model that’s easier to steer.

Governments mostly drew the same line, and in 2026 they started crossing it. The early actions (Italy’s Garante, Taiwan, South Korea’s privacy regulator, Australia, the Navy and NASA, the Texas, New York, and Virginia device bans) target the app, the website, or the API. Victoria’s guideline even carves out the weights in so many words: its DeepSeek ban “does not include open-sourced Large Language Models (LLM) where the entire codebase is available for inspection, the model is deployed locally on a government system, and appropriate mitigations are in place.” Microsoft did the same split commercially. Brad Smith told the Senate “At Microsoft we don’t allow our employees to use the DeepSeek app,” while Azure hosted R1.

Then the rules moved to the weights. Section 1532 of the FY2026 NDAA makes the Pentagon remove AI “developed by” DeepSeek, wherever it’s hosted, and bars contractors from using it on Pentagon work, while section 6604 of the same law covers only “the DeepSeek application or any successor application or service” on intelligence systems. A DHS order published in the Federal Register today removes “third-party products and services developed using DeepSeek implementations” from civilian agencies, and says “The models themselves may contain malware or other security vulnerabilities.” Texas added Alibaba, Zhipu, MiniMax, and Moonshot AI to its prohibited list in January. And the House Homeland Security and China committees’ April letter to Airbnb, which reportedly runs Qwen through US providers, lists API data pathways as a separate risk and asks whether the weights “have been independently audited for the presence of backdoors.” If you sell to the Pentagon or a civilian agency, provenance is now a compliance question.

Here’s the part that surprised me: on OpenRouter, zero retention doesn’t mean not Chinese. Of the 1,026 endpoints on the zero-retention list today, 483 serve models trained in China, mostly on US hosts like DeepInfra, Together, Fireworks, BaseTen, and Parasail. But the list also includes first-party endpoints run by Moonshot AI, Z.AI (Zhipu), MiniMax, Tencent, ByteDance’s Seed, and SiliconFlow, and OpenRouter labels most of them as headquartered in Singapore, because that’s where the contracting entity sits (Moonshot’s privacy policy names MOONSHOT AI PTE. LTD.). DeepSeek’s own API is excluded by data_collection: "deny", since OpenRouter marks it as training on prompts, and Alibaba’s, Baidu’s, and Xiaomi’s first-party endpoints retain prompts and drop out too. So under exactly the two fields above, a request for Kimi K3 can land on Moonshot’s own endpoint, and the zero-retention pool for deepseek-chat-v3.1, which served under the policy in my measurements, includes SiliconFlow. Zero retention is a retention promise. It says nothing about jurisdiction. Whether PRC law reaches a Singapore subsidiary is a question I can’t answer, but Anthropic’s own sales policy treats it as reachable: it refuses companies more than 50% owned by firms headquartered in China, including through “subsidiaries incorporated in other countries,” because those firms face “legal requirements that can compel them to share data, cooperate with intelligence services.”

OpenRouter has no routing parameter for country. The fix is a provider list: an allowed-provider ceiling on the account or key (Bedrock, Google, Perplexity, and Azure if you need it), or an ignore list on the request. For Claude none of this matters, since no Chinese provider serves Anthropic models. It matters for any tool that lets a user pick any model, like a chat tool with a model menu.

Where I come out, for now: no prompt goes to an endpoint run by a Chinese company, Singapore label or not, and that’s enforced by the provider ceiling rather than by remembering. Chinese-trained weights on a US cloud are a behavior question, judged per task. They’re fine for bounded work with no tools and no outside parties’ text, and they’re not my pick for an agent that reads untrusted documents and can act. That second call would change with a published hijacking evaluation of the specific model I’d be running.

What Others Do

The problem everyone is reacting to is measurable. Cyberhaven’s 2026 report says “39.7 percent of all AI interactions involve sensitive data,” and that 58.2% of Claude usage it sees runs through personal accounts. In January a wrapper app that let people chat with OpenAI, Anthropic, and Google models left a Firebase backend open, and roughly 300 million messages from more than 25 million users were exposed from the app’s own backend, with no model host involved.

Organizations handling confidential material tend to land in one of six places, and each breaks somewhere:

The baseline here sits in the second row, with code around it. Apple’s Private Cloud Compute paper is the best statement of what that row lacks: with conventional cloud promises “there is generally no way for security researchers to verify this promise,” and “Security and privacy guarantees are strongest when they are entirely technically enforceable.” OpenAI seems to agree. According to VentureBeat’s account of its September DevDay, OpenAI’s new “Private Intelligence” includes “ZDR with Private Safety Processing,” which runs abuse review in a “hardware-attested safety runtime” without letting its personnel see the content. That reads like an admission that plain zero retention leaves the abuse-review gap open.

Two firms do something worth copying. JPMorgan built LLM Suite as “a portal that allows users to tap external large language models,” which is a router the bank owns, so the router hop isn’t a new party. And Thomson Reuters says CoCounsel turns off providers’ abuse monitoring “where applicable,” and sends every request “under the identity ‘Thomson Reuters,’ never identifying the Thomson Reuters customer who made the request.” That’s the hidden-header idea, done all the way down: the host knows who’s paying, not whose document it is.

Here’s what the providers promise for API traffic, from their own pages as of October 20:

Zero retention through a router is the router’s contract with each provider, not something the provider grants everyone. That’s why Vercel’s AI Gateway can list Anthropic’s own API and Claude Platform on AWS as zero-retention while OpenRouter lists neither.

The other routers and gateways land in different places. Vercel’s AI Gateway offers zero retention team-wide (for a per-request fee) or per request, fails with a 400 no_providers_available when nothing qualifies, says it retains no prompts itself, and lists Fable 5 as unsupported under zero retention on every provider. Hosted Portkey keeps logs 90 days by default, with zero retention and PII scrubbing available; its hybrid deployment keeps prompts in your environment and sends only metrics out. Cloudflare’s AI Gateway logs by default, prompts and responses included, and per-request headers turn that off. Self-hosted LiteLLM doesn’t log content by default and removes the router as a third party, but moves the supply chain onto you: two LiteLLM releases on PyPI were credential stealers in March 2026. Requesty and Not Diamond advertise logging off per key, organization-wide zero retention on request, and SOC 2 (Requesty’s in progress), but that’s from marketing pages, so low confidence. And calling Bedrock or Vertex directly removes the router as a processor: the contract is yours, and retention is a setting in your own cloud account.

Practitioners mostly argue about trust. “OpenRouter sees all your prompts, sends your requests to different providers with pinky promises that they dont use your data, and is therefore a non starter for any company who cares about compliance,” one Hacker News commenter wrote in August. Micah Lee put the same point about zero-retention promises more briefly: “Nothing technical guarantees it.” The other side’s best argument is practical. Another commenter called getting “genuine zero data retention agreements” on your own “one of the most exhausting things to do,” since the clouds link to generic privacy policies, and gave OpenRouter credit for stating “the data retention policies of almost all, but not all of their providers.” A commenter who appears to speak for OpenRouter: “If you don’t opt in, we don’t retain anything and are a pass through.” Others note that a claim of “nothing is retained anywhere” can’t survive safety retention, and that “a promise that is not in the contract is not a promise” (a GDPR-focused vendor blog, October 14). Comparison write-ups steer regulated workloads to a self-hosted gateway or straight to Bedrock.

The router can also change hands. Stripe is buying OpenRouter (announced August 19). The announcement promises “same mission, same name, same product, same roadmap,” and says nothing about logging or retention after the deal closes. Terms are a snapshot, which is one more reason the policy lives in code and the evidence lives in the logs.

What the Rules Say

Official guidance mostly says the obvious thing, slowly. The UK’s NCSC said it in 2023: “the query will be visible to the organisation providing the LLM.” NIST’s Generative AI Profile (AI 600-1) asks organizations to “Inventory all third-party entities with access to organizational content,” which is the Who Sees a Prompt table with a control number on it. Its privacy section is almost all about training data, though, so you can’t cite NIST as saying a prompt is a disclosure to the host.

The financial regulators are sharper. New York’s DFS told regulated firms in October 2024 to require AI vendors to give “representations and warranties related to the secure use of Covered Entities’ NPI, including requirements to take advantage of available enhanced privacy, security, and confidentiality options.” That’s zero retention, written as a contract requirement. Hong Kong’s SFC is the only regulator I found that names the middle layer: firms should assess “data leakage risk at each third party component,” including “prompt management solutions, orchestration tools.” A router is exactly that component. FINRA Regulatory Notice 24-09 (June 2024) says its rules apply whether firms build their own generative AI tools or are “leveraging the technology of a third party.”

Privacy regulators care about roles. The UK ICO says “a contract does not necessarily determine whether an organisation is a controller, joint controller or processor,” and that a developer “processing data for their own purposes” is a controller for that processing. A host that keeps prompts for abuse review or training is doing it for its own purposes; zero retention is what keeps it a processor. On health data, HHS limits the HIPAA conduit exception to “transmission-only services,” and my reading (not HHS’s) is that a router that logs, caches, or classifies prompts is more than a conduit and needs a business associate agreement.

Lawyers have the most specific rules, and they apply to anyone holding other people’s material under NDA. ABA Formal Opinion 512 (July 2024) expects lawyers to understand a tool’s terms well enough to know who can see what goes into it, and says that “boiler-plate provisions to engagement letters purporting to authorize the lawyer to use GAI” aren’t enough for client consent. California’s 2026 guidance says “Reasonable efforts require more than reliance on generalized marketing assurances,” and adds a rule for agents: no deployment “that permits autonomous external transmission of client information … without appropriate safeguards and human review.” Florida’s Opinion 24-1 wants a provider that will notify the lawyer of “service of process requiring the production of client information.” And the UK Law Society warns that metadata “might be shared with the main technology providers, not only with the specific software and vendor you are using,” which is the whole chain in one sentence. Know who can read it, and be able to say so.

The courts got there this year. In February a federal judge in Manhattan held in United States v. Heppner that a defendant’s chats with consumer Claude weren’t confidential, “not merely because Heppner communicated with a third-party AI platform but also because the written privacy policy” let Anthropic train on the data and disclose it to third parties, “including ‘governmental regulatory authorities.’” The reasoning runs straight through the provider’s terms, which is what commercial no-training, no-retention terms change. In Colorado, a proposed protective order in Morgan v. V2X would bar sending confidential material to any service that will “further transfer the Confidential Information to another provider” unless due diligence shows that provider’s controls and contracts keep the order intact. That reads directly on routers, and the motion says several judges in that district already use similar language. In June a New York court quashed a subpoena to OpenAI for “All prompts, inputs, uploaded materials, and corresponding outputs” tied to an opponent’s accounts, on work-product grounds, but civil litigants now subpoena the model provider directly. Preservation orders reach the provider too. In New York Times v. OpenAI the court ordered OpenAI on May 13, 2025 to preserve output logs, and a stipulated order that October ended the duty as of September 26. OpenAI said at the time that data under its zero-retention API wasn’t affected, because it was never stored. With zero retention there’s nothing to produce.

Steps Above the Baseline

The policy is a baseline. If a workload needs a stronger guarantee (material under an unusually strict NDA, or regulated personal data), these are the steps up, in order of effort.

First, account-level enforcement and a provider ceiling, which is no code at all: the account settings at the end of the next section. It removes the risk of a key or a proxy that forgets the policy.

Second, bring your own key to your own Bedrock account. The contract and the retention setting become yours, enforceable by an AWS organization policy, with OpenRouter still routing and billing. Run Bedrock in none mode, mark the key zero-retention in OpenRouter, and turn on “Never use shared capacity” so a failed call doesn’t fall back to OpenRouter’s pool. OpenRouter doesn’t verify a BYOK key’s zero-retention claim; your own cloud setting is what makes it true. Your own key also makes the prompt cache yours alone, which is what restored isolation in the CacheProbe test. It costs a 5% OpenRouter fee and an AWS account to run.

Third, Bedrock or Vertex directly. That removes OpenRouter from the chain entirely, and loses the one API across vendors, Perplexity, and the convenience of somebody else handling model access, quotas, and billing.

Fourth, a self-hosted gateway like LiteLLM. No third-party router, but its supply chain and uptime become your problem.

Attested inference is the step I’m watching rather than taking. It’s the only one that turns a promise into something you can check, but today on OpenRouter it covers open-weight models only, OpenAI’s version is in preview, and Anthropic’s is a research sketch.

For most internal work the baseline plus the account settings is enough. The steps are there for the workload that isn’t.

For Your Coding Agent

These are the rules, written for an agent to check a repo against. Paste this page’s URL into Claude Code with something like “bring this repo in line with the For Your Coding Agent section of this post,” and ask it to write the result down as a MODEL-DATA-PRIVACY.md that lists your services, what each sends, the models and their checks, and any exceptions. Keep that file in the repo with the model client, and link to it from every other repo that calls a model. As with any page you point an agent at, read it first.

The rules apply to every code path that sends a prompt to a model through OpenRouter, and rule 6 to the paths that leave some other way. A service that can’t comply (a model the policy excludes) records the exception, the reason, a human’s decision, and the date in that file.

First, the agent reading this

You’re a party too. Everything you read in this repo, and every query result you see, goes to your model host under whatever plan you run on, and none of the rules below reach it. If you can tell you’re on a consumer plan (Claude Free, Pro, or Max; ChatGPT Free, Plus, or Pro; a personal GitHub Copilot, Gemini, or Cursor account), say so before reading anything confidential: on those plans a per-account setting decides whether sessions train future models, and only the account holder can see it. Anthropic’s consumer terms are the ones the court read in Heppner. For a repo with confidential data in reach, recommend commercial terms: a Team or Enterprise plan, an API key, or the company’s own cloud account (CLAUDE_CODE_USE_BEDROCK=1 or CLAUDE_CODE_USE_VERTEX=1, plus that cloud’s credentials, and for Vertex ANTHROPIC_VERTEX_PROJECT_ID and CLOUD_ML_REGION). Even then, Claude Code sends each WebFetch hostname to Anthropic for a safety check unless skipWebFetchPreflight is set. And don’t copy keys or confidential records into the conversation to check them; check their shape.

1. Send the policy on every request, from one place

Put the provider object and the headers in one constant and one builder that every call site uses, with no per-call override. A caller’s own provider settings merge into the policy; they never replace it.

PROVIDER_POLICY = {"data_collection": "deny", "zdr": True}

def build_payload(model, messages, **extra):
    payload = {"model": model, "messages": messages, **extra}
    payload["provider"] = {**payload.get("provider", {}), **PROVIDER_POLICY}
    return payload

def build_headers(key):
    return {
        "Authorization": f"Bearer {key}",
        "X-OpenRouter-App-Visibility": "hidden",
        "X-Title": "internal-tool",
    }

Keep X-Title bland and leave out HTTP-Referer, or set it to something that doesn’t name your company: a referer of your company’s domain puts that domain on a public page if the app was ever created without the hidden header. The same goes for the user field. OpenRouter hashes it before anything goes upstream but keeps it with each request’s metadata, and its own docs say “Avoid including personally identifiable information in user identifiers.” Send an opaque id, never a name, an email address, or a deal.

A proxy that forwards a browser’s request has to build the body on the server, not patch the one the browser sent. Reject anything that isn’t a JSON object, check the model against a list, copy only the fields the tool uses, and set the policy there:

let sent;
try { sent = JSON.parse(bodyText); } catch { return reject(400); }
if (!sent || typeof sent !== "object" || Array.isArray(sent)) return reject(400);
if (!ALLOWED_MODELS.has(sent.model)) return reject(400);
const body = {
  model: sent.model,
  messages: sent.messages,
  max_tokens: sent.max_tokens,
  stream: sent.stream,
  provider: { data_collection: "deny", zdr: true },
};

Merging the policy into the browser’s body isn’t enough, because everything else it sent goes through too: a plugins entry for the web plugin, an openrouter:web_search server tool, or a model id ending in :online free to turn search on, and search sends text from the conversation to a backend the policy doesn’t govern. A user can add those fields, and so can any script running in the page.

A service that pins a provider merges the pin into the same object:

"provider": {"order": ["amazon-bedrock"], "allow_fallbacks": false, "data_collection": "deny", "zdr": true}

Zero retention says nothing about jurisdiction (see Models Trained in China). If a service lets users pick any model, keep prompts off endpoints run by Chinese companies with an ignore list in the same object, or better, an allowed-provider ceiling on the key. OpenRouter labels several of these providers as Singapore-headquartered, so filtering on a country code misses them:

"ignore": ["deepseek", "alibaba", "moonshotai", "z-ai", "minimax", "seed", "siliconflow",
           "tencent", "baidu", "streamlake", "xiaomi", "nex-agi", "stepfun"]

Those slugs come from https://openrouter.ai/api/v1/providers as of October 20, 2026, and the list grows, which is why a ceiling (a list of who’s allowed) ages better than a list of who isn’t.

Otherwise leave fallbacks on and don’t name a provider. OpenRouter falls back between eligible endpoints on its own (Bedrock and Vertex, for Claude), and that’s the point of not pinning. A pin to a provider the policy excludes doesn’t fall back to a compliant one; it fails. Perplexity models have exactly one endpoint, so they have no fallback either way. And never write a fallback that retries without the policy when the policy fails. That’s the one fallback this policy forbids.

2. Test the request the code actually sends

A test asserts the provider object and the hidden header on every request path, including a tool-use round and any proxy path. It captures the outgoing request (a fake transport, a recorded request body) rather than inspecting the constant. A test that copies the constant and checks the copy can never fail.

3. Fail closed, by name

Classify by the payload’s shape, not by guessing, and don’t echo the payload into logs. OpenRouter’s refusal carries a routing funnel: error.metadata.routing_funnel lists each filter with the endpoints left after it, and error.metadata.failed_routing_step names the one that emptied the pool (“Filter by Data Policy” for a policy refusal). Read that field first and the message only when the field is absent. A pin fails at a different step depending on its shape: only naming an ineligible provider fails at the data-policy filter, while order with fallbacks off fails at the fallback filter. So treat any non-empty failed_routing_step as a refusal, whatever step it names. An ignore list or a provider ceiling is another filter in the same funnel and should fail at its own step (I haven’t measured those), and a classifier that matches only the data-policy step files that refusal as a plain 404.

Never cache a refusal as an answer. If a step stores its result against a document’s revision, a refusal that returns empty gets stored and never re-read. Raise instead, record a skip, and let the next run read the document again once the setting is fixed. And expect a configuration failure to hit every document alike: a burst of the same error, not a scattering.

4. Record the serving endpoint on every call

The response body’s provider field names the endpoint that served the call. It was present on every response I measured but isn’t in OpenRouter’s documentation; the documented per-call record is /api/v1/generation, which is the fallback if the field ever disappears. Log it per call, reduced to a safe character set (Amazon Bedrock prints as AmazonBedrock). A provider outside the compliant set is a stop-the-line event.

5. Check a model before switching to it

Read OpenRouter’s public list at https://openrouter.ai/api/v1/endpoints/zdr, or send one request with the policy:

printf 'Authorization: Bearer %s\n' "$OPENROUTER_API_KEY" |
curl -s https://openrouter.ai/api/v1/chat/completions -H @- \
  -H 'Content-Type: application/json' \
  -d '{"model":"<model>","messages":[{"role":"user","content":"Reply with the single word ok."}],
       "max_tokens":16,"usage":{"include":true},"provider":{"data_collection":"deny","zdr":true}}' \
  | jq '{provider, error}'

Expect provider to name a compliant host (Amazon Bedrock or Google for Claude, Perplexity, Azure for OpenAI) and no error. The key reaches curl on stdin, so it stays out of the process list. Run it from a script that reads the key itself, never from a command line that lands in a transcript. Then run the repo’s own model tests with the candidate before changing a default, and after the deploy read the provider= field on the log lines.

6. Keep confidential text out of the side doors

Search tools are outside the guarantee. A web-search plugin or a search-native model sends its query to a search backend the provider fields don’t govern, so run a search as its own call with no confidential context in it. OpenRouter’s newer openrouter:web_search server tool lets the model write the query, which is easier to bound than the deprecated plugin, which searches on every request.

Your own telemetry is a side door too. Hosted LLM-observability tools like Langfuse, Helicone, and LangSmith record full prompts and completions once they’re wired into the model client, Sentry’s AI monitoring captures them once its PII collection is on (by default in newer JavaScript SDKs), and OpenRouter’s Broadcast forwards them from the router itself. Each is a party to every call it sees. Keep prompt bodies out of error reports and traces, or list the vendor in the policy file with its terms.

An MCP connector is a side door that faces the other way. If the repo serves one, its tool results land in each user’s conversation with whatever model their client runs, under that user’s plan, and no routing field ever sees them. Return the least that answers the call, and write down in the policy file that the connector’s output is governed by its users’ plans, which for confidential data means commercial ones.

Keep confidential text out of JSON schemas and tool definitions. Anthropic notes that schemas for structured output are “cached separately from message content,” for up to 24 hours since last use. Send bounded excerpts rather than whole documents, mask addresses, and keep private items out of shared material.

Avoid :free models. A count on October 15 found nine of nineteen free models on hosts whose policy allows training on prompts, each with a single endpoint.

Prompt caching stays on. It keeps a prefix in the provider’s memory for the cache’s lifetime (Anthropic: “held in memory for the cache TTL,” which is minutes), and it’s the one place a prompt outlives its request under zdr. OpenRouter doesn’t count that as retention. Definitions differ, though. Google’s zero-retention guidance for Vertex says cached data is deleted no later than 24 hours after it’s written, and lets a project whose policy forbids storing data at rest turn off durable caching (keeping the in-memory kind) or turn caching off entirely. That applies to a customer’s own Vertex project, and whether OpenRouter’s Google project does either isn’t public. OpenRouter’s list flags none of the Anthropic endpoints for implicit caching, and explicit cache breakpoints are in-memory. It’s worth keeping for a roughly tenfold cut in repeated-prefix cost.

One caveat about caching through a router. A provider that isolates its prompt cache isolates it by the account that pays, and through a router that’s the router’s account. A 2025 Stanford audit (Gu et al., ICML) found caches shared across users, beyond a single organization, at 7 of the 17 API providers it tested, detectable from response times; Anthropic’s cache was per organization, and at least five providers changed something after disclosure. OpenRouter doesn’t document whether it keeps its customers’ caches apart. A workshop paper this year (Fahey, “CacheProbe”) reported cross-account cache hits through OpenRouter’s default credentials for OpenAI, Groq, and Fireworks models in late 2025, and found that bringing your own provider key restored isolation. That’s one author, three models, and nearly a year old, and as far as I know nobody has tested Claude on Bedrock or Vertex that way. An attacker has to guess a prompt’s opening to learn anything, so I rate the risk low, but it’s the one place where “in memory isn’t retention” has a side channel.

7. One key per service

Each service gets its own OpenRouter key with a spend limit, read from the environment, never logged, and never pasted into a prompt, a chat, or a command line.

8. Loosening is a security review

Loosening the policy, per call, per model, or per service, is a security review in the repo that does it, plus an exception recorded in the policy file with a human’s decision and the date. Adding a model isn’t a loosening if the model has a zero-retention endpoint; run the checks in rule 5. A new router, or a direct account with a model vendor, is a new use of the data and needs the data owner’s OK first.

For the human: account settings

These live in the OpenRouter dashboard and with its support (the last one in your AI accounts), so an agent should list them for you rather than attempt them.

1. In the privacy settings, turn off providers that may train on inputs (paid and free models have separate switches), and turn on zero data retention enforcement for each model group (Anthropic, OpenAI, Google, other). It covers every key, browser proxies included. Settle any model the policy excludes first, because under enforcement it fails the same way.
2. Confirm both opt-ins read off: Input & Output Logging (observability settings) and OpenRouter Use of Inputs/Outputs (privacy settings, the 1% discount). Check Broadcast in the observability settings too: a destination there gets prompts and completions unless its privacy mode is on.
3. Give each key a guardrail with an allowed-provider ceiling (for a Claude-plus-Perplexity setup: Amazon Bedrock, Google, Perplexity; add Azure only if you use an OpenAI model) and a monthly spend cap. The ceiling also keeps prompts off first-party endpoints run by Chinese companies, which zero retention alone doesn’t.
4. Ask support to hide any app pages created before you sent the hidden header. Name the apps, their origins (OpenRouter groups apps by origin), and every referer you’ve used.
5. Rotate any key that ever appeared in a prompt, and set a spend limit on each.
6. Keep the account’s admins to a few people, each with 2FA on (or SSO, on an Enterprise plan). An admin can turn logging or Broadcast on for every request and no request can tell, so re-check these settings on a schedule.
7. Check your coding agent’s plan, and every personal AI account that touches work. On a consumer plan, turn the model-training setting off (Claude, ChatGPT, Gemini, GitHub Copilot, Perplexity, and Cursor all have one), and move sessions that touch confidential data to commercial terms or your own cloud account.

References:

• Zatloukal, P. (2026). Prose as a Prompt, the pattern the last section uses.
• OpenRouter. Provider routing; Zero data retention and the live list; Data collection; Input and output logging; App attribution; Guardrails; BYOK; Terms, Privacy policy, and DPA. All read October 20, 2026.
• OpenRouter. User tracking; Broadcast; SSO. Read October 20, 2026.
• Anthropic. API and data retention. Updates to consumer terms and privacy policy (2025, August 28); Claude Code data usage; How long do you store my data? and changing the model-improvement setting.
• Consumer training settings. OpenAI, Data controls in ChatGPT. Google, Gemini Apps Privacy Hub. GitHub (2026), Updates to Copilot interaction data usage policy. Perplexity, Data collection at Perplexity. Cursor, Data use. All read October 20, 2026.
• Willison, S. (2025). The lethal trifecta for AI agents.
• Gu, C., Li, X. L., Kuditipudi, R., Liang, P., and Hashimoto, T. (2025). Auditing Prompt Caching in Language Model APIs. ICML 2025. Fahey, R. (2026). CacheProbe: Auditing Prompt Cache Isolation in Gateway APIs. SAGAI '26.
• Amazon. Bedrock data retention.
• Google. Vertex AI zero data retention.
• Microsoft. Azure Foundry data privacy.
• Perplexity. API privacy and security.
• Vercel. AI Gateway zero data retention.
• NIST CAISI (2025). Evaluation of DeepSeek AI Models (September 30). CrowdStrike (2025). Security flaws in DeepSeek-generated code linked to political triggers (November 20). Rager et al. (2025). Discovering Forbidden Topics in Language Models.
• DeepSeek. Privacy policy (February 10, 2026). Amazon. Bedrock data protection. Microsoft. Data privacy for models in the Foundry catalog.
• US House Committee on Homeland Security and Select Committee on the CCP (2026). Letter to Airbnb on PRC AI models (April 29). DHS (2026). Exclusion and Removal Order 2026-01 (Federal Register, October 20). FY2026 NDAA section 1532 and section 6604. Victoria, DeepSeek direction and guideline.
• Anthropic (2025). Updating restrictions of sales to unsupported regions (September 4).
• OpenRouter. Providers API and the zero-retention list, both read October 20, 2026, for the counts and provider labels in Models Trained in China. OpenRouter is joining Stripe (August 19, 2026).
• Apple (2024). Private Cloud Compute. TEE.fail (2025). Cyberhaven (2026). Sensitive enterprise data is flowing into AI tools at scale. VentureBeat (2026). OpenAI’s Private Intelligence (September 29). Thomson Reuters, CoCounsel FAQ. Harvey, Security.
• UK NCSC (2023). ChatGPT and large language models: what’s the risk? NIST (2024). AI 600-1, Generative AI Profile. NYDFS (2024). Cybersecurity risks arising from AI (October 16). Hong Kong SFC (2024). Circular on generative AI language models (November 12). UK ICO, Allocating controllership across the generative AI supply chain. HHS, HIPAA and cloud computing.
• State Bar of California (2026). Practical guidance for generative AI. The Florida Bar (2024). Ethics Opinion 24-1. The Law Society (2026). Generative AI: the essentials.
• United States v. Heppner, No. 25-cr-503 (S.D.N.Y. Feb. 17, 2026), memorandum. Morgan v. V2X, No. 1:25-cv-01991 (D. Colo.), motion to amend protective order (March 2, 2026). Assini v. Hayward, 2026 NY Slip Op 26086 (June 4, 2026).