TrueFoundry vs OpenRouter: Security, Compliance, Guardrails, BYOK, SOC 2 and HIPAA Compared (2026)

Any OpenRouter security review starts with the same fact, so this post does too: with OpenRouter, prompts, responses and metadata leave your network on every request, cross to OpenRouter, and cross again to whichever provider serves the call. Everything else on this heading (how provider keys are held, what the guardrails catch, how vulnerabilities are handled, what certifications exist) sits downstream of that boundary question, and it is where an AI gateway you can run inside your own network diverges from one you cannot.

This post covers the security and compliance heading of our TrueFoundry vs OpenRouter series: what data leaves the boundary, provider key handling and BYOK, encryption and network posture, PII redaction on the live request, guardrails (built-in, bring-your-own, third-party), prompt-injection defence, vulnerability handling, certifications, and which controls sit behind a paid tier. It is written for the security engineer running the review and the sales engineer who has to answer them, and every claim is drawn from the two vendors' public documentation.

At a glance

OpenRouter security starts with one fact: everything leaves

There is no OpenRouter configuration in which prompts stay inside your network, because there is no self-hosted mode. Content crosses two boundaries, yours to OpenRouter and OpenRouter to the provider, and what you control is where it goes and whether it is retained, not whether it leaves. In-region routing (Enterprise, EU or US) constrains the jurisdiction of decryption and processing; zero-data-retention routing restricts requests to endpoints that do not retain; provider pinning constrains which company receives the data. Two precision points for an enterprise reader: OpenRouter does not train on API data, but each upstream provider may have different terms for API versus consumer use, so the second hop inherits a policy you have to check per provider; and ZDR does not extend to plugins and tools such as web search, which may be operated by third parties with their own retention. For a requirement that reads "no prompt data leaves the boundary", this row is categorical.

TrueFoundry's answer depends on deployment mode, and we give it per mode. In managed SaaS, prompts, responses and metadata transit TrueFoundry infrastructure, mitigated by region selection, your-own-bucket trace storage and logging-off configs. In hybrid mode, the gateway plane runs in your VPC, so prompt and response traffic stays inside; configuration comes down and logs and metrics go up to our control plane. In fully self-hosted mode, nothing on the request path leaves except user emails and request counts to our licensing server (security and compliance).

One caveat travels with every containment claim we make: the built-in PII/PHI guardrail is powered by Azure AI Language and runs on TrueFoundry-managed infrastructure, so a self-hosted customer who enables it sends request content across the boundary they built. The no-egress alternatives are a vendor-hosted guardrail with your own keys or a custom self-hosted guardrail (PII guardrail). How prompts are stored and who can see them once they are inside is the tenancy question, covered in our post on OpenRouter privacy.

OpenRouter BYOK: the fallback nobody reads about

OpenRouter BYOK lets you supply your own provider credentials so that usage lands on your provider account with your rate limits and negotiated terms. OpenRouter states the keys are securely encrypted; they are managed in workspace BYOK settings, each key supports model, API-key and member filters evaluated before routing, and key ordering is explicit (prioritised keys before OpenRouter's endpoints, fallback keys after). The fee is a percentage of what the same model and provider would cost on OpenRouter, above a plan-dependent allowance.

The security finding is the fallback behaviour, and it has two layers. By default, if a BYOK key hits a rate limit or fails, OpenRouter falls back to shared OpenRouter capacity, fulfilled from your credits. Setting "Never use shared capacity on this provider", or the per-key "Always use this key" toggle, prevents fallback to OpenRouter's own key for that provider only. OpenRouter's support documentation states explicitly that this does not prevent fallback to a different provider: if an Anthropic BYOK key fails, OpenRouter will not use its own Anthropic key, but may fulfil the request through Google Vertex on OpenRouter credits. Preventing cross-provider fallback requires routing constraints at the request level, not in BYOK settings. The practical consequence: a team that adopted BYOK to keep inference on a contracted, compliance-reviewed provider account can have traffic served through a different provider entirely on a key failure, unless every call site constrains it. Not documented: where keys are stored, the encryption scheme, whether KMS or customer-managed keys are supported, and rotation handling.

TrueFoundry holds provider keys one of three ways: encrypted at rest in the control plane database; referenced from your own secret manager (AWS SSM and Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault) with hourly auto-sync so that rotation you perform externally propagates; or mounted as Kubernetes secrets. The secret-manager path works for model, MCP and guardrail integrations alike, and in fully self-hosted mode keys never leave your infrastructure (secret managers in AI Gateway). There is no fallback to a vendor key because there is no vendor key; the only keys are yours. Native KMS envelope encryption or BYOK for the control-plane database is not documented, which we flag rather than claim.

On the wire, both products are TLS: TrueFoundry documents TLS 1.2+ in transit and AES-256 at rest on managed infrastructure; OpenRouter documents TLS on its public API. Neither documents mTLS. OpenRouter does not document private networking, IP allow-listing, VPC peering or PrivateLink, which follows from the hosted archetype; TrueFoundry's network posture options are the deployment modes themselves, and in a self-hosted cluster you can add a service mesh, which is your posture rather than the product's.

PII redaction and LLM guardrails: built-in, bring-your-own, third-party

Both products redact PII on the live request, before the provider sees it, which is the question this heading asks (log-time masking is a governance question and lives in a different post).

OpenRouter's Sensitive Info guardrail detects and redacts or blocks PII in API requests using built-in presets (email, phone, SSN, credit card, IP address, person name, address), each set to block or redact, plus NLP-based detection; custom content filters add your own regex patterns. Where several guardrails apply, Sensitive Info filters union across layers, and if one blocks while another redacts, blocking wins. The built-in set covers budget enforcement, ZDR, model and provider restrictions, prompt-injection defence, sensitive-info detection and custom regex, and it is well specified and runs in-path with low overhead. Extensibility is the weak side: bring-your-own means custom regex patterns only, with no hook for executing customer code, no policy language such as Cedar or OPA, and no mechanism to call an external service in the request path, which follows from a hosted router having no execution environment for customer code. Third-party guardrails are not documented in the guardrails guide; Google Model Armor and Lakera Guard have been referenced as beta integrations available by request, but that is not confirmed in first-party documentation.

TrueFoundry's PII/PHI guardrail runs on the LLM input hook in mutate mode (detected entities are redacted and the request continues), is context-aware with configurable entity categories, and also runs on LLM output and on MCP pre- and post-tool hooks; secrets-detection and regex-pattern guardrails are usable at request time in mutate mode as well (PII guardrail). LLM guardrails on TrueFoundry cover all three categories. Built-in, managed with zero setup: PII/PHI, content moderation, prompt injection, secrets detection, regex, SQL sanitiser, code-safety linter, metadata validation. Bring-your-own: custom guardrails you host, plus Cedar and OPA policy-language hooks. Third-party, roughly fifteen documented: AWS Bedrock, Azure PII, Content Safety and Prompt Shield, Google Model Armor, NeMo, Guardrails AI, Enkrypt, Lasso, Pillar, F5/CalypsoAI, Noma, CoreWeave Weave and others (guardrails overview, TrueFoundry guardrails). Guardrails attach through policies on four hooks, including MCP tool pre and post, and guardrails on tool calls are a differentiator few gateways in any category have; our post on enterprise AI security with an MCP gateway goes deeper on that layer. All of it executes on a stateless gateway plane at roughly 3–4 ms of added latency and 350+ requests per second per vCPU across 2,500+ LLMs, with the honest footnote that a managed guardrail attached to a route adds its own network hop.

Prompt injection protection

OpenRouter's injection and jailbreak detection is regex-based: more than 30 patterns derived from the OWASP LLM Prompt Injection Prevention Cheat Sheet and other sources, with explicit countermeasures for typoglycemia, encoding-based and character-spaced evasion. Detection is deterministic, overhead is described as negligible, it runs before the request is sent to the provider so blocked traffic never leaves OpenRouter, and it is the one guardrail with a flag (observe-only) mode. The trade-off is the one any regex filter carries: it catches known patterns rather than novel ones.

TrueFoundry ships a dedicated built-in Prompt Injection guardrail (detect-and-block on input), plus third-party options aimed at the same threat: Azure Prompt Shield, Google Model Armor, Lasso and Pillar (prompt injection guardrail). On efficacy we say the same thing about both products: it is vendor-stated until you test it. A small set of known injection payloads thrown at each filter during an evaluation is worth more than either vendor's claim, and we would rather be measured than believed.

Vulnerability handling and patch cadence

TrueFoundry documents responsible disclosure through security@truefoundry.com, 30+ automated security tools run per code change, internal and external penetration testing, and security code review. The patch policy is the quotable part for regulated buyers: a Stable release channel with one designated release per quarter, maintained for six months, with P0/P1 bugs and Critical/High CVEs patched on demand against your Stable version, alongside a Rolling channel for the latest (control plane upgrade). Being closed-source, there is no public CVE trail to audit, which cuts both ways and we say so.

OpenRouter publishes no disclosure process, security contact, patch cadence or CVE history in its documentation. For a hosted closed-source service there is likewise no public CVE trail; a disclosure process and contact may sit behind its Trust Portal, but a buyer cannot confirm that from the public record.

Certifications: SOC 2, HIPAA, GDPR and the DPA

TrueFoundry documents SOC 2 Type II (report under NDA through trust.truefoundry.com), GDPR and HIPAA. ISO 27001 and FedRAMP are not claimed. One scope note our documentation makes itself, and that every self-hosted buyer should read twice: the certifications apply to TrueFoundry's managed infrastructure, and compliance of a self-hosted deployment is the customer's responsibility, as it is for any software you run yourself (security and compliance, LLM info). For a team looking for a HIPAA compliant LLM gateway, the right reading is that the managed service carries the documentation and a self-hosted deployment inherits your own HIPAA programme.

OpenRouter offers a mutually signed, enforceable DPA exclusively to Enterprise customers through the Trust Portal at trust.openrouter.ai; self-serve customers may request portal access to review it for information only, approval takes one to two business days, is handled by a separate team from support and cannot be expedited, and the DPA covers the ZDR configuration. On OpenRouter SOC 2: it is not stated in OpenRouter's public documentation; third-party sources assert it, and the existence of a Trust Portal implies attestation documents are held there, but a buyer should obtain the report rather than infer it. OpenRouter HIPAA, ISO 27001 and FedRAMP are not claimed in any first-party source. OpenRouter GDPR coverage therefore runs through the Enterprise DPA, and nowhere else. For how certifications turn into evidence a reviewer will accept, see our explainer on AI compliance.

What sits behind a paid tier

OpenRouter's gating pattern deserves credit because it is the inverse of the usual one. Free at every tier: guardrails in full, meaning budget enforcement, ZDR, model and provider allowlists, prompt-injection defence, PII detection and redaction. Enterprise-gated: SSO and SCIM, in-region routing, the signed DPA and the higher BYOK allowance. What costs money is not the ability to protect traffic but the ability to evidence it contractually and to connect it to an identity provider. For a solo developer that is close to ideal.

TrueFoundry is a commercial product throughout, so there is no free-open-source story to fall apart, and the wall list is: conditional data-routing destinations and the multi-tenant self-hosted control plane at Enterprise, plus the inherently paid self-hosted and air-gapped modes. SSO and SOC 2 start below Enterprise on our pricing page, and we flag for our own editors that the cell-by-cell tier placement of SSO, SCIM, SOC 2 report access and guardrails should be confirmed on the live page before any "gated at tier X" claim is quoted (TrueFoundry pricing).

TrueFoundry vs OpenRouter: security and compliance 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

• Prompts may transit a third party under your security policy, and the controls you need are protection (PII redaction, injection filtering, provider-side zero retention) without a budget line.
• Evidence can wait. A signed DPA and SSO are Enterprise purchases, and your review does not need them yet.
• You use BYOK and will constrain routing per request so that a key failure cannot move your traffic to a provider you have not reviewed.

When to choose TrueFoundry

• The boundary is the requirement: prompts must stay in your VPC or an air-gapped environment, and you will run a self-hosted guardrail rather than our managed PII guardrail.
• Provider keys must live in your secret manager, rotate on your schedule and propagate automatically, with no vendor key for traffic to fall back to.
• Guardrails must be extensible with your own code, Cedar or OPA, or a named third-party vendor, and must cover tool calls, not only model calls.
• The security review will ask for paper: a disclosure process, a patch cadence, and first-party SOC 2 Type II, GDPR and HIPAA statements, scoped honestly to what the vendor hosts.

Our guide to AI security platforms and gateways covers the wider field if neither of these two is the final answer.

Related reading

• AI Security Platforms and Gateways — the wider field of security tooling for AI traffic
• Enterprise AI Security with an MCP Gateway — guardrails and identity on tool calls
• MCP Server Security Best Practices — hardening the servers your agents call
• What is AI Compliance? — turning controls into evidence a reviewer accepts
• OpenRouter Alternatives — the wider field of enterprise options

Conclusion

OpenRouter security is a fair deal for a developer: every guardrail is free, nothing is stored by default, and the price of that is accepting that data always leaves, that BYOK can route around your provider, and that evidence and identity integration cost extra. TrueFoundry's is the shape a security team expects from infrastructure: containment with two disclosed exceptions, keys in your own secret manager, guardrails you can extend with code and attach to tool calls, a quarterly patch channel with on-demand CVE fixes, and first-party attestations scoped to what we host. On the boundary row, the guardrail-extensibility row and the certifications row, the comparison points the same way, and the PII-guardrail caveat is the one TrueFoundry claim that must always carry its footnote.

To see guardrails, secret-manager-backed keys and the hybrid boundary configured together, explore the TrueFoundry AI Gateway, or book a demo if a security review is already on the calendar.