Guardrails
Deterministic checks applied to model inputs and outputs, enforcing constraints that the model itself cannot be relied upon to respect.
The premise is that a model's behaviour is probabilistic and its instructions are persuadable, so anything that must always hold has to be enforced outside it.
Input guardrails run before inference: detecting injection attempts, stripping or flagging personal data before it leaves the estate, blocking prohibited requests, and enforcing size and rate limits.
Output guardrails run after: schema validation where structured output is required, which is the most valuable and least discussed of them; checking that claims are supported by the retrieved context; scanning for personal data or secrets in the response; policy checks for prohibited content; and verifying that any action the model proposes is within the permitted set.
The design decision that matters most is what happens on failure. Blocking is safest and produces a poor experience if it fires often. Regeneration with feedback frequently succeeds on a second attempt and adds latency and cost. Falling back to a deterministic path or to a human is the right answer for high-consequence flows.
Two cautions. Guardrails implemented as another model call inherit the same probabilistic behaviour and can themselves be manipulated, so the strongest guardrails are deterministic — schema validation, allowlists, permission checks — rather than model-based classification. And every guardrail adds latency, so their placement should follow the consequence of the failure they prevent rather than being applied uniformly.