Guardrail Policies

Guardrail Policies splits a guardrail into three separate policies, so you can mix and match them. Instead of one guardrail that holds a budget, a model list, and content filters together, you create each one on its own and assign it to the people and API keys it should cover. If you already use guardrails through the API or Terraform, see Migrating to Guardrail Policies.

Policy types

There are three kinds of policy:

Policy	What it controls
Budget	A spending cap in USD that resets daily, weekly, or monthly, and whether BYOK spend counts toward it.
Model & provider access	Which models and providers can be used, Zero Data Retention per model group, model training and publication choices, and which data regions requests may arrive through.
Content moderation	Prompt injection protection, sensitive info detection, and custom content filters.

Each setting works the same way it does in a guardrail. The difference is that each type can be assigned on its own. For example, a team can share one model access policy while each person gets a different budget.

Where policies apply

Policies apply at two levels:

Workspace-wide policies apply to every member and API key in a workspace, and can’t be overridden. A member’s or API key’s own policy within a workspace can add restrictions on top of a workspace-wide policy, but it can’t loosen one. Use these for rules the whole workspace has to follow, like a maximum per-person spending cap or requiring ZDR without exception. The same workspace-wide policy can be assigned to multiple workspaces. Create workspace-wide policies and assign them to workspaces under Account > Guardrails.
Member and API key policies apply to specific members or API keys inside one workspace. Use them to restrict particular people or keys further, like a smaller budget for a contractor or a shorter model list for a production key. A member’s policy also covers their chatroom usage and the API keys they created. Create and assign member and API key policies within a workspace under Workspace > Guardrails.

A member or API key can have at most one policy of each type in a workspace. Picking a new budget policy for someone replaces their old budget policy but leaves their model access and moderation policies alone.

An organization API key with no policy of its own follows the member who created it. Its spend counts toward that member’s budget. If the creator leaves the organization, the key falls back to the workspace’s default.

Defaults

For each policy type (budget, model & provider access, content moderation), you can set a default at both levels:

Default workspace-wide policy: applies to every workspace in your account that doesn’t have its own set workspace-wide policy of that type, including workspaces you create later.
Default member & API key policy within a workspace: applies to every member and API key in that workspace that doesn’t have its own set policy of that type, including people and keys added later.

Replacing or removing a default

You can remove the default from one workspace, member, or API key, at the level where the default is set. Replace it with a different policy or no policy.

Workspace-wide: give a workspace a different workspace-wide policy, or remove the default so that workspace has no workspace-wide policy of that type. Account-wide privacy and provider settings under Settings > Privacy always apply to every workspace.
Within a workspace: give a member or API key a different policy, or remove the default so they have no member or API key policy of that type. Workspace-wide policies still apply to them.

No default required

You don’t have to set a default at either level. Without one, workspaces, members, and API keys only get a policy of that type if you assign one directly.

How policies combine

When more than one level applies to a request, the stricter rule always wins:

Models and providers: only those allowed by every applicable policy are available.
Zero Data Retention: enforced for a model group if any applicable policy enforces it.
Data regions: only regions allowed by every policy that sets them. A policy that leaves regions unrestricted doesn’t change the result.
Sensitive info and content filters: filters from every applicable policy are combined. If the same filter has different actions, block wins over redact.
Budgets: each budget is checked on its own. A request is blocked when any one of them is used up.

Account-wide privacy and provider settings under Settings > Privacy always apply on top of every policy, and individual API key credit limits still apply too.

Budget enforcement

Budgets are tracked per person and per API key. They are never a shared pool for everyone assigned to the policy.

A member budget of $50/day gives each assigned member their own $50/day. Spend from all their API keys adds up toward it.
An API key budget limits that key’s own spend.
A workspace-wide budget assigned to a workspace limits each member and each API key in that workspace. A $100/month workspace-wide budget means no one in the workspace can spend more than $100/month, even if their own budget is higher.

To cap the total spend of a whole workspace, use a workspace budget instead. Budgets reset at 00:00 UTC: daily every day, weekly on Monday, and monthly on the 1st.

Example: raising one person’s budget

Your workspace has a workspace-wide policy with a $100/month budget, and a workspace default budget of $50/month. You give Alice her own $300/month budget policy. Alice’s own budget is now $300, but the workspace-wide policy still caps her at $100/month. To let her spend more, raise the workspace-wide policy’s limit or remove the workspace from it. You can check which budgets apply to an API key, and how much is left, with GET /api/v1/key.

Managing policies in the dashboard

Workspace policies live on the workspace’s Guardrails page (for the default workspace, Workspaces > Default > Guardrails). From there you can create budget, model & provider access, and content moderation policies, set a workspace default, and pick policies for each member and API key on the Assignments tab. Workspace-wide policies live under Account > Guardrails, where you choose which workspaces each one covers.

Organization admins can manage every policy. Workspace admins can create, edit, delete, and assign policies in workspaces they administer. Only organization admins can manage workspace-wide policies.

Managing policies with the API

Policies are managed with a Management API key. All routes live under https://openrouter.ai/api/v1/guardrails/policies:

Route	Purpose
`GET`, `POST` `/account`	List or create workspace-wide policies
`PUT`, `DELETE` `/account/{id}`	Update or delete a workspace-wide policy
`GET`, `POST` `/budget`	List (`?workspace_id=`) or create budget policies
`GET`, `PUT`, `DELETE` `/budget/{id}`	Read, update, or delete a budget policy
`/moderation`, `/moderation/{id}`	The same routes for content moderation policies
`/model-availability`, `/model-availability/{id}`	The same routes for model & provider access policies
`GET`, `PUT` `/assignments/members/{member_id}`	Read or change one member’s policy of one type
`GET`, `PUT` `/assignments/api-keys/{key_hash}`	Read or change one API key’s policy of one type

GET and DELETE on a workspace policy take workspace_id as a query parameter. List routes return { "data": [...], "total_count": N } and accept optional offset and limit for paging. API keys are named by their hash, like everywhere else in the Management API. Member IDs are the user IDs returned by List organization members (id) or a workspace’s member list (user_id).

Create a budget policy

This creates a $200/month budget in a workspace and assigns it to one member and one API key:

curl -X POST https://openrouter.ai/api/v1/guardrails/policies/budget \
  -H "Authorization: Bearer $OPENROUTER_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Engineering monthly budget",
    "policy_type": "budget",
    "workspace_id": "YOUR_WORKSPACE_ID",
    "config": {
      "limit_usd": 200,
      "reset_interval": "monthly",
      "include_byok_in_budgets": false
    },
    "member_ids": ["user_2abcDEFghiJKLmnoPQRstu"],
    "api_key_hashes": ["YOUR_API_KEY_HASH"]
  }'

Set "is_workspace_default": true to make it the workspace default for its type. Use opted_out_member_ids and opted_out_api_key_hashes to keep specific members or keys off the new default.

Create a model & provider access policy

curl -X POST https://openrouter.ai/api/v1/guardrails/policies/model-availability \
  -H "Authorization: Bearer $OPENROUTER_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Approved models",
    "policy_type": "model_availability",
    "workspace_id": "YOUR_WORKSPACE_ID",
    "is_workspace_default": true,
    "config": {
      "allowed_providers": ["openai", "anthropic"],
      "allowed_models": ["openai/gpt-4o", "anthropic/claude-sonnet-4"],
      "enforce_zdr_anthropic": true,
      "enforce_zdr_openai": true
    }
  }'

Create a workspace-wide policy

This applies a content moderation policy to two workspaces:

curl -X POST https://openrouter.ai/api/v1/guardrails/policies/account \
  -H "Authorization: Bearer $OPENROUTER_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Block secrets",
    "policy_type": "moderation",
    "is_default": false,
    "workspace_ids": ["WORKSPACE_ID_1", "WORKSPACE_ID_2"],
    "config": {
      "content_filter_builtins": [{ "slug": "secrets", "action": "block" }]
    }
  }'

Set "is_default": true instead to cover every workspace in the account, and list any workspaces to leave out in opted_out_workspace_ids.

Updating a policy

PUT replaces the policy’s name and settings, so send the full config every time. To change who is assigned, send both member_ids and api_key_hashes with the complete new lists. To leave assignments alone, for example when only changing the limit, leave both out.

Changing one member or API key

When several people or scripts manage assignments at once, sending full lists can overwrite each other’s changes. The assignment routes change one member or API key at a time instead. First read the current state:

curl "https://openrouter.ai/api/v1/guardrails/policies/assignments/members/user_2abcDEFghiJKLmnoPQRstu?workspace_id=YOUR_WORKSPACE_ID&policy_type=budget" \
  -H "Authorization: Bearer $OPENROUTER_MANAGEMENT_KEY"

{
  "data": {
    "policy_ids": [],
    "workspace_default_policy_ids": ["2c6f1a4e-0b7d-4e59-9a61-3f8d2e7c1b90"],
    "opted_out": false
  }
}

Then send the change along with the state you read as expected_assignment:

curl -X PUT https://openrouter.ai/api/v1/guardrails/policies/assignments/members/user_2abcDEFghiJKLmnoPQRstu \
  -H "Authorization: Bearer $OPENROUTER_MANAGEMENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "YOUR_WORKSPACE_ID",
    "policy_type": "budget",
    "policy_id": "BUDGET_POLICY_ID",
    "assigned": true,
    "expected_assignment": {
      "policy_ids": [],
      "workspace_default_policy_ids": ["2c6f1a4e-0b7d-4e59-9a61-3f8d2e7c1b90"],
      "opted_out": false
    }
  }'

If the assignment changed since you read it, the request fails with 409 Conflict. Read it again and retry. Use the /assignments/api-keys/{key_hash} route the same way for API keys.

Limits

A single create or update request can name up to 10,000 members and API keys in total. A policy itself can cover any number of them.
Workspace policies belong to one workspace and can only be assigned to members and API keys in that workspace.

When a request is blocked

Requests blocked by a policy return the same 403 errors as guardrails. See When a Request Is Blocked and Budget limits for the response shapes.

Overview

Models & Routing

Tool Calling

Features

Observability

Authentication

Ori

Developer Tools

Privacy

Best Practices

Providers

Community

Policy types

Where policies apply

Defaults

Replacing or removing a default

No default required

How policies combine

Budget enforcement

Example: raising one person’s budget

Managing policies in the dashboard

Managing policies with the API

Create a budget policy

Create a model & provider access policy

Create a workspace-wide policy

Updating a policy

Changing one member or API key

Limits

When a request is blocked

​Policy types

​Where policies apply

​Defaults

​Replacing or removing a default

​No default required

​How policies combine

​Budget enforcement

​Example: raising one person’s budget

​Managing policies in the dashboard

​Managing policies with the API

​Create a budget policy

​Create a model & provider access policy

​Create a workspace-wide policy

​Updating a policy

​Changing one member or API key

​Limits

​When a request is blocked

Policy types

Where policies apply

Defaults

Replacing or removing a default

No default required

How policies combine

Budget enforcement

Example: raising one person’s budget

Managing policies in the dashboard

Managing policies with the API

Create a budget policy

Create a model & provider access policy

Create a workspace-wide policy

Updating a policy

Changing one member or API key

Limits

When a request is blocked