Review Fail-closed

A control is fail-closed when a failure, missing check, or unresolved uncertainty makes it deny, stop, or enter a restricted state instead of allowing the action to continue.

The system needs a valid yes before it proceeds. If a permission service is unavailable, a rule cannot be evaluated, or a required approval is missing, the safer default is to stop or reduce capability rather than assume permission.

AI agents can act across changing tools, identities, and data. A permissive default can turn a temporary outage or ambiguous state into an unauthorized action. A fail-closed design contains that uncertainty and creates a clear path for recovery or escalation.

An AI payment agent cannot reach the service that verifies transfer authority. It does not send the payment. It places the request in a restricted queue and asks an authorized person to resolve the failed check.

Fail-closed is not always the safest behavior for the whole system. A locked emergency exit, unavailable medical device, or blocked recovery path can create a different danger. Designers must choose the safe failure state for the actual consequences and provide a controlled way to recover.

If the check cannot say yes, the system says no.

* [[guardrails|Guardrails]] * [[exception|Exception]] * [[load-rejection|Load Rejection]] * [[human-oversight|Human Oversight]] * [[runtime-governance|Runtime Governance]]

* [NIST CSRC, “fail secure”](https://csrc.nist.gov/glossary/term/fail_secure) — describes termination that preserves a secure state when a failure occurs or is detected. * [IETF, RFC 4949, *Internet Security Glossary, Version 2*](https://www.rfc-editor.org/rfc/rfc4949.html) — provides the underlying security terminology for failure modes that do not compromise security.

* Identify which operations must stop through [[guardrails|Guardrails]] and which conditions require a documented [[exception|Exception]]. * Connect fail-closed behavior to live enforcement through [[runtime-governance|Runtime Governance]].