OpenRouter 重构 Guardrails：组织限制与工作区默认分离

A year ago, most companies on OpenRouter used AI in a few teams. Now it’s reaching across departments. People using OpenRouter on teams of 10 or more have grown 70x, and the average organization runs three times as many active API keys as more of that work moves to agents.

The admins managing all of this keep asking for the same thing: one set of rules for the whole organization, and room to make exceptions for the people who need more.

We’ve rebuilt how Guardrails is configured so admins can now set organization-wide restrictions, give people different budgets and model access within them, and change each policy on its own.

To get started, open your workspace’s Guardrails page to set up policies, or read the Guardrail Policies docs.

Why we changed Guardrails

We built the first version of Guardrails for that earlier pattern: a few teams, a handful of API keys. Today we see hundreds or thousands of employees signing in through SSO, coding agents running on every engineer’s laptop, and platform teams accountable for what all of it costs.

That shift showed up in what customers asked us for:

• Budgets per person, with exceptions. Teams wanted a default monthly or weekly budget for everyone, plus a higher one for the people who need it. With one guardrail per budget level, one customer was on track to create a separate guardrail for each of its roughly 1,200 employees.
• Defaults that start conservative. Customers wanted new members to start with the most conservative settings and be granted more over time. The old model worked the other way: the workspace default was the most anyone could get, and every other guardrail could only tighten it.
• One rule across many workspaces. Companies with several business units wanted to set ZDR, provider, and region rules once, instead of copying the same guardrail into every workspace.
• A way to handle requests. Admins kept getting asked for a bigger budget or access to a new model for a project, and wanted approving that to be a quick change, not a rebuild.

Some customers have now built their own internal workflows on top of Guardrails. An employee asks for a higher budget or access to a specific model for a project, explains why, and an admin approves it. With separate policy types and limits set by the organization, approving that request is a single change. They just assign the person a different budget or model access policy and it stays inside the organization’s limits automatically.

Organization limits are separate from workspace defaults

Organization admins can now set limits for whole workspaces, such as a maximum budget, Zero Data Retention requirements, or which models and providers can be used. These limits apply to every member and API key in the workspace, including people with their own budget or model policy.

Inside those limits, workspace admins set the defaults. New members get a default budget and model list as soon as they join, and the admin can give specific people a higher budget or access to more models. None of that can go past the organization’s limits.

In practice, that looks like an organization admin limits the Engineering workspace to $2,000 a month per person, ZDR-only providers, and no access to a particular high-cost model. The workspace admin sets the default for new members at $200 a month with the team’s standard models. A new engineer who joins gets that $200 default automatically. A senior engineer leading an agent project can get $1,500 a month and access to more models. No one in the workspace can go past $2,000 a month or use a non-ZDR provider.

Budget, model access, and moderation are separate policies

A guardrail used to bundle a budget, model and provider access, and content moderation into one named object. They’re now three separate policy types:

• Budget sets a spending cap in USD that resets daily, weekly, or monthly.
• Model and provider access controls which models and providers can be used, ZDR, and data regions.
• Content moderation covers prompt injection protection, sensitive info detection, and custom content filters.

We split them up because they don’t change together. A person’s budget might change with every new project, while the team’s model list and moderation rules can stay the same for months.

Now the team shares one model access policy and one moderation policy, and you can change one person’s budget without touching anything else.

Backwards Compatible

You don’t need to change anything to keep your current setup. Existing guardrails keep their IDs and enforce the same rules, and the guardrails API and Terraform resources work as before. Each guardrail now also shows up as separate budget, model access, and moderation policies, so you can move over one workspace at a time when you’re ready.

If you manage guardrails through the API or Terraform, read Migrating to Guardrail Policies first, because changes made in the dashboard don’t sync back to your config.

Getting started

To try it, open the Guardrails page in any workspace you manage. Your existing guardrails will already be there as separate policies. A good first step is raising one person’s budget without touching anything else. Organization admins can set org-wide limits from Workspace-wide guardrails. For the full setup, see the Guardrail Policies docs.

FAQ

What are OpenRouter Guardrails?

Guardrails let organizations control spending, model and provider access, and content moderation for their members and API keys.

Can I set different AI budgets for different people?

Yes. Assign a budget policy to a member or API key. It resets daily, weekly, or monthly and can’t exceed the limits your organization admin sets.

Are budgets shared across a workspace?

No. Each budget applies per member or per API key, not as a shared pool. A $100/month limit means each person can spend up to $100.

What happens to my existing guardrails?

They keep enforcing the same rules and keep their IDs. Each one now also appears as up to three separate policies.

Do I need to migrate to a new API?

No. The existing guardrails API and Terraform resources keep working. New policy endpoints live alongside them under /api/v1/guardrails/policies.

Who can manage guardrail policies?

Organization admins can manage every policy, including org-wide limits. Workspace admins manage policies in the workspace.