OpenRouter Security: Data Policy, ZDR, API Keys and Agent Controls
OpenRouter routes model calls for a very large number of teams, and its security posture is genuinely good. The gap is not in the gateway. It is in what your agent does after the model answers.
Direct answer
OpenRouter is a credible piece of production infrastructure from a security standpoint. It holds SOC 2 Type 2, publishes a pentest report through a public trust center, does not log prompts or completions by default, and offers zero data retention enforcement at three levels: globally in account privacy settings, per model group, and per request with a zdr flag in provider preferences. There is no publicly disclosed OpenRouter breach as of September 2026. Three limits are worth knowing before you treat it as your control plane. First, OpenRouter states plainly that provider-level privacy settings have, in its own words, no bearing on OpenRouter policies and what it does with your prompts, so the toggle governs the providers rather than the router. Second, ZDR enforcement applies only to provider routing for inference requests and not to plugins and tools such as web search, which OpenRouter says may be operated by third parties with their own retention policies. Third, and this is the one that matters for agents, OpenRouter governs model access: which provider, which data policy, which key, how much spend. It does not see which tool an agent invokes with the answer, which internal API it hits, or whether an irreversible action got a human gate. This page cites OpenRouter documentation directly, and the comparison table below has rows where the honest answer is that we are not the thing you need.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
OpenRouter usually arrives the same way every good gateway does. Someone wants to try three models without three contracts, so they point a service at it. Six months later it is the single path a dozen agents take to reach a model, it holds provider keys, and the keys that were created for an experiment are still live in production. The security review then asks a question the gateway cannot answer: when the support agent decided to issue a refund, or the coding agent decided to push a branch, what authorized that action? OpenRouter logged a completion. It did not see the tool call, because the tool call never went through it.
How Agentshield handles it
Treat OpenRouter as the model-access control plane and put a second control on the action path. On the OpenRouter side there is real work worth doing: enable ZDR at the account level rather than per request so a forgotten call cannot opt out, use provisioning keys to issue a distinct runtime key per service with its own credit limit and reset interval, keep management keys out of application environments entirely, and remember that enabling BYOK does not relax your data policy, because OpenRouter applies provider, account and guardrail data policies before BYOK endpoints are created. On the action side, the controls have to sit where the agent acts rather than where the model is called: a scoped identity per agent so a compromised prompt cannot reach a tool the agent was never granted, an approval gate on irreversible operations such as payments, deletions and production writes, and an append-only record of attempted actions kept somewhere the agent host cannot rewrite. The two layers do different jobs and most teams running agents in production end up with both.
The controls
The controls that secure the agents your teams route through OpenRouter, and the tools they call next.
Is OpenRouter safe to use? The security record as of September 2026
Short version: yes, with the usual caveats about how you configure it. The longer version is worth reading if you are putting it in front of agents that act.
OpenRouter maintains a public trust center where it publishes its compliance posture, including SOC 2 Type 2 and a penetration test report. That is more transparency than most gateway vendors offer, and it means a security review does not have to take marketing copy on faith. On default data handling, OpenRouter does not log prompts or completions; it retains request metadata such as timestamps, the model used, token counts and latency for billing and operational purposes.
On the question people actually type into search: there is no publicly disclosed OpenRouter security breach as of September 2026. We looked, and we would say so here if there were, the same way this site documented the LiteLLM PyPI compromise in detail. Absence of a disclosed incident is not the same as a guarantee, but it is the honest state of the record.
| Question a security review asks | Where OpenRouter stands |
|---|---|
| Is there a compliance attestation we can read? | Yes. SOC 2 Type 2 and a pentest report via the public trust center |
| Are prompts logged by default? | No. Request metadata is retained for billing and operations |
| Can we force zero-retention providers only? | Yes, at account level, per model group, or per request |
| Has there been a disclosed breach? | None publicly disclosed as of September 2026 |
| Does it govern what agents do with the output? | No. That is a different layer and a different control |
The last row is the one that decides whether you need anything else, and it is covered in full further down this page.
OpenRouter data policy and ZDR: what it covers, and three things it does not
Zero data retention is the control most enterprise buyers care about, and OpenRouter implements it more carefully than the usual single switch. It defines ZDR as a state where a provider will not store your data for any period of time, and providers under ZDR also cannot train on it. It separates retention from training, because some endpoints retain without training, typically for abuse scanning or legal compliance, and gives you controls for both.
You can enforce it three ways. Globally, with a toggle in account privacy settings that restricts all requests to ZDR endpoints. Per model group, so you can hold a stricter line on one vendor family than another. Or per request, by including a zdr flag set to true in the provider preferences of an individual API call.
OpenRouter also fails safe on ambiguity, which is a genuinely good design decision and worth quoting: "If OpenRouter is not able to establish or ascertain a clear policy for a provider or endpoint, we take a conservative stance and assume that the endpoint both retains and trains on data." Most vendors resolve unknowns in their own favor. This one does not.
Now the three limits.
| Limit | What OpenRouter says | What it means for you |
|---|---|---|
| The toggle governs providers, not the router | The privacy setting "has no bearing on OpenRouter own policies and what we do with your prompts" | Read the OpenRouter privacy policy separately. The provider filter does not answer questions about OpenRouter itself |
| ZDR does not extend to plugins and tools | ZDR enforcement "only applies to provider routing for inference requests. It does not apply to plugins and tools you choose to enable, such as web search" | If you enable web search or similar, a third party with its own retention policy is now in the path. Audit what is switched on |
| Provider caching is not counted as retention | In-memory prompt caching at provider datacenters is not treated as data retention under ZDR | Reasonable, and standard across the industry, but say so explicitly if your data protection review asks about transient copies |
None of these are gotchas. OpenRouter documents all three itself. They matter because teams tend to enable ZDR once, screenshot the setting for the audit file, and assume the entire request path is covered when the plugin surface is not.
OpenRouter API key security: provisioning keys, per-key limits and BYOK
Key sprawl is the most common real-world failure on any gateway, and it is the part of OpenRouter security you have the most direct control over.
OpenRouter separates administrative credentials from runtime ones. You create a management key from the management keys settings page, and that key is used only for administration: as the documentation puts it, "Management keys cannot be used to make API calls to OpenRouter completion endpoints, they are exclusively for administrative operations." That separation is useful, and it also means a management key leaking is an entirely different severity of incident from a runtime key leaking, because it can mint and delete keys.
With a management key you can drive key lifecycle through the keys API: list keys with pagination, create keys with an optional credit limit, retrieve a specific key by its hash, update name, disabled status and limit reset schedule, and delete keys outright. Limits reset daily, weekly or monthly at midnight UTC.
That combination supports the pattern worth adopting: one key per service or per agent, never one key per team, each with a credit ceiling sized to what that workload should plausibly spend. A key with a 50 dollar monthly ceiling that leaks is a bounded incident. A shared unlimited key that leaks is not.
| Practice | Why it matters |
|---|---|
| Issue one runtime key per agent or service | Revocation stops being an outage. You disable one key instead of rotating a credential twelve things depend on |
| Set a credit limit on every key | Turns a leaked key from an open tab into a capped loss, and a limit breach becomes a detection signal |
| Keep management keys out of application environments | A management key in a container environment turns any read-anything bug into full key control |
| Use limit reset intervals deliberately | Daily resets on experimental workloads surface runaway loops within a day rather than at month end |
| Do not treat BYOK as a policy relaxation | Provider, account and guardrail data policies are applied before BYOK endpoints are created |
On BYOK specifically: OpenRouter states that "your provider keys are securely encrypted and used for all requests routed through the specified provider," and BYOK usage carries a 5 percent markup, with provider-key allowances tied to monthly list-price thresholds of 25,000 US dollars for pay-as-you-go accounts and 200,000 US dollars for enterprise. BYOK also supports filters that restrict a key to particular models, API keys or workspace members, which is a real access-control primitive and underused.
Where OpenRouter stops: model access versus agent action
This is the section that decides whether you need a second layer, and it deserves a straight answer rather than a sales pitch.
OpenRouter controls the model call. It authenticates the caller, picks a provider under your data policy, enforces your key limits, and returns a completion. Everything in that sentence is on the path between your code and a model.
An agent does something different. It takes the completion and acts: calls a tool, hits an internal API, writes to a database, sends an email, opens a pull request, issues a refund. That traffic does not go through OpenRouter. The gateway has already returned its response and is out of the loop. So when a prompt injection buried in a support ticket or a scraped web page convinces an agent to exfiltrate a customer list, the model call that produced that decision looks completely ordinary in the gateway logs, because it was ordinary. The abnormal part happened afterward, somewhere OpenRouter never sees.
| Control | OpenRouter | Agentshield | Who should own it |
|---|---|---|---|
| Multi-provider model routing | Yes, and this is its core strength | No | OpenRouter. We do not compete here |
| Provider data policy and ZDR enforcement | Yes, three enforcement levels | No | OpenRouter |
| Spend control and per-key credit limits | Yes, via provisioning keys | No | OpenRouter |
| Which tools an agent may invoke | Not visible to it | Yes, scoped per agent identity | An action-path control |
| Human approval before irreversible actions | No | Yes | An action-path control |
Three of those five rows say buy OpenRouter, and one says we do not compete at all. That is the accurate picture. If your use of OpenRouter is chat completions returning text to a person, the gateway plus sensible key hygiene is genuinely sufficient and you do not need us. If an agent takes that output and acts on production systems, the enforcement point has to move to where the action happens.
If you are still choosing a gateway rather than securing one, the buyer comparison in our guide to LLM gateway security software sorts the category by what each product actually enforces. The same wedge applies to the self-hosted option, covered on our LiteLLM security page, and the broader pattern is on our AI gateway security page.
FAQ
Common questions about openrouter security.
Is OpenRouter safe to use?
Yes, for what it does. OpenRouter holds SOC 2 Type 2, publishes a pentest report through a public trust center, does not log prompts or completions by default, and can restrict routing to zero-retention providers. There is no publicly disclosed breach as of September 2026. Safety for agent workloads depends on controls that sit after the model call, not on the gateway.
Has OpenRouter had a security breach?
No publicly disclosed security breach as of September 2026. OpenRouter publishes its compliance posture and a penetration test report through a public trust center, which is where a current answer should be checked rather than relying on this page. No disclosed incident is not a guarantee of none, but it is the state of the public record.
Does OpenRouter store my prompts?
Not by default. OpenRouter does not log prompts or completions by default and retains request metadata such as timestamps, model used, token counts and latency for billing and operational purposes. Individual providers you route to have their own retention policies, which is what the zero data retention controls are for.
What is OpenRouter zero data retention?
ZDR restricts routing to providers that will not store your data for any period, and those providers also cannot train on it. You can enforce it globally in account privacy settings, per model group for vendor families such as Anthropic, OpenAI or Google, or per request by setting a zdr flag to true in provider preferences.
Does OpenRouter train on my data?
OpenRouter routes to providers rather than training models itself, and it states that if you opt out of training in account settings it will not route to providers that train. Note its own caveat that provider-level privacy settings have no bearing on OpenRouter policies for your prompts, so read the OpenRouter privacy policy separately from the provider filter.
Is OpenRouter SOC 2 compliant?
Yes. OpenRouter maintains SOC 2 Type 2 and publishes supporting material, including a penetration test report, through its public trust center. For a vendor review, request the current report through that trust center rather than citing a third-party summary, since attestation periods and scope change between audit cycles.
How do I rotate OpenRouter API keys?
Use a management key against the keys API. It supports listing keys with pagination, creating keys with optional credit limits, retrieving a key by hash, updating name, disabled status and limit reset schedule, and deleting keys. The practical pattern is one runtime key per agent or service so revocation disables a single workload rather than causing an outage.
Does ZDR cover web search and plugins?
No, and OpenRouter says so explicitly. ZDR enforcement applies only to provider routing for inference requests and does not apply to plugins and tools you choose to enable, such as web search, which may be operated by third-party services with their own data retention policies. Audit which plugins are enabled before treating ZDR as end to end.
Is OpenRouter safe for enterprise agent workloads?
For model access, provider governance and spend control, yes. For agents that act, it is incomplete by design, because the tool calls, internal API requests and production writes an agent makes never traverse the gateway. Those need a scoped identity per agent, an approval gate on irreversible operations, and an audit record kept off the agent host.
Does Agentshield replace OpenRouter?
No. OpenRouter handles multi-provider routing, data policy enforcement and key-level spend control, and we do none of those things. We govern what an agent is allowed to do with a model response: which tools it may call, which actions require human approval, and what gets recorded. Teams running production agents commonly run both.
More use cases