Guardrails

Named policies that cap what people can spend, block requests carrying sensitive content, and narrow which models they can call, plus the defaults every new key owner starts with

Budgets limit how much can be spent. Guardrails limit what may be sent. A guardrail is a named policy you attach to people. It can cap their spend, block requests carrying sensitive content such as secrets or card numbers, switch off models for them, and put tags on their keys. Dispatch applies it to every request their keys make, before anything leaves Dispatch for a model.

Guardrails are on the Guardrails tab of the Organization page, together with the defaults new key owners start with and the organization's Token Optimization setting.

One policy, every key: Create a "Support team policy" that blocks email addresses, phone numbers and card numbers and switches off your most expensive tier. Assign it to each person on the support team, and every key they hold, including keys they create next month, follows it.

Guardrails Belong to People, Not Keys

A guardrail is assigned to a key owner, and each owner has at most one. It then covers every key that person holds, now and later. Somebody with five keys counts once in the guardrail's Owners column.

You assign a guardrail to a person in two places:

• Defaults for new key owners, further down this tab, chooses the guardrail everyone starts with. See Member Defaults.

• Change budget on the API Keys page changes the guardrail for one person who already has keys. See Users.

A person with no guardrail has no content filters and no extra model restrictions. They're still bound by their own allowance, the organization budget, and the organization's Model Access settings.

The Guardrail List

The Guardrails card lists every guardrail:

Column	What it shows
Name	The guardrail's name
Spend limit	The limit and how often it resets, or None
Content filters	How many filters are switched on
Models	Which models it leaves available
Tags	Tags it puts on its owners' keys
Owners	How many key owners it's assigned to

Click a row to edit a guardrail. Click the bin icon to delete one. Deleting asks for confirmation, because the people assigned to it "lose its limits and content filters immediately, across every key they hold."

Creating or Editing a Guardrail

Click New guardrail, or click an existing row. The panel notes that the guardrail is "Enforced by Dispatch on every request its holders' keys make."

Field	What it does
Name	Required. For example, "Support team policy".
Spend limit (USD) and Resets	Optional. A spend limit for each person under the guardrail, resetting daily, weekly or monthly. A limit needs both an amount and a reset interval, and the amount must be greater than zero.
Token Optimization	Inherit organization setting, On or Off. See Token Optimization.
Content filters	The kinds of content to block. See below.
Models	Switch off models the organization allows, so the people under this guardrail can't call them.
Tags	Tags put on every key the people under this guardrail own.

Click Save to apply.

Content Filters

Switch on any of these:

Filter	Blocks a request containing
Prompt injection	Prompt-injection phrasing
API keys and secrets	API keys or credentials
Credit card numbers	Payment card numbers
Social security numbers	Social security numbers
Email addresses	Email addresses
Phone numbers	Phone numbers
IP addresses	Public IP addresses

How the filters work:

• Every filter blocks. There's no redact or warn-only mode. A request that matches any filter that's switched on is refused before it reaches a model.

• The whole conversation is checked, not only the newest message. A card number in an earlier turn, or in a system prompt a tool assembled, still counts.

• Only requests are checked. The model's reply isn't scanned.

• The filters are a fixed list. You can't add your own patterns.

Models

The Models section lists the models your organization allows on its Model Access settings. Switch one off to keep it from the people under this guardrail. A guardrail can only take models away; it can never switch on a model the organization has switched off. Models added to your organization later follow your organization's Models settings.

You must leave at least one model on, because "with none, every request from the people under this guardrail would be refused."

The Auto tier "Keeps choosing between models for each request, including ones switched off here." Switching a model off stops people asking for it by name.

Tags

Tags chosen here go on every key owned by the people under the guardrail, including keys they create later. On the key, they show as inherited and can only be removed by changing the guardrail. When you save a guardrail with changed tags, Dispatch confirms how many keys across how many people now carry them. Moving a person onto or off the guardrail adds or removes its tags straight away.

A key can carry up to 10 tags and up to 5 tags with several values, so tags you can't add are greyed out once you reach the limit. See Tags.

What a Blocked Request Looks Like

The person whose request was refused gets an error from Dispatch that names the guardrail and says what to do next:

Cause	What the caller sees
A content filter matched	The request was blocked by the named policy, which doesn't allow that kind of content in a request, with the advice to remove it and try again or ask their Darcy administrator
The guardrail's spend limit was reached	The policy's budget has been reached, how much has been spent, and that it resets at the start of the next period or their administrator can raise it
They asked for a model the guardrail switched off	The model isn't available under their guardrail, a request to contact their administrator, and the models they can use instead

The error never repeats the content that matched, so a secret that triggered a filter doesn't end up in an error message or a log. The Models page also shows each person which models are "disabled by your guardrail".

Member Defaults

The Defaults for new key owners card decides what a person's allowance starts at. As the card puts it: "People in this organization can create their own keys, as many as they like, but every one of them spends from a single allowance they cannot change." The defaults apply whether the person creates their first key themselves or you create it for them.

Field	What it sets
Guardrail	The guardrail new key owners start under, or No guardrail
Spend limit (USD)	Their starting allowance. Leave it blank for No limit. Otherwise it must be above zero.
Resets	daily, weekly or monthly. Available once there's a spend limit.

Click Save defaults.

Defaults only apply to a person's first key. Anyone who already has a key keeps the allowance they were given. To change theirs, use Change budget on the API Keys page. See Users.

Token Optimization

The Token Optimization card at the foot of the tab sets the organization's default. When it's on, Dispatch "Shortens what your team's agents and apps send to the model: command output such as test runs, searches and diffs, and JSON tool results in a compact layout that keeps every value. Failures and errors are always sent in full, and file contents are never changed."

Use On for this organization to switch it. It applies within a minute to everyone whose guardrail is set to Inherit organization setting. A guardrail set to On or Off keeps its own setting for the people under it. See Insights for what it saves.

Next Steps

Goal	Documentation
Assign a guardrail or allowance to one person	Users
Choose the models everyone may call	Model Access
Set the organization-wide spending ceiling	Billing & Budget
Define the tags a guardrail can apply	Tags