TL;DR — Most production guardrails are implemented as a second LLM or classifier call wrapped in a try/except that defaults to allowing content when that call times out, rate-limits, or returns garbage. Teams stress-test whether the guardrail catches bad input, but almost nobody stress-tests what happens when the guardrail itself fails. That silent fail-open default is a bigger production safety risk than most of the jailbreaks it's supposed to stop.
Every guardrail architecture I've reviewed in the last two years shares the same shape: a pre-check on the input, generation in the middle, a post-check on the output. Each check is usually its own model call — a moderation classifier, a smaller judge model, sometimes the same LLM asked to grade its own output. Teams spend real effort tuning these checks. They red-team them, they measure precision and recall on adversarial prompts, they argue about thresholds in design docs.
Almost none of them ask the other question: what does the system do when the guardrail call itself fails?
The Try/Except That Ate Your Safety Policy
Go find the code. It's usually a few lines wrapping the moderation call in a try/except, and in the except branch, generation proceeds anyway. Sometimes there's a log line. Sometimes there isn't even that. The reasoning, when anyone bothers to articulate it, is reasonable-sounding: we don't want a moderation API outage to take down the whole product.
