AI Gateway
in/guard/out vs OpenRouter Guardrails
OpenRouter’s Workspace Guardrails govern the traffic a router controls: spend caps per key or member, model and provider allowlists, zero data retention, data regions, a free regex screen for prompt injection, and sensitive-info detection that redacts or blocks PII. AI-powered injection detection from Google Model Armor or Lakera is in beta. It is genuinely useful – and all of it runs on the request, before it leaves for the model.
in/guard/out works the other side of that line. It fronts OpenRouter as an ordinary OpenAI-compatible upstream, so the workspace rules keep running underneath, and it adds what a request screen can’t see: the model’s response, the agent’s tool calls, and the run they add up to.
Side by side
| Capability | OpenRouter Guardrails | in/guard/out |
|---|---|---|
| Where checks run | On the request, before it is forwarded | Request and response |
| Model responses | Not scanned – sensitive info “does not scan model responses” | Grounded, fact-checked, safety-screened, format-checked |
| PII after detection | Redacted to [EMAIL]-style labels, or blocked – never restored | Stable placeholders, restored on response |
| Hallucination & numeric grounding | — | Deterministic grounding + claim audit |
| When a check fails | Flag, redact, or block | Repair where safe: the number, the JSON, the PII |
| Output format (JSON schema) | — | Validate and repair |
| Injection in tool results | Regex covers user-supplied message content | Tool results scanned before re-entering context; actions grounded anyway |
| Agent tool calls the model emits | Forwarded as payload | Allow/deny, schemas, permission tiers, sequence policies |
| Budgets | USD caps per key or member, daily to monthly | Per-run cost, step, and tool-call caps, reserved before the call |
| Run visibility | Guardrail activity per request | A reconstructed run graph with cost burn-down |
Based on OpenRouter Guardrails’s publicly available information. We’ve done our best to keep it accurate, but details may have changed since we last looked. If you’ve noticed an error, please email us.
A request screen and a run governor
OpenRouter’s guardrails are built for the job a router can do well: decide who may spend, on which models, in which region, with what retention, and keep obvious injections and raw PII from leaving. Those are access and egress rules, and they compose. A key’s spend cap, its allowlist, and its ZDR setting stay exactly where they are when traffic passes through in/guard/out first.
What they don’t attempt is the outcome. A redacted name comes back to your user as [PERSON_NAME]; a figure the model changed from the source ships as written; a payment tool call with an invented IBAN is forwarded like any other payload. in/guard/out screens and restores PII, grounds every number against the source, repairs what it safely can, and holds the agent’s actions to tiers, grounding, taint, and per-run budgets.
Frequently asked questions
OpenRouter has guardrails now – do I still need in/guard/out?
For different work. OpenRouter governs access – spend, models, providers, retention, region – and screens requests for injection and PII. in/guard/out checks the response and the actions: grounding, fact-checking, format repair, PII restore, tool policy, and run budgets. Keep both; they don’t overlap much.
What about the Model Armor and Lakera options?
They put a classifier behind OpenRouter’s regex screen, which helps catch injections that patterns miss. They are in beta, and they still screen the request. in/guard/out’s injection defense also scans tool results – where indirect injection arrives – and, for the attempt every scanner misses, checks the resulting action against the run’s sources and permission tiers.
OpenRouter redacts PII – how is that different from screening?
Redaction is one-way: the model sees [EMAIL], and so does your user. in/guard/out swaps values for stable placeholders the model can reason over, then puts the real values back on the way out. Taint tracking keeps a screened value from leaving through a tool argument later in the run.
Do the two budget systems conflict?
No, they nest. OpenRouter caps spend per key or member per day, week, or month – the outer wall. in/guard/out caps one agent run: cost, steps, and tool calls, guard-model calls included, reserved before each request so concurrent calls can’t overshoot.
How do I set it up?
Point an in/guard/out key at OpenRouter as its upstream and swap your app’s base URL to in/guard/out. Model selection works as before. The OpenRouter integration page walks through it.
Keep the router’s rules. Check the answers.
in/guard/out fronts OpenRouter as an OpenAI-compatible upstream, so its workspace guardrails keep running underneath. We are running a limited demo - sign up and we will get you in as soon as we can.