Is OpenRouter a security product?

It is a model-access and cost-governance layer that has grown a real guardrails feature set. Its guardrails do PII detection, prompt-injection screening, model and provider allowlists, and per-key budgets, and blocked requests return a structured decision record. What it is not is an identity-aware enforcement layer tied to your identity provider, and it holds no signed, tamper-evident audit record. Treat it as strong routing with real content policy, running inside a SaaS you route through.

What does OpenRouter's policy bind to?

To an API key, or to an org member who owns keys. Guardrails are assigned to members and keys, and budgets accumulate against the owning member. The request itself carries no verified identity assertion, and application attribution uses self-declared headers that a caller can set freely. This is the sharpest difference from identity-bound enforcement: OpenRouter answers which key made the call, and identity-bound policy answers which verified person or agent made it.

Does OpenRouter keep an audit trail?

By default OpenRouter stores no prompts or responses, which is a privacy stance rather than an audit stance. Opt-in Input and Output Logging stores full prompts in an isolated store with AES-256 at rest, retained at least three months and visible to org admins. On a guardrail block it returns a pipeline array describing the stages that ran. None of these is a signed, tamper-evident, append-only per-decision record, and a no-retention default and a provable-decision record pull in opposite directions.

Can I run DeepInspect in front of OpenRouter?

Yes, and for a regulated team it is a sensible pattern. DeepInspect sits at the AI request boundary inside your environment, binds the call to a verified identity, classifies the prompt, applies policy, and commits a signed record before the request leaves for OpenRouter. OpenRouter then handles model access, routing, and failover. You keep OpenRouter's breadth and add an identity-bound evidence layer that lives on your own infrastructure.

Which fits a regulated enterprise?

If the enterprise can route prompts through a third-party SaaS and mainly needs breadth and cost control, OpenRouter fits well. If it needs identity-bound policy tied to its own identity provider, verifiable independent audit records, or enforcement inside its VPC, those requirements point to a self-hosted layer. Many regulated teams run both: OpenRouter for access, DeepInspect for the identity-bound decision and the record an auditor will inspect.

DeepInspect vs OpenRouter: Key-Bound Convenience and Identity-Bound Evidence

OpenRouter is a hosted, OpenAI-compatible API that fronts more than 400 models across 50-plus providers behind one key and one bill. It does price, throughput, and latency-weighted routing, automatic failover, bring-your-own-key, prompt caching, and structured outputs. It has also grown a real policy layer, Guardrails, which does PII detection, prompt-injection and jailbreak screening, model and provider allowlists, and per-key budgets. Anyone who still says OpenRouter has no security features is working from an old snapshot.

So this comparison is not routing versus guardrails. Both have policy. The comparison is about what the policy binds to and what record survives the decision. OpenRouter binds policy to an API key inside a multi-tenant SaaS you route through. DeepInspect binds policy to an identity and commits a signed record on infrastructure you run. That difference decides which one a regulated deployment can stand behind.

TL;DR

OpenRouter is the strongest hosted model-access and cost-governance layer available, and its guardrails are genuine. Its policy attaches to an API key, its identity model authenticates keys rather than your users, and its logging is opt-in observability retained on OpenRouter or shipped to your APM. DeepInspect binds policy to the natural person or agent, classifies prompt content across regulated data types, and commits a signed per-decision audit record on a write path you control. Different layers for different jobs.

OpenRouter: what it is and where it sits

OpenRouter's core value is breadth and convenience. One integration reaches hundreds of models, switching cost between them is close to zero, and the provider routing controls are precise: order, allow_fallbacks, sort by price or throughput or latency, and data_collection: "deny" to route only to providers that do not store or train on your data. Zero Completion Insurance means you are not charged for empty completions. BYOK runs your own provider keys at 5% of the equivalent OpenRouter cost.

The Guardrails layer is assignable to org members and individual keys, and it composes budget limits, model and provider allowlists, zero-data-retention enforcement, regex-based prompt-injection detection, and PII detection with redact or block actions. A blocked request returns 403, and with router metadata enabled the response carries a pipeline array naming each guardrail stage that ran, its guardrail_id, and the matched patterns. That is a machine-readable per-decision record, returned to the caller.

What DeepInspect is and where it sits

DeepInspect is a stateless proxy at the AI request boundary that you deploy inside your own environment. It evaluates identity-bound policy per request, classifies prompt content against the regulated data types the organization recognizes, and commits a signed per-decision audit record with cryptographic integrity. Deterministic, fail-closed, model-agnostic in front of any HTTP LLM endpoint including OpenRouter itself.

The primitives point at enforcement and evidence: natural-person or agent identity taken from the application; per-route and per-role policy; prompt-level classification across PII, PHI, MNPI, source code, and jurisdictional categories; a pass, block, or modify decision before the request leaves your environment; and a signed audit record shaped for regulatory review.

Where the two separate

Three differences carry the decision.

Identity. OpenRouter's primary auth is the API key. Provisioning keys manage other keys, and OAuth PKCE logs your end user into OpenRouter and mints them a user-controlled OpenRouter key. That is not your identity provider asserting a verified identity into the request. Guardrails attach to a member or a key, so there is a member-to-key-to-request chain, but the request itself carries no identity assertion, and app attribution rides self-declared, spoofable HTTP-Referer and X-Title headers. DeepInspect binds the natural-person or agent identity into every decision and every record.

The record. OpenRouter's default posture stores no prompts or responses unless you opt into logging, which is a strong privacy stance. Opt-in Input and Output Logging keeps full prompts in an isolated store, AES-256 at rest, retained a minimum of three months, viewable by org admins. None of these is a signed, tamper-evident, append-only per-decision record. There is a real tension worth naming: a design that retains nothing by default cannot also prove what it decided. DeepInspect resolves that tension by committing a signed decision record without retaining prompt content it is not asked to.

Location. OpenRouter's enforcement runs inside a multi-tenant SaaS in the path of every prompt. Its strongest compliance controls, a DPA and EU in-region routing through eu.openrouter.ai, are enterprise-tier and by request, and OpenRouter states it is SOC-2 compliant without a public report type I could verify. DeepInspect runs in your environment, so the enforcement point and the record never leave your control boundary.

Feature comparison

| Capability | OpenRouter | DeepInspect | |---|---|---| | Model breadth | 400+ models, 50+ providers | Forwards to any HTTP LLM, including OpenRouter | | Routing and failover | Price, throughput, latency, fallbacks | Out of scope | | Guardrails | PII, prompt-injection, allowlists, budgets | Identity-bound policy + classification | | Policy binds to | API key or org member | Natural person or agent | | Identity source | OpenRouter account keys, OAuth PKCE to OpenRouter | Your identity provider, per request | | Per-decision record | pipeline array returned to caller, unsigned | Signed, tamper-evident, committed before response | | Data retention | None by default; opt-in logging, 3-month min | Decision record without prompt retention by default | | Where enforcement runs | Multi-tenant SaaS in the path | Your environment | | Prompt classes detected | PII presets, custom regex | PII, PHI, MNPI, source code, jurisdictional |

Pick OpenRouter if...

You want one API, one bill, and one contract across 400+ models with near-zero switching cost.
You are a product or AI team optimizing for model breadth, price and latency routing, and uptime through failover.
Cost governance through per-key, per-member, and per-workspace budgets is your main control need.
You want BYOK to use existing cloud commitments while keeping OpenRouter as the routing layer.

Pick DeepInspect if...

You need identity-bound per-request policy tied to your own identity provider, not policy bound to an API key.
You need a cryptographically verifiable, independent audit record for each AI decision.
You cannot accept a third-party multi-tenant SaaS in the path of every prompt, or you need enforcement inside your VPC.
You need prompt classification across PHI, MNPI, and jurisdictional categories for a regulated workload.

Pricing approach

OpenRouter states its model pricing matches provider pricing with no markup, and charges 5% on BYOK usage. Its DPA and EU in-region routing are enterprise-tier. DeepInspect is priced through a sales conversation and deploys self-hosted or managed. The two are not substitutes on price, because they sell different things: OpenRouter sells access and routing, DeepInspect sells enforcement and evidence.

DeepInspect

This is the gap DeepInspect closes, and it composes cleanly with OpenRouter rather than replacing it. A team can keep OpenRouter as the model-access layer and put DeepInspect at the AI request boundary in front of it.

In that arrangement, DeepInspect binds each call to the verified identity your application supplies, classifies the prompt against the regulated categories your sector recognizes, applies per-route policy, and commits a signed decision record inside your environment before the request ever reaches OpenRouter. OpenRouter then does what it is strong at: reaching the right model at the right price with failover. You get breadth from OpenRouter and identity-bound evidence from DeepInspect, and the record that an auditor inspects lives on infrastructure you run. If you route through OpenRouter and you are facing the August EU AI Act deadline, book an audit at deepinspect.ai.