Guardrails: Protect your Agents, Data, and Costs | OpenRouter

Guardrails: Protect your Agents, Data, and Costs

Cailee Moberg · 5/29/2026

OpenRouter workspaces have guardrails: a set of configurable security and governance tools for budget enforcement, zero data retention (ZDR), model and provider restrictions, prompt injection defense, and data loss prevention. Layer each of these rules into a guardrail to govern your entire workspace, or create customized guardrails for team member groups or API keys, all without changing your code.

Go to Workspaces > Guardrails(opens in new tab) in your home dashboard or use the management API(opens in new tab) to create guardrails. Read the docs(opens in new tab) for more detail.

Budget Enforcement

Set spending limits with daily, weekly, or monthly reset windows. Requests that exceed the limit for the time period will fail with a 403 response. Use it to cap spending per member or per key so a single runaway script can't burn the month's budget.

Guardrail budgets are per-entity, not shared. Assign a guardrail with a $50/day limit to three team members, and each one gets their own $50 budget. API key budgets layer independently on top of member budgets. If Audrey has a $100/day member limit and her key has a $30/day limit, the key caps at $30 and Audrey's total across all keys in the workspace caps at $100. Both are checked on every request.

Zero Data Retention (ZDR) and Model/Provider Restrictions

Disable all endpoints that retain or train on data in one-click, block individual models or providers, or restrict the workspace to a model/provider allowlist. Disallowed requests fail with a 403 response. Use it to keep traffic on providers you've vetted, off providers that retain or train on inputs, and on the model price tier each project should use.

Your account-wide privacy policies and provider restrictions(opens in new tab) are inherited by default. Guardrails can only be more restrictive.

Prompt Injection Defense

Scan inputs against a set of >30 regex patterns derived from the OWASP LLM Prompt Injection Prevention Cheat Sheet(opens in new tab) and other resources to identify prompt injection and jailbreak attempts. The detection system includes techniques to catch common evasion strategies: typoglycemia, encoding-based, and character-spaced evasion. It's deterministic and latency overhead is negligible.

Detection runs before the request is sent to the model provider, so blocked traffic never leaves OpenRouter. Use it to catch common injection and jailbreak patterns, especially for agents that pass user input verbatim.

Choose the action you want taken when a pattern is detected:

Flag: The request passes through unmodified; the detection is recorded for observability, but no enforcement is applied. Useful for evaluating the impact on your traffic before switching to redact or block.

Redact: Matched parts of the input are replaced with [PROMPT_INJECTION] and the sanitized request is sent to the model.

Block: The entire request is rejected with a 403 before it reaches the model. The 403 response includes metadata about the type of pattern detected.

Read the prompt injection detection docs(opens in new tab).

Data Loss Prevention (DLP)

Detect and handle PII and other sensitive information in requests. Seven sensitive info types are built in. You can also add your own custom regex patterns for domain-specific data (internal project codenames, proprietary IP). Configure each to Redact the sensitive info or Block the request entirely. Blocked requests return a 403 response with information about the type of content detected. Use it to keep PII and sensitive identifiers out of vendor logs and in compliance with your data handling commitments.

Most built-in patterns and all custom patterns use regular expression matching. This is deterministic and adds negligible latency to requests. Names and addresses use Natural Language Processing (NLP) via Presidio(opens in new tab) and add latency proportional to input size.

Built-in patternMethodRedacted as

Email addressRegex[EMAIL]

Phone numberRegex[PHONE]

Social Security numberRegex[SSN]

Credit card numberRegex[CREDIT_CARD]

IP addressRegex[IP_ADDRESS]

Person nameNLP[PERSON_NAME]

AddressNLP[ADDRESS]

Read the sensitive info protection docs(opens in new tab).

Assign to API keys or org members

You can assign a guardrail to multiple API keys or members. When assigned to members, the guardrail applies to all of their keys in the workspace.

Each workspace has a default guardrail you can configure that applies to every API key and member in the workspace. You can create additional guardrails to further restrict specific API keys or members. The workspace default guardrail sets the baseline; any additional guardrails layer on top.

Start using guardrails

Go to Workspaces > Guardrails(opens in new tab) in your home dashboard to configure your workspace guardrail or create guardrails for specific API keys or members.

Configure programmatically. The Management API supports every guardrail operation, including create, update, delete, list, and assign to keys or members, so you can automate provisioning during team onboarding or key rotation.

Guardrails docs overview(opens in new tab) · Guardrails API reference(opens in new tab)