TrueFoundry vs OpenRouter: Data Retention, Policy, and AI Governance (2026)

OpenRouter ZDR is the first thing most teams reach for when a security review asks where their prompts end up, and it is worth being exact about what it buys. ZDR restricts a request to providers that do not store prompts or responses. It governs the provider's retention, not OpenRouter's, and it is one control inside a wider question that an AI gateway has to answer: what is allowed, where may data sit, what is kept, and who can prove it afterwards.

This post covers the governance and policy heading of our TrueFoundry vs OpenRouter series: how policy is expressed, scoped, tested and versioned; allow and deny lists; prompt-, tool- and parameter-level restrictions; data residency for data at rest; logging policy and masking; retention and deletion; and the change audit trail. It is written for the platform engineer who has to implement the rules and the compliance lead who has to defend them, and every claim is drawn from the two vendors' public documentation.

At a glance

What OpenRouter ZDR actually does, and does not do

OpenRouter ZDR ensures that providers do not store prompts or responses. It is enforceable globally, per model group (Anthropic, OpenAI, Google, SpaceXAI and non-frontier) through guardrails, or per request using the ZDR parameter. Separately, provider.data_collection: "deny" routes requests only to providers that do not collect user data, settable per request or as an account-wide default in privacy settings. The two are controlled independently because they are different promises: some endpoints do not train on your data but do retain it for abuse scanning or legal reasons, so an OpenRouter data policy that says "no training" is not the same as one that says "no retention".

Three limits define the control. ZDR does not extend to plugins and tools you enable, such as web search, which may be operated by third parties with their own retention policies. ZDR governs the provider's retention, not OpenRouter's own; OpenRouter's content retention is a separate workspace-level logging switch, covered below. And OpenRouter data retention for request metadata (timestamps, model, token counts, latency) continues for billing and operations with no stated duration and no configurable period. The signed DPA available to Enterprise customers covers the ZDR configuration, which is the right place for a compliance team to anchor it.

TrueFoundry has no ZDR feature, and the reason is structural rather than a gap: you bring your own provider keys, so your provider's retention terms are the ones you negotiated, and the equivalent control is which provider account a team is allowed to use. Where the two products do overlap is on OpenRouter zero data retention as a routing policy versus TrueFoundry's provider-account grants as an access policy, and that is the shape of everything on this heading: OpenRouter steers traffic, TrueFoundry authorises it.

The policy engine: guardrails vs rule sets

OpenRouter guardrails are the policy engine. A guardrail is a named rule object, created in Workspaces → Guardrails or through the Management API (create, update, delete, list, assign to keys or members), composing a budget limit, model allowlist, provider allowlist, ZDR per model group, regex prompt-injection detection, Sensitive Info (PII presets plus NLP detection) and custom regex content filters. In an organisation only admins manage guardrails; account-wide privacy policies and provider restrictions are inherited, and a guardrail can only be more restrictive. The composition semantics are documented per rule type, which deserves credit: allowlists intersect (strictest wins), ZDR is OR'd per model group, Sensitive Info filters union with block beating redact, and budgets are checked separately per layer rather than merged. Expression is UI forms plus REST; there is no policy language, no YAML and no GitOps path. Pre-rollout testing is partial: a flag action records a detection without enforcing it, but only for the regex injection filter; PII rules accept block or redact, and budgets and allowlists have no dry run.

TrueFoundry expresses policy as UI-built rule sets with YAML equivalence ("Apply as YAML" in every rule form), grouped into four families under AI Gateway → Policies: Guardrails, Budget Limiting, Logging Config and Rate Limiting. All four share one scoping model: subjects (user, team, virtual account), models including virtual models, MCP servers and tools, provider accounts, and X-TFY-METADATA key-values (guardrails configuration). Budgets have a simulate API that returns which rules would match a hypothetical request before you commit it, and guardrails run in monitor or warn mode before enforcement (simulate budgets). For the cases a form cannot express, Cedar policy and OPA policy guardrails let you write the rule as code (Cedar, OPA). Evaluation semantics differ per family and we quote them exactly: budgets AND every matching rule, rate limits are first-match-wins, logging is deny-wins.

Two things neither vendor documents, and we say so plainly: versioning of policy rules (no draft and publish, no rollback, no history) and an approval workflow for policy changes (edits by authorised admins take effect on save, with no four-eyes control). Enterprise API-management products have change-management stories here. Neither of these two gateways does yet.

Allow lists, deny lists, and tool- and parameter-level policy

OpenRouter has allowed lists only. A model allowlist and a provider allowlist, with empty meaning allow all, and no deny-list primitive. Per team works via workspace-scoped guardrails or per-member assignment; per environment has no mechanism because there is no environment object. The operational cost of allowlist-only is real: when a new model ships, every guardrail must be edited to permit it, whereas a deny list would admit it automatically. Safer default, higher maintenance, and at forty applications a standing administrative chore. Tool-level policy does not exist; OpenRouter operates its own server tools, but no per-tool grant, restriction or consent control is documented, and plugins sit outside ZDR. Parameter-level policy is not documented either; nothing restricts temperature or max_tokens, and provider.max_price is a routing constraint, not a policy.

TrueFoundry has both directions. RBAC grants are the allow list (a team only sees and calls models it has been granted), and policy rules add IN and NOT IN conditions on models per subject, with per-environment expression through metadata (environment: production) or per-environment virtual accounts (gateway access control). Tool-level policy targets specific MCP servers and individual tools, with pre-invoke and post-invoke hooks. Parameter-level policy comes from a metadata-validation guardrail that enforces required request metadata, and from Cedar and OPA rules that can be written against request parameters. We flag one thing for the editor and for buyers alike: a concrete parameter restriction such as blocking a temperature above 1 should be verified hands-on before it is claimed generally.

AI data residency: where traces actually rest

Residency is a data-at-rest question, not a networking one, and the two vendors answer different questions.

TrueFoundry Data Routing (AI Gateway → Controls) chooses where traces live: control-plane-managed storage with region selection on SaaS, or customer-managed object storage in your bucket and your region. The Enterprise plan adds conditional routing with multiple destinations matched top-down on metadata or caller identity, so the EU team's traces go to an EU bucket and everything else to the default (data routing). A per-region datastore is a real deployment option, not a single-region drain. Two caveats we state: metrics always go to the default destination and are kept forever, with no residency control; and in self-hosted mode residency is trivially yours, because nothing leaves. For teams already running models in their own environment, our guide to on-premise LLM deployment covers that end of the spectrum.

OpenRouter's in-region routing is mostly a processing-location answer: for Enterprise customers, prompts and completions are decrypted and processed within the selected region, EU or US. The default at-rest position is that little is at rest, because content is not stored, but where the retained metadata lives, and in which region, is not documented. Opt-in Input & Output Logging stores content in an isolated Google Cloud Storage project whose region is not stated. And the sharpest finding on the heading: Input & Output Logging does not apply to requests routed through the EU or US endpoints, so in-region routing and stored prompt content are mutually exclusive. An enterprise buyer who wants EU residency cannot also have prompt-level debugging or audit through the platform.

Logging policy and masking: the matrix

This is the most differentiated capability on the heading, so we state it as a matrix rather than a yes or no.

TrueFoundry Logging Configs are named rules with AND-ed conditions on subjects, models and metadata. Each rule carries a log on/off toggle and redaction patterns drawn from a predefined catalogue (email, US SSN, credit card, India Aadhaar and PAN, and more) plus custom regex with custom replacement text. All matching rules are evaluated, deny wins (one matching rule with log off suppresses the body), and redactions merge across matching allow rules. Redaction applies only to the stored copy; the live request to the provider is never modified by this feature. A per-request X-TFY-LOGGING-CONFIG header acts as a fallback when no rule matches, metadata, cost, tokens and latency are always recorded, and each trace records tfy.logging.prompt_logging_enabled and matched_config_names, so the logging decision itself is auditable (logging config). The direct answer: per-request logging decision, yes; mask before store, yes; varied by team, developer, model, environment and regex match, yes.

All of it is enforced on a stateless gateway plane at roughly 3–4 ms of added latency and 350+ requests per second per vCPU across 2,500+ LLMs.

OpenRouter: decide per request whether to log, no, because Input & Output Logging is a workspace-level toggle only admins can change. Mask before logging, no. Vary by team, only insofar as workspace equals team. By developer, model, environment or regex match, no. One boundary to keep crisp: the redaction OpenRouter does have (Sensitive Info presets and custom regex) modifies the live request before the provider sees it. That is request-time redaction, which we cover in the security post, not log-time masking; you cannot configure "log everything, mask this" independently of what the provider receives, because the two are the same control. The ZDR parameter governs provider-side retention, not OpenRouter's logging, and should not be mistaken for a logging policy.

Retention, erasure and the AI audit trail

TrueFoundry trace retention is configurable per data-routing destination, with a default policy when unset. Metrics are kept forever and are not configurable. Right-to-erasure of specific logged requests is not documented as an in-product workflow; with customer-managed storage you own the bucket, so deletion is mechanically yours. On the admin audit trail we are direct: our documentation's audit language is about agent and request activity, and a who-changed-which-policy-when trail with export is not documented, although the pricing page lists audit logs at Enterprise. Ask us to demonstrate it rather than take the line item on trust (data routing, pricing).

OpenRouter's default content retention is none; metadata is retained for billing with no stated duration and no configurable period; retention windows on stored prompts and right-to-erasure are not documented. An audit log exists: the SCIM Group Mappings documentation states that when a group is deleted in the identity provider and members lose access, the removals are recorded there. Its scope, retention, viewing interface and export are not documented, no dedicated audit-log page appears, and whether it covers configuration changes such as guardrail edits rather than membership changes only is undetermined. Activity Export produces usage data as CSV or PDF grouped by model, key or member; it is a usage report, not a change audit. For how an AI audit trail fits a wider governance programme, our explainer on AI governance covers the framework.

TrueFoundry vs OpenRouter: governance and policy head-to-head

TrueFoundry capabilities are from our documentation; OpenRouter capabilities reflect its publicly documented functionality at the time of writing.

When to choose OpenRouter

• Your governance needs are allowlists, per-key budgets and request-time PII redaction, and the people who set policy are the same admins who run the account.
• Provider retention is the risk you care about most, and a per-request guarantee that the provider keeps nothing is worth more to you than control over your own gateway's logs.
• You can live with EU residency or prompt-level audit, but not both, because the regional endpoints exclude content logging.

When to choose TrueFoundry

• Policy has to be code reviewed and applied as YAML, with Cedar or OPA for the rules a form cannot express and a simulate call before anything goes live.
• You need deny lists so a new model does not require editing every rule, and policy that reaches your own MCP tools and request parameters.
• Traces must rest in a region you choose, per team, and the logging decision must vary by team, model and request, with masking before storage and a record of which rule decided.
• An auditor will ask which rule applied to a given trace, and LLM governance in your organisation has to produce that answer from the gateway rather than from a spreadsheet.

On either side, press the vendor on policy versioning, change approval and an exportable admin audit trail; neither documents them today. For the wider field of gateways, see our guide to OpenRouter alternatives.

Related reading

• What is AI Governance? — the framework this post's policy engine sits inside
• What is AI Compliance? — turning policy into evidence
• On-Premise LLM Deployment — the self-hosted end of the residency spectrum
• What is an LLM Gateway? — the architectural primer
• OpenRouter Alternatives — the wider field of enterprise options

Conclusion

OpenRouter ZDR is a well-specified control over something most gateways cannot touch, the retention policies of providers you never signed with, and OpenRouter's guardrails come with the clearest composition rules in the category. They are bounded by a flat identity model, allow lists only, no tool or parameter policy, and a logging switch that is on or off for a whole workspace. TrueFoundry's governance is a policy engine: one scoping model across budgets, limits, guardrails and logging; YAML, Cedar and OPA; deny lists; tool-level hooks; conditional residency; and a logging matrix that records its own decisions. Both leave the same three enterprise rows undocumented. For a platform team that has to show its work, the decision on this heading is not close.

To see a logging policy, a deny list and a per-region trace route configured together, explore the TrueFoundry AI Gateway, or book a demo if you are designing governance for a multi-team rollout now.