- In short
- Fail-open and fail-closed describe what a guardrail does when it errors, times out, or becomes unreachable: fail open lets the request through unscreened, fail closed blocks it until the control is healthy. If the direction is not chosen explicitly, the surrounding code usually defaults to letting traffic through, so a screening service that silently passes on error looks healthy while providing none of its protection. High-consequence checkpoints should fail closed even at the cost of availability.
A guardrail is a dependency, and dependencies fail
A control that screens requests can fail exactly the way any dependency fails: it can time out, return an error, or become unreachable under load. The CCAR-P exam treats deciding what happens then as an apply-level skill, because the failure of a guardrail is uniquely deceptive. Unlike a database that goes down loudly, a screening service can error and still let traffic flow, so requests keep succeeding while the control does none of the work it was placed there to do.
That is why the failure direction is a design decision, not an implementation detail. When a guardrail errors, the system must do one of two things: let the request through, or block it. If you have not chosen, the surrounding code chooses for you - and the default is almost always to let the request through, falling back to the unprotected path. The same reasoning that put retries and circuit breakers around your model calls applies here: decide how the control behaves when it fails, rather than inheriting whatever behaviour happens to keep requests flowing.
- Fail-open vs fail-closed design
- The explicit choice of what a guardrail does when it errors, times out, or is unreachable. Fail open passes the request through unscreened; fail closed blocks it until the control is healthy. Left unchosen, code defaults to fail open, so a screening service that silently passes on error appears healthy while providing none of its protection. High-consequence checkpoints should fail closed.
Why fail-open is the dangerous default
The insidious part of failing open is that it looks like success. When a screening service errors but still passes traffic, the dashboards stay green, requests keep completing, and latency may even improve because the check is being skipped. Nothing surfaces the fact that the protection is gone. An operator-built guardrail that silently passes traffic when it errors is worse than one that blocks traffic, because it gives you the reassurance of having a control while providing none of the function.
This is precisely the state an audit or an incident later exposes. The control existed on the diagram, was configured, and was assumed live - but during the window it was erroring, it protected nothing, and no one knew. Choosing fail-open by accident is how a guarded system quietly becomes unguarded without any change to the architecture.
When fail-closed is the right call
High-consequence checkpoints should fail closed even at the cost of availability. If a checkpoint guards a financial action, an irreversible operation, or the exposure of PII, the cost of a single unscreened action slipping through outweighs the cost of temporarily blocking traffic until the control recovers. Failing closed degrades the system deliberately - it becomes unavailable rather than unprotected - which is the safer failure for anything that cannot be undone.
One boundary matters for the exam: this decision applies only to the controls your team builds, hosts, and configures. Anthropic's own model-level safety controls are not operator-configurable and are outside the fail-open/fail-closed choice - they do not fail open. The decision is exclusively about your operator-built screening, authorization, and review components.
What the CCAR-P exam trips candidates on
The first trap is choosing fail-open for a checkpoint that guards an irreversible action because it "keeps the system available." The scenario frames availability as the responsible engineering choice, and a candidate who does not weigh the cost of an unscreened action slipping through takes the bait. The credited reasoning is that for an irreversible or high-cost action, an unscreened request getting through is far more expensive than a temporary block, so the checkpoint fails closed.
The second trap is treating a guardrail error as equivalent to a guardrail pass. A scenario shows a screening call that timed out, and the system continued as though the check had returned "safe." The credited reading is that an error is an undefined state, not a pass - it must be resolved by the direction you chose in advance, which for a consequential checkpoint means blocking. The exam rewards candidates who never let "the check couldn't run" silently become "the check said yes."
Worked example
A screening service that sits in front of a payments agent starts timing out under load. The application was written to continue if the screening call does not return in time, so during the incident thousands of payment requests were processed with no screening, and the monitoring showed the system as healthy the whole time. What was the design flaw, and how should it be corrected?
The flaw is an unchosen failure direction that defaulted to fail-open. Nobody decided what the screening step should do when it timed out, so the surrounding code did the ordinary thing and let requests continue. Because the requests kept completing, every health signal stayed green - the classic deceptive failure, where the appearance of protection persisted while the protection itself was gone.
The correction is to make the failure direction explicit and, for this checkpoint, fail closed. Screening in front of a payments action guards an irreversible, high-cost operation, so when the check cannot run, the safer state is to block the payment until screening is healthy again rather than to process it unscreened. The system should degrade to unavailable, surface the error loudly, and treat the timeout as the undefined state it is - never as a silent pass.
There is a monitoring lesson too: a guardrail that can fail open needs an alert on its error rate, not just on request success, so that "the control is erroring" is visible before an audit finds it. But the primary fix is the deliberate fail-closed choice on a checkpoint whose action cannot be undone.
Common misreadings to avoid
Misconception
Failing open on a screening checkpoint is the responsible choice because it keeps the system available.
What's actually true
Misconception
If the guardrail call errors or times out, the request has effectively passed the check.
What's actually true
How this shows up on the exam
Domain 5 items describe a guardrail that errored, timed out, or was unreachable and ask what the system should have done. The reliable method is to identify what the checkpoint guards: if the protected action is irreversible or high-cost, the checkpoint fails closed, and any design that let traffic through on error - by choice or by default - is the flaw. Watch for scenarios where the monitoring looked healthy; that is the signature of a silent fail-open.
This decision completes the guarded path defined in the three-point guarded request path and pairs with model-based vs deterministic check selection, since the check type and its failure behaviour are chosen together. Failing open is one of the missing-control patterns a system vulnerability walkthrough is meant to surface, and it precedes skill supply-chain auditing, where a runtime sandbox is the fail-closed backstop for a control that misses something.
A screening service in front of an irreversible financial action begins timing out under load, and the application continues processing requests, showing healthy dashboards throughout. What is the correct design and diagnosis?
People also ask
What is the difference between fail open and fail closed?
What happens if I do not choose a failure direction?
Which checkpoints should fail closed?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.