The guardrail I installed did nothing — during the incident it was installed to prevent
Everyone assumes
The risk is the control you never got around to adding. Once a guardrail is in place, that box is ticked.
What we found
The dangerous control is the one that exists and silently doesn't run. Ours read configuration that was never set, so it approved everything — including during the exact runaway it had been built to stop.
The evidence
Same shape, repeatedly, in our own systems: a spend guard that read environment variables nobody had set and therefore allowed every request; a hook that fired correctly but whose real work was piped into `2>/dev/null` for weeks; model settings that were parsed and then ignored for months. Each was visibly “installed” the whole time.
Why it happened
A guardrail that fails OPEN is indistinguishable from a working one right up until the moment you need it — because both produce no complaints. Nobody audits a control that never fires; a quiet guard reads as a well-behaved guard.
What it costs you
Spend limits are the obvious case. An unmetered fan-out with a limit that silently isn't enforcing is not protected — it just feels protected, which is worse, because it licenses bigger bets.
Check your own setup
Take your most important limit — a budget cap, a rate limit, an approval gate. Deliberately trip it in a safe environment. If it doesn't stop you, it has never been stopping anyone.
Our own spend-guard incident; the general lesson is: audit your enforcement, not your intentions.