Agents Guardrail Concepts › What a guardrail is, and what it cannot be 12 of 12 steps written
01 — part 1, conceptsconcept

What a guardrail is, and what it cannot be

A guardrail is a check that can refuse.

The definition, and why it is narrow on purpose

Not a policy document, not a system prompt, not a warning printed beneath an answer, not a dashboard somebody reviews on Tuesday. A guardrail is code that runs while a request is in flight and has the authority to stop it. If it cannot stop anything it is monitoring — which is valuable, and a different thing with a different job that step 12 comes back to.

a check that can refuse everything else is monitoring, which is a different job a request in flight the check decides now from what it sees refused and somebody is told no allowed through the work begins both arrows are the same check working correctly
What moves: a request reaches the check and leaves by one of two arrows. The pink arrow is a refusal, the green one is the work beginning. Both are the check working correctly — which is the whole problem.
Nothing in this scene is measured. It is what a guardrail is; Part 3 prices them.

Three consequences, and they are the whole difficulty

because it…the consequence
decides nowit runs in the request's own time. It cannot wait for the incident review, or for a person to look, or for the next model release. Whatever it knows at the moment it runs is all it will ever know
decides from what it can seea check at the door sees a request. It does not see which tools the agent will reach for, what it will retrieve, or what it will eventually say — those have not happened. A check is a narrow instrument pointed at one moment
refuses real peopleevery refusal lands on somebody. At volume this is not a rounding error, and it is the line most often left off the comparison entirely

The third is the one that gets left out of comparisons, because the people paying it are not in the room. A guardrail that refuses a harmful request prevents an incident; the same guardrail firing on a request that was fine refuses a real person who wanted something reasonable. These are not two failure modes to be traded off later. They are the same event seen from two sides, and no amount of care makes one happen without risking the other.

The instinct this volume is written against

Faced with those three, the natural move is to install more checks. If one check is narrow, use six. If a check at the door can be evaded, add one at the exit as well.

Part 3 measures what that buys. On all three streams of traffic, the configuration containing every check in every legal position catches exactly what the winning configuration catches — and costs between 1.4 and 2.2 times as much. Not a little more safety for a little more money. The same catches, for more money.

What this volume does not cover

Adversarial machine learning — how to build a classifier that resists evasion — is a real field and is not this one. Every detector here is treated as a fixed instrument with a known blind spot, because the question being asked is where to point the instruments you have, not how to build a better one. A reader who wants the other question should know that within a page.