Guardrails

A guardrail is a set of rules for requests. You assign it to the organization, a workspace, a member or a key. Every guardrail that covers a request applies. When two guardrails disagree, the stricter rule wins.

Guardrails apply to POST /v1/chat/completions, /v1/messages, /v1/responses, /v1/images/generations, /v1/videos and /v1/decisions. You manage them with the management API.

In the console, open Governance > Guardrails for the rules. Open Governance > Budgets for the spending limits.

Create and assign a guardrail

1. 01

   Create the guardrail with a management key:

   bashcopy

   curl https://dev2-api.routerplus.com/v1/guardrails \
     -H "Authorization: Bearer $TM_MANAGEMENT_KEY" \
     -H "Content-Type: application/json" \
     -d '{"name": "support-bot",
          "blocked_models": ["openai/gpt-oss-20b"],
          "content_rules": [{"kind": "pii", "preset": "email", "action": "redact"}]}'

   The response is 201. data holds the guardrail and its guardrail_id.

2. 02

   Assign the guardrail. It has no effect until you do. target_kind is the organization, a workspace, a member or a key:

   bashcopy

   curl https://dev2-api.routerplus.com/v1/guardrails/$GUARDRAIL_ID/assignments \
     -H "Authorization: Bearer $TM_MANAGEMENT_KEY" \
     -H "Content-Type: application/json" \
     -d '{"target_kind": "org", "target_id": "'$ORG_ID'"}'

A change applies within 5 seconds. With the guardrail above:

• A call to openai/gpt-oss-20b returns 403 with error.code guardrail_blocked.
• A call that contains an email address goes to the provider with [REDACTED:email] in its place. The response carries x-tm-guardrail-actions: redacted.

Rules

Unknown fields are refused.

A filter on a provider fact leaves out each provider for which RouterPlus does not know that fact. For example, zdr: true leaves out a provider that does not publish its retention.

Regions and infrastructure

• RouterPlus records a provider's regions and infrastructure only from the provider's published terms: its privacy policy, data processing terms, subprocessor list or docs.
• allowed_regions keeps only providers whose terms state where they process requests.
• RouterPlus does not record a region that a provider offers only as an option RouterPlus does not use.
• blocked_infrastructure leaves out a provider that names a blocked cloud for serving or hosting.
• GET /v1/models/<model>/endpoints shows each provider's regions and infrastructure under data_policy.

Budgets

{ "budgets": [
  { "id": "monthly", "limit_usd": 500, "period": "month" },
  { "id": "opus", "limit_usd": 50, "period": "week", "model": "claude-opus-*" },
  { "id": "team-pool", "limit_usd": 2000, "period": "month", "shared": true, "include_byok": true }
] }

• period is day, week (from Monday), month or lifetime. Periods start at 00:00 UTC. A budget with no period is lifetime.
• model and provider count only the spend on that model or provider.
• include_byok also counts the provider cost of requests on your own provider keys.
• shared: true makes one budget for everything the guardrail is assigned to. Without it, each assignment has its own budget. For example, a guardrail on a workspace counts the spend of that workspace.
• A key also has its own limit: limit with limit_reset on the key.

RouterPlus refuses a request when its budget is used up. Requests that are already running finish. Spend can go past the limit by the cost of those requests.

Content rules

{ "content_rules": [
  { "kind": "pii", "preset": "credit_card", "action": "block" },
  { "kind": "pii", "preset": "email", "action": "redact" },
  { "kind": "regex", "pattern": "PROJ-[0-9]{4}", "action": "redact", "label": "project_code" },
  { "kind": "injection", "action": "block" }
] }

• pii presets: email, phone, ssn, credit_card, iban, ip_address, credential, aws_access_key, private_key, jwt, us_passport.
• regex: up to 512 characters, with flags i, m, s and u. A pattern with lookarounds, backreferences or nested quantifiers returns invalid_regex_pattern.
• injection finds prompt-injection and jailbreak patterns in user text and tool results.
• action:
  • redact puts [REDACTED:<label>] in place of the match before RouterPlus sends the request.
  • block refuses the request.
  • flag records the match and sends the request unchanged.
• When two guardrails have the same pattern with different actions, block wins over redact, and redact wins over flag.

Content rules read message text, tool-call arguments and tool results. They do not read images or tool definitions. RouterPlus does not store the matched text. The record holds the rule, the count and the place in the request where it matched.

Errors

The 401 and 403 refusals carry x-should-retry: false. Do not retry them.

Response headers:

• x-tm-guardrails: the ids of the guardrails that applied.
• x-tm-guardrail-actions: redacted or flagged, when a content rule acted.
• x-tm-guardrails: unavailable: RouterPlus could not read your guardrails, so the request ran without them.

Grants

A grant is a time-boxed exception to one rule. An approved grant applies from starts_at until expires_at. After expires_at, the base rule applies again.

• A grant lasts at most 90 days.
• A budget or key limit grant must raise the limit. When two grants cover the same limit, the higher one applies.
• A guardrail with overridable: false is a hard limit. It takes no grant. Its organization-level budgets also cap every budget grant for the same period.
• A management key can request, approve, reject, cancel and list grants. An API key can request a grant for itself, and list, read and cancel the grants it requested.
• RouterPlus sends a notice when a grant is requested, decided or cancelled, and one day before it expires.

In the console, open Access > Grants. For the endpoints, see Grants in the management API.

Activity

GET /v1/guardrails/events lists the requests that a guardrail blocked, redacted or flagged. In the console, open Governance > Guardrail events.