Guardrails Overview
A guardrail is one named bundle of rules -- budget, rate ceilings, model and provider access, content filters -- bound to a principal. They never stack.
Guardrails Overview
A guardrail decides what a bound principal may do and whose credential it does it with: access rules, content rules, a credential class, a budget and rate ceilings, on one object.
One guardrail governs a request, or none does. They never stack. There is no merging, no union and no precedence between two guardrails -- the gate picks exactly one.
That is the opposite of how a routing profile resolves, and the two are deliberately different: a profile is behaviour and merges field by field, while a guardrail is protection and resolves to one whole object.
The binding ladder
| Order | Binding |
|---|---|
| 1 | The principal's own binding. |
| 2 | Else the team default. |
| 3 | Else nothing. |
Nothing means allow. An unconfigured team is not a governed team. Creating your first guardrail and marking it the team default is what turns governance on for everything that has no more specific binding.
A subject has at most one binding, which is what makes "they never stack" true rather than aspirational.
What a guardrail carries
| Part | Page |
|---|---|
| A credential class -- whose credential its traffic forwards with | Keys and credentials |
| A budget, and how often it resets | Governance rules |
| Rate ceilings: requests per minute, tokens per minute | Governance rules |
| Model access: allowed and ignored models | Governance rules |
| Provider access: allowed and ignored providers | Governance rules |
| Content rules: builtin detectors and your own patterns | Content rules |
| Soft-warn thresholds | Governance rules |
Two halves, enforced in different places
This is the distinction to hold on to, because the two halves have genuinely different coverage and genuinely different latency.
| Governance half | Content half | |
|---|---|---|
| Covers | Budgets, rate and token ceilings, model and provider access | PII detectors, prompt injection, your own patterns |
| Enforced by | DevZero, end to end. The control plane decides, the gateway does the counter arithmetic. | Either the upstream, or the gateway itself -- depending on the serving upstream. |
| Covers which traffic | Every request, whoever's credential pays. | Keyed connector inference. Which enforcer runs depends on the serving upstream, not on your credential. |
| How fast a change lands | Seconds, bounded by the decision cache. | Seconds where the gateway enforces; up to 5 minutes where an upstream does. |
See Content rules for the coverage gaps, which are stated rather than glossed.
Assignment
Assignments are replaced declaratively:
- Marking a guardrail the team default makes it the fallback for every principal without a more specific binding.
- Naming a key repoints it from wherever it was bound.
- Omitting a key unbinds it only if it currently points at this guardrail.
Only ownerless service keys can be bound directly. A key held by a person follows their identity's guardrail instead -- because minting a key must never be a way around a person's budget.
An unassigned guardrail governs nothing, and the table says so with a dash rather than implying it is active. Archiving is refused while assignments still point at a guardrail: unassign first.
Creating one
The wizard has five steps, and it adapts to the credential class rather than disabling controls -- a seat guardrail drops the Limits step entirely, because a seat cannot carry a budget, a rate ceiling or a key binding.
- Identity and custody. Name it, choose whose credential it forwards with, and what it governs.
- Limits. One ceiling on total spend, one on how fast it burns.
- Access. Which models requests may reach, and through whom.
- Content filters. What gets detected before a model sees the request.
- Review. Everything this guardrail will do -- and will not.
Introducing one safely
Governance runs in one of three modes -- off, shadow or enforce -- set per
gateway deployment by DevZero, not per guardrail and not per team. In shadow
mode every decision is evaluated and recorded, and nothing is denied. A hosted
gateway starts in shadow, and a self-hosted one starts in off.
Use it. The known failure mode of an allowlist is a false deny: a non-wildcard entry must match what the gateway actually sends, byte for byte, or the rule silently denies traffic it was meant to permit -- and the denial is cached for a short window, so it sticks.
Read your shadow window's would-deny decisions and explain every one of them before asking DevZero to move your gateway to enforce.
Reading the table
| Column | |
|---|---|
| Name | |
| Status | Including the content half's own status. |
| Budget | With a burn meter. |
| Rules | Counts of allowed and blocked models and providers. |
| Assignments | The team-default badge first, then key names -- or a dash. |
The Guardrails screen is team-scoped, so the gateway picker and the time picker are removed rather than rendered inert.