On May 29, OpenRouter launched Guardrails: a set of configurable security and governance tools at the workspace level, covering budget enforcement, zero data retention (ZDR) with model/provider restrictions, prompt injection defense, and data loss prevention (DLP). For builders managing API spend, fielding governance requirements, or simply trying to keep a home-grown agent from torching the budget, this is worth a slot in the toolbox.
The more consequential design decision is placement. These rules do not live in application code; they attach to the OpenRouter workspace. One rule set can govern the entire workspace, or you can build custom guardrails for specific groups of team members or individual API keys — without touching a line of code. Configuration lives at Workspaces > Guardrails in the dashboard, or directly through the management API.
Three status codes to remember first
Guardrail behavior ultimately surfaces as HTTP status codes, and three numbers are worth memorizing up front: budget overruns return 402, requests to a restricted model or provider return 404, and prompt injection or DLP blocks return 403. Encode that mapping into your agent’s error handling and you will know immediately which layer tripped when a gate fires.
| Code | Trigger |
|---|---|
| 402 | Spend exceeded the reset-window limit |
| 404 | Model or provider is restricted |
| 403 | Prompt injection or DLP block |
Budget enforcement: per-entity, and it layers
Budget enforcement supports daily, weekly, and monthly reset windows; requests past the limit fail with a 402. The easily missed detail is that budgets are per-entity: assign a $50/day guardrail to three members and they do not share one $50 pool — each gets an independent $50. Quotas cannot be eaten by a teammate, and accountability stays legible.
API key budgets layer independently on top of member budgets. In the official example’s numbers: a member with a $100/day limit who holds a key capped at $30/day will see that key stop at $30, while the member’s combined ceiling across all workspace keys remains $100. Both limits are checked on every request — the key layer can be tighter than the member layer, never looser.
ZDR and model restrictions: inheritance that only tightens
On the privacy side, the one-click option is ZDR: disable all endpoints that retain or train on data. On the governance side, you can block individual models or providers, or invert the logic into an allowlist; restricted requests fail with a 404.
What actually forms the skeleton is the inheritance rule: account-level privacy policies and provider restrictions are inherited by the workspace by default, and guardrails can only be stricter than the account setting — never more permissive. The floor is locked at the account level; every layer below can only add restrictions. That has a direct implication for multi-environment setups: if staging needs looser rules than production, solve it in workspace structure up front, not by loosening a guardrail later.
Prompt injection defense: 30+ regexes before the request leaves
Input-side defense scans for prompt injection and jailbreaks with more than 30 regex patterns, sourced in part from the OWASP LLM Prompt Injection Prevention Cheat Sheet. The scan matches direct instructions as well as common evasion techniques — typoglycemia, encoding-based, and character-spaced payloads. Two engineering properties stand out: the scan is deterministic with negligible latency, and it runs before the request reaches the model provider — blocked traffic never leaves OpenRouter at all.
Actions come in three stages. Flag lets the request pass through unmodified and only records the detection, which suits an initial observability pass; Redact replaces matched segments with [PROMPT_INJECTION] and sends the sanitized request; Block rejects the whole request with a 403 plus metadata about the pattern type detected. The pragmatic path is to run Flag for a while, then tighten to Redact or Block based on the observed false-positive rate.
DLP: seven built-in types, Presidio the one exception
Data loss prevention ships with seven built-in sensitive-info types, and custom regex patterns extend coverage to domain-specific data such as internal codenames or proprietary IP. Actions are the same Redact-or-Block pair, with blocks returning a 403. One fork in detection methods matters: most built-in types and all custom patterns use regex, staying deterministic and low-latency, while person names and addresses use NLP via Microsoft Presidio, whose latency grows with input size — high-throughput deployments should budget for that exception.
The layering model and automation
Every workspace has a default guardrail as the baseline, applied to all keys and members; additional guardrails layer on top, and a rule assigned to a member covers all of that member’s keys. For programmatic control, the management API supports the full operation set — create, update, delete, list, and assign. The key fields from the official curl example:
{
"limit_usd": 100,
"reset_interval": "daily",
"allowed_models": ["..."],
"content_filter_builtins": [{ "slug": "...", "action": "block" }]
}limit_usd with reset_interval defines the budget window, allowed_models is the model allowlist, and content_filter_builtins turns on content-filter rules one by one with a slug and an action. Team onboarding and key rotation automation can sit directly on this API without circling back into the codebase.
Trade-offs and builder guidance
Limits first. The regex defense is deterministic: effective against common injection and evasion patterns, but a deliberately crafted targeted attack was never going to be caught 100% of the time — treat it as one layer of defense in depth, not the whole stack. Presidio NLP latency scales with input, so whether person-name and address detection stays on should be decided from real traffic measurements. And guardrails only tighten; the staging-versus-production divergence noted earlier has to be resolved at workspace-planning time.
The rollout order is straightforward. Start with the default guardrail: a conservative daily budget and prompt injection blocking as the baseline. Then layer stricter model restrictions and DLP on high-risk production keys. Guardrails’ value is not in replacing security design at the application layer — it is in pulling cost and safety out of the codebase into infrastructure that can be audited and adjusted independently, without a rebuild at deploy time.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.