Content Rules
Builtin detectors, custom patterns, the three actions, where each rule is actually enforced, and the coverage gaps stated plainly.
Content Rules
The content half of a guardrail detects things in a request before a model sees it. It is the half with real coverage limits, and this page states them rather than glossing them.
Both enforcement paths read only the request. A content rule does not touch a model's generated answer. If you need output filtering, this is not it.
Builtin detectors
| Detector | What is detected | Example |
|---|---|---|
| Email addresses | name@example.com | |
| Phone numbers | +1 555 010 0100 | |
| Social security numbers | 123-45-6789 | |
| Credit card numbers | 4111 1111 1111 1111 | |
| IP addresses | 203.0.113.7 | |
| Person names | Detected names | |
| Postal addresses | Street addresses | |
| Prompt injection | Attempts to override system instructions |
The descriptions say what is detected rather than naming a technique, because the engine behind them is swappable. Treat them as a statement about outcomes, not about implementation.
Prompt injection alone takes a scan scope: all messages, or user messages only. It is rejected on any other detector rather than silently ignored.
Custom patterns
Your own regular expressions, each with an action and a label -- the
placeholder or error label used when it fires, for example [API_KEY]. The
label is honoured only where an upstream enforces: it is not sent to the
gateway, so where the gateway enforces locally every custom pattern redacts to
[REDACTED] and is recorded as CUSTOM.
| Constraint | Value |
|---|---|
| Pattern length | 1000 characters |
| Label length | 100 characters |
| Rules per list | 100 |
| Syntax | RE2 |
A pattern is compiled when you save it, and a pattern that does not compile at request time is a refused request rather than a silently skipped rule. An unknown detector slug, action or scan scope is likewise rejected, not dropped -- someone who types a filter the platform quietly discards would believe they were protected.
One action per detector. A duplicate entry for the same detector is rejected, because two entries would leave the effective action to an upstream's precedence rules rather than to what you chose.
The three actions
| Action | Behaviour |
|---|---|
| Flag | Records the match and changes nothing. |
| Redact | Replaces each match with the detector's placeholder. |
| Block | Refuses the request. |
A fourth state exists only in the interface: Off simply means the filter is absent from the saved guardrail.
Flag is the "measure before you enforce" setting. Turn a detector on as flag, read what it finds on your real traffic for a while, and only then decide between redact and block.
A block is always observable: it is a refusal before the request reaches a model. Redact and flag are invisible by default, which is why the gateway opts into the upstream's guardrail metadata where an upstream enforces -- without it, a redaction would simply succeed with silently modified content.
Only detector categories are recorded in telemetry. The upstream also returns a fragment of the matched prompt text, which for a PII detector is the PII itself; it is deliberately never parsed, logged or stored.
Where a rule is actually enforced
There are two enforcers, and which one runs is a property of the serving upstream rather than of your credential or your rule.
| Path | When | How fast a change lands |
|---|---|---|
| The gateway enforces locally | The serving upstream applies no guardrails of its own. Rules ride the authorization decision. | Seconds -- it inherits the decision cache's freshness. |
| The upstream enforces | The serving upstream can apply them. DevZero projects your rules onto a guardrail object attached to your team's provisioned keys. | Up to 5 minutes, on a reconciliation sweep. |
Where an upstream enforces, the previous rules keep applying until the projection lands. Switching Block to Redact will keep blocking meanwhile, and the Guardrails table shows the guardrail as pending until it converges.
Content status
The status is deliberately not collapsed to active or inactive, because "saved but not yet enforcing" and "saved and enforcing" is exactly the distinction it exists to make.
| State | Badge | Meaning |
|---|---|---|
not_applicable | none | No content rules configured. |
disabled | Filters off | The content half is switched off for this installation. |
unbound | Not enforced | Rules exist but there is nothing to attach them to -- no managed-custody enrollment, or the guardrail is unassigned or disabled. They enforce nothing. |
pending | Applying… | Rules changed and the projection has not converged yet. |
active | Filtering | Projected and enforcing. |
error | Filter error | The last projection attempt failed; the status carries the message. |
Coverage gaps
These are the product's own stated limits. None of them is a bug report; all of them affect whether you are protected.
Two implementation facts with visible consequences
Enforcement runs before the cache lookup. Running it early and reassigning the body is what makes a redaction total -- but it means two requests differing only in a redacted value share a cache entry.
A redaction that would break the body is treated as a failure to enforce rather than forwarded. Redaction rewrites string values only, clamped to the interior of one JSON string, and detection runs over the raw body so a redacted body is still a valid cache key.
Recommended rollout
- Add the detectors you care about as flag.
- Read what they find on your real traffic for a window you trust.
- Move the ones that matter to redact or block, and watch the guardrail's content status until it reports enforcing.
- If any of your traffic runs on your own provider account, configure equivalent filters there -- DevZero cannot reach it.
Governance Rules
Budgets, rate ceilings, and model and provider access -- the half of a guardrail DevZero enforces on every request.
Evals Overview
The family of judged model comparisons -- trials, experiments, compare and watches -- and the one rule that separates traffic evidence from corpus evidence.