Fail-Open vs Fail-Closed: What an AI Agent Guardrail Should Do When the Check Fails
Decide by the action, not by the guardrail. Irreversible, consequential actions fail closed: no verdict means the action waits or goes to a person. Reversible and advisory actions can fail open, as long as every unchecked action is recorded as unchecked. And whichever you choose, a missing verdict must never be stored as a pass.
On this page
Every guardrail is a dependency. The policy check, the judge model, the classifier on the request path: each of them can time out, crash, or return something unusable. When that happens, your agent is waiting on an answer that is not coming, and some piece of code decides what happens next.
That code is usually written in an afternoon, often as an exception handler that logs a warning and lets the request through. It is one of the most consequential decisions in the system.
What fail-open and fail-closed mean for an AI agent
Fail-open: when the check cannot produce a verdict, the action proceeds as if it had passed.
Fail-closed: when the check cannot produce a verdict, the action does not proceed.
For an agent, "cannot produce a verdict" covers more than an outage. A check can fail in at least four ways:
- Unreachable. The service is down, or the network between the agent and the check is.
- Too slow. It answers after the latency budget the caller was willing to wait.
- Unusable. A model-based judge returns something that is not a valid verdict: malformed output, a missing field, a placeholder.
- Uncertain. The judge says, honestly, that the evidence is not enough to decide.
The fourth is the one most designs forget. A judge that can say "uncertain" has done its job — a judge that always has an answer is making some of them up. The caller still has to decide what uncertain means for this particular action.
Rule 1: Decide by the action, not by the guardrail
The tempting design is one global setting. The guardrail fails open, or it fails closed. Either way, it is wrong about half the time.
Fail-closed everywhere means a judge outage stops every agent, including the ones drafting internal summaries. Teams that live through that once tend to switch the guardrail off. Fail-open everywhere means an outage is the moment every payment, production write and customer message goes unchecked, which is exactly when you can least see what is happening.
What sorts it is whether the action can be undone, and what it costs if it should not have run.
| Action type | Examples | When the check fails |
|---|---|---|
| Irreversible and consequential | Payment, trade, production write, message to a customer, setpoint change | Fail closed. Hold, queue, or escalate to a person |
| Reversible but costly | Ticket update, staging config change, internal email | Fail closed with a short timeout, then escalate |
| Advisory or read-only | Draft, summary, search, internal analysis | Fail open, recorded as unchecked |
This is the same line OWASP draws in its guidance on excessive agency (LLM06:2025): human approval for high-impact actions, and authorisation enforced in the downstream systems rather than left to the model. It is also the reason to judge an action before it runs rather than review the logs afterwards. The case for checking first is the actions you cannot take back.
Rule 2: A missing verdict is not a pass
Whichever way the action goes, the record has to say what actually happened.
The common bug is a default. The verdict field starts as "pass", or a score starts at a safe-looking value, and when the check throws, the default is what gets written. Three months later the audit trail shows a clean approval for an action that nothing ever looked at.
Write the failure down as a failure: unchecked, judge unavailable, timed out, with the reason. In our own evaluation pipeline, when no judge manages to score a trace, the trace is recorded with the worst safety score and an explicit safety_eval_failed error, not left at a neutral value that would read as fine. A gap you can count is a gap you can close. A gap disguised as a pass is invisible.
The same goes for "uncertain". It must never be squeezed into "pass" because a downstream system only understands two values. If the caller cannot handle three states, the bug is in the caller.
Rule 3: Fall back to another checker before you fall back to nothing
Between "the check passed" and "no check happened" there is usually a third option: a second checker.
That might be a simpler, faster model. It might be a deterministic rule set that covers the highest-risk cases — amount ceilings, blocked destinations, known injection patterns. It might be the previous version of the judge. A degraded check is far better than none, as long as the record says which checker produced the verdict.
Our evaluation pipeline works this way. If the Nucleus judge is unreachable or returns no trustworthy verdict, that trace falls back to a secondary judge, and the fallback is logged per trace. That path scores traces after the fact, so availability matters more there than strictness; the code says it in so many words: the evaluation loop must never stall because one judge is down.
For a check that gates an action before it runs, the fallback idea is the same. What happens when the fallback fails too is Rule 1's decision, not the fallback's.
Rule 4: Fail-closed needs a way out, or it becomes fail-broken
A fail-closed check with no escalation route does not make the system safe. It makes it stuck, and stuck systems get their safety controls removed.
Every fail-closed path needs three things:
- A timeout per action class, so an agent never waits forever on a verdict.
- A queue with an owner. Held actions go somewhere a named person or team will see them, with a response time they have agreed to.
- A record of the human decision, so the eventual approval or rejection is as traceable as an automated verdict would have been.
What security engineering already says
None of this is new. Agents just make it urgent again.
Saltzer and Schroeder's 1975 paper, The Protection of Information in Computer Systems, lists fail-safe defaults among its design principles: base access decisions on permission rather than exclusion, so that when nothing has granted access, the answer is no. NIST SP 800-53 carries the same idea as control SC-24, fail in known state: on defined failures, a system goes to a defined state and keeps the information needed to recover.
For an agent, "permission rather than exclusion" means a consequential action needs a positive verdict to run. "Known state" means you decided in advance, per action class, what happens when that verdict cannot be had.
A fail-open vs fail-closed checklist for your design review
- List the agent's consequential actions. For each one: if the check is unavailable, does it proceed?
- Does every failure mode — unreachable, slow, unusable, uncertain — have an explicit outcome?
- Can a check failure ever be recorded as a pass? Search the code for the default.
- Is there a second checker, and does the record say which one decided?
- Where do held actions go, who owns that queue, and how quickly do they answer?
Where Syntrox fits
Nucleus, our judge, returns three verdicts, not two: pass, fail and uncertain. It returns uncertain rather than guessing when a grounded check arrives with no context to check against. Our evaluation workers fall back to a secondary judge when Nucleus is unavailable, and record any trace that no judge could score as a failure.
What an uncertain verdict or a judge outage should mean for a given action is, in our view, a decision for your risk owners to make per action class, not a vendor's default.