How it works
A deterministic guardrail sits on the path between an agent's proposed action and the effect that action would have. The model produces a candidate — a tool call, a payload, a command — and the guardrail evaluates it against a fixed rule before anything executes. The rule is code, not judgment, so the same input always yields the same verdict.
A guardrail typically runs one of three check types:
- Structural — schema validation, type checks, allow-lists, or bounds on a field. The payload either conforms or it does not.
- Policy — an explicit rule expressed in code: this account may not be charged above a limit, this path is read-only, this table is off-limits.
- Sign-off — a required human or upstream approval before the action is released.
The outcome is binary and legible: pass and the action proceeds unchanged, or fail and it is blocked, with a reason you can log and replay. Crucially, the guardrail does not try to improve the output or reason about intent. It bounds the blast radius of a stochastic system by refusing anything outside a shape you defined in advance. That narrowness is the point — a check you can reason about completely is worth more at a consequential boundary than a smarter check you cannot.
Why it matters in an agent harness
An agent loop is non-deterministic by construction. The same prompt can yield different tool calls across runs, and a single bad call at a write boundary can be expensive or irreversible. Deterministic guardrails are how you keep a stochastic core inside a predictable envelope without slowing the loop to human speed.
They buy several concrete properties:
- Containment. A guardrail on a destructive tool caps what any single misfire can do, regardless of how the model got there. The failure is bounded before it becomes an incident.
- Reversibility. Pairing a guardrail with a checkpoint or a dry-run means a blocked or suspect action leaves state recoverable rather than half-applied.
- Observability. Because the verdict is deterministic, every block is reproducible. You can replay the exact input, see the exact rule that fired, and trust that a green result means the same thing today as it did last week.
- Permissions as data. Encoding scope as a guardrail — least-privilege paths, spend caps, environment fences — turns "the agent should not do that" from a hope in the prompt into an enforced boundary the model cannot argue past.
The harness gets stronger as you move safety off the model's shoulders and onto checks that do not vary. The model stays free to explore; the boundary stays fixed.
Deterministic guardrail vs model-based check
Both screen an action, but they fail differently, and the difference should drive where you use each.
| Deterministic guardrail | Model-based check | |
|---|---|---|
| Verdict | Same every time for the same input | Varies; itself non-deterministic |
| Expresses | Rules you can state exactly | Judgment that resists exact rules |
| Auditability | Full — replay the rule | Partial — you audit a probability |
| Best at | Hard limits, schemas, scope, spend | Tone, nuance, fuzzy policy |
| Failure mode | Too rigid; blocks valid edge cases | Silently wrong; passes bad input |
Use a deterministic guardrail where the cost of a wrong action is high and the rule is expressible — a spend cap, a write scope, a required field. Use a model-based check where the property is genuinely fuzzy and a false block is cheaper than the nuance you would lose. In practice they layer: the deterministic guardrail enforces the hard boundary, and a model-based check advises inside it.
The Rifty take
We put the deterministic guardrail closest to anything irreversible and let the model be creative everywhere behind it. The tradeoff we accept is that a rigid check will occasionally block a legitimate edge case — we would rather tune a boundary that failed loud than trust a boundary that might fail silent. The rule we hold: if an action is consequential, the thing standing in front of it should give the same answer every time and log why. Safety you cannot replay is not safety you can operate.
Implementation checks
- Put the guardrail on the action, not the prompt. Instruction-level constraints are advisory; a check at the tool boundary is enforced.
- Make blocks explicit and logged — the rejected input, the rule that fired, and a replayable record — so a failure is an artifact, not a mystery.
- Fail closed on consequential paths. When the guardrail itself errors, block rather than pass.
- Keep the rule narrow enough to reason about completely; a check you cannot fully explain is not deterministic in practice.
- Version guardrails alongside the code they protect, so a green verdict means the same thing across runs.
- Pair each guardrail with a recovery path — checkpoint, dry-run, or rollback — so a blocked or suspect action never leaves state half-applied.
Frequently asked questions
How is a deterministic guardrail different from a normal guardrail?
A deterministic guardrail is a subclass of guardrail whose verdict is fixed and repeatable — the same input always yields the same pass or block. A general guardrail may rely on a model or heuristic and vary run to run. Determinism is what makes the check auditable and replayable at consequential boundaries.
When should I use a deterministic guardrail instead of a model-based check?
Reach for a deterministic guardrail when the failure is expensive and the rule is expressible in code — spend caps, write scopes, schema shape, required fields. Use a model-based check for genuinely fuzzy properties like tone or nuanced policy. In practice, layer them: deterministic for the hard limit, model-based for judgment inside it.
Where in an agent loop should the guardrail sit?
Place it on the action boundary — between the proposed tool call and its effect — not in the prompt. Prompt-level constraints are advisory and the model can drift past them. A check at the tool or write boundary is enforced regardless of how the model reasoned its way to the call.
What is the main failure mode of a deterministic guardrail?
Rigidity. Because the rule is fixed, it can block legitimate edge cases the author did not anticipate, creating false positives. The mitigation is to fail loud and logged so blocks are visible and tunable, and to keep rules narrow enough to reason about rather than broad and brittle.
Should a guardrail fail open or fail closed?
On consequential paths, fail closed: if the guardrail itself errors or cannot evaluate, block the action rather than let it through. Failing open turns your safety boundary into a silent no-op exactly when something is already wrong. Reserve fail-open only for low-stakes, easily reversible actions.