Guardrails

The design principle is that a guardrail must not depend on the component it is guarding. Instructing a model to refuse certain requests is a preference, not a control — it operates in the same channel as the input trying to subvert it. A guardrail is a check outside the model: a schema the output must parse against, an allowlist the tool arguments must match, a spend ceiling enforced by the caller, a step limit that halts the loop. These fail closed and cannot be argued with.

In agent systems the highest-value guardrails cluster around actions rather than text. Separate read-only tools from mutating ones and grant them different credentials. Require an explicit approval step for anything irreversible. Scope every credential to the narrowest resource that works. Cap loop iterations and total tokens so a confused agent fails cheaply instead of expensively. Log every tool invocation with its arguments so an incident can be reconstructed afterwards.

Two misconceptions recur. The first is that a model-based classifier counts as a hard control; it is a useful probabilistic filter, and it belongs behind, not instead of, a deterministic check. The second is that guardrails are a launch checklist item. They are load-bearing architecture — retrofitting them onto a system whose tools were designed without permission boundaries usually means redesigning the tools.