The Guardrail That Only Fires After the Damage Is Done

# The Guardrail That Only Fires After the Damage Is Done A content-moderation guardrail on an agent pipeline had a 100% catch rate in every audit. It also let through months of exactly the output it existed to stop. Both things were true because the guardrail was checking the agent's final response — after every tool call, every write, every side effect had already happened. ## Post-hoc checks audit the output, not the action The pipeline's guardrail ran a classifier over the agent's final text response before it was shown to a user, and blocked anything that scored above a threshold. On the metric everyone was tracking — "did any flagged text ever reach a user" — it worked. But the agent's job wasn't just to produce text. Along the way, it wrote records to a database, sent notifications, and updated an external CRM. If the reasoning that produced a bad final answer also produced a bad intermediate action, the guardrail never saw it, because the guardrail only looked at the last step. This is the shape of a lot of agent safety work: the check is bolted onto the output boundary because that's the easiest place to intercept something before a human sees it. It's also the latest possible place to intercept something, which means it's structurally blind to anything that happens earlier in the chain. ## The audit was measuring the wrong surface Every review of the guardrail asked "does this block bad text," and the answer was reliably yes. Nobody was asking "does this block bad actions," because the actions weren't part of what got reviewed — they were implementation detail, invisible unless you went looking at the tool-call log rather than the chat transcript. The 100% catch rate was real and also almost entirely beside the point, because the point was never really "don't show bad text." It was "don't cause harm," and by the time text is being generated, most of the actions that could cause harm have already run. ## Moving the check earlier changes what it can catch The fix was to run a lighter-weight version of the same classification logic before each tool call that had a real side effect — write, send, notify — using the agent's stated intent for that call rather than its polished final response. This is a worse text classifier in isolation: intent statements are terser and less context-rich than a finished response, so it has a higher false-positive rate. It is a categorically better guardrail, because it can actually stop the write from happening instead of just hiding the write's summary from the user afterward. The tradeoff is real and worth naming rather than glossing over: earlier checks are noisier and will block some legitimate actions the output-stage check would have let through cleanly, because there's less information to work with at that point. That's not a flaw to engineer away, it's the actual cost of catching things earlier — you're trading precision for reach. A team that wants zero added friction should keep the output-stage check and accept that it only ever catches the fraction of harm that happens to route through the final response. The question worth asking about any agent guardrail isn't "what's the catch rate." It's "what's the latest point in the chain where this check runs, and what already happened before it got there." A guardrail with a perfect catch rate on the wrong surface is a guardrail that's already too late.