Summary: OpenRouter launched Guardrails on May 29 as a workspace-level toolkit combining budget limits, ZDR, model and provider restrictions, prompt-injection defense, and DLP. Rules attach to the workspace or to specific members and API keys without application-code changes, and inherited account policies can only be tightened, not loosened. The regex defenses are one defensive layer and Presidio-based person or address detection adds input-dependent latency.
Guardrails showed up on May 29 from OpenRouter: a configurable toolkit for security and governance that sits at the workspace level, bundling budget enforcement, zero data retention (ZDR) together with model/provider restrictions, prompt injection defense, and data loss prevention (DLP). Builders juggling API spend, fielding governance requirements, or simply trying to stop an agent they wrote from burning through the budget should give it a slot in the toolbox.
Where the rules live matters just as much as what they say. Nothing goes into application code — the controls attach to the OpenRouter workspace. A single rule set can cover the whole workspace, or particular groups of team members and individual API keys can get guardrails of their own, all without writing a line of code. Everything is configured under Workspaces > Guardrails in the dashboard, or through the management API.
Three HTTP codes worth memorizing first
When a guardrail fires, the outcome shows up as an HTTP status code. Commit three numbers to memory: spending past the budget returns 402, a request aimed at a restricted model or provider returns 404, and a prompt injection or DLP block returns 403. Put that mapping into your agent’s error handling, and the moment a gate trips you will know which layer stopped the call.
| Code | Cause |
|---|---|
| 402 | Spending crossed the reset-window limit |
| 404 | Requested model or provider is restricted |
| 403 | A prompt injection or DLP block fired |
Budget enforcement: one quota per entity, stacked in layers
Budgets can run on daily, weekly, or monthly reset windows, and anything beyond the limit fails with a 402. The detail most people miss: quotas are per-entity. Hand a $50/day guardrail to three members and there is no shared $50 pot — every one of them holds a full, separate $50. A teammate cannot eat your quota, and accountability stays easy to trace.
Key budgets sit independently above member budgets. With the official example’s figures: a member capped at $100/day who holds a key limited to $30/day will see that key stop at $30, while the member’s total across every workspace key still tops out at $100. Every request is measured against both limits — a key can be tighter than its member, but never looser.
ZDR and model restrictions: an inheritance chain that only tightens
Privacy gets a single-switch answer in ZDR: turn off every endpoint that retains or trains on data. On the governance side, individual models or providers can be blocked, or the logic flipped into an allowlist; anything restricted fails with a 404.
The skeleton, though, is the inheritance rule. Account-level privacy policies and provider restrictions flow down to the workspace by default, and guardrails may only be stricter than the account setting — loosening is not on the table. The floor gets set at the account level, and each layer beneath can only add more. Multi-environment setups feel this directly: if staging has to be looser than production, build that difference into the workspace structure at the start rather than relaxing a guardrail after the fact.
Prompt injection defense: interception before the request leaves
On the input side, more than 30 regex patterns scan for prompt injection and jailbreaks, with rules drawn partly from the OWASP LLM Prompt Injection Prevention Cheat Sheet. Direct instructions get matched, and so do the usual evasion tricks — encoding-based, character-spaced, and typoglycemia payloads. Two engineering facts stand out: the scan is deterministic with negligible latency, and it runs before the request ever reaches the model provider, so caught traffic never leaves OpenRouter.
Responses come in three stages. Flag passes the request through untouched and simply logs the detection — a sensible first step for observability. Redact swaps matched segments for [PROMPT_INJECTION] and forwards the cleaned request. Block refuses the entire request with a 403, carrying metadata that names the pattern type. The pragmatic route: run Flag for a while, read the false-positive rate, then choose between Redact and Block.
DLP: seven built-in types, with Presidio as the lone exception
Data loss prevention arrives with seven built-in sensitive-info types, and custom regex patterns extend coverage to domain-specific data such as internal codenames or proprietary IP. The same Redact-or-Block choice applies, with blocks returning a 403. One fork in detection matters: most built-in types and every custom pattern run on regex and stay deterministic and fast, while person names and addresses go through NLP in Microsoft Presidio, whose latency climbs with input size — high-throughput deployments should account for that exception in their response-time budget.
How guardrails stack, and how to automate them
A default guardrail ships with every workspace and acts as the baseline across all keys and members; extra guardrails stack above it, and a rule attached to a member reaches every key that member owns. Where programmatic control is needed, the management API exposes the full operation set — create, update, delete, list, and assign. The important fields from the official curl example:
{
"limit_usd": 100,
"reset_interval": "daily",
"allowed_models": ["..."],
"content_filter_builtins": [{ "slug": "...", "action": "block" }]
}limit_usd together with reset_interval sets the budget window, allowed_models holds the model allowlist, and content_filter_builtins switches on content-filter rules one by one through a slug and an action. Automation for team onboarding or key rotation can be built straight on this API, with no need to circle back into the codebase.
Limits to respect, and a sensible rollout
Be clear-eyed about the limits. Regex defense is deterministic: it handles common injection and evasion patterns well, but a deliberately engineered targeted attack was never going to be caught 100% of the time — count it as one layer inside defense in depth, not the whole answer. Presidio NLP latency grows with input, so whether person-name and address detection stays on should come from measuring real traffic. And because guardrails only tighten, the staging-versus-production gap mentioned earlier has to be settled while the workspace is being planned.
Rollout is simple. Open with the default guardrail: a conservative daily budget plus prompt injection blocking as the baseline. From there, put stricter model restrictions and DLP on the production keys that carry the most risk. What Guardrails offers is not a replacement for application-layer security — it moves cost and safety out of the codebase and into infrastructure you can audit and adjust independently, with no rebuild at deploy time.