The default-deny principle
In security engineering, fail-closed (also called default-deny) means that when a system cannot make a decision, it denies the request. Fail-open means it allows the request. For AI control systems, this choice determines whether ambiguity creates safety or risk.
A fail-closed AI control system denies execution when a policy cannot be resolved, an authority cannot be verified, a context dependency is unavailable, or the control plane is unreachable. The system does not guess, approximate, or defer to the AI system's own judgment. It stops.
Why fail-open is dangerous for consequential AI actions
Fail-open design prioritizes availability: the system continues operating even when governance is degraded. This is appropriate for low-stakes decisions — recommending a product, generating a draft, answering a question. It is dangerous for consequential actions: approving a wire transfer, modifying a firewall rule, deleting a database, or actuating physical machinery.
The risk is not merely that a wrong action executes. It is that the action executes without governance — without policy evaluation, without authority verification, without an evidence trail. A fail-open system that loses its control plane becomes an ungoverned system, and ungoverned AI systems taking consequential actions is precisely the scenario that kill switch architecture exists to prevent.
Graduated fail-closed design
A binary fail-closed/fail-open choice is too coarse for production systems. A mature architecture applies fail-closed behavior proportionally: non-consequential actions can bypass the control plane or fail open; consequential actions fail closed. The classification of 'consequential' is itself a policy decision, defined by the organization, not by the AI system.
Within the fail-closed path, the system can support graceful degradation: if the primary policy engine is unavailable, fall back to a cached policy set; if the cache is stale, fall back to a deny-all baseline; if the control plane is completely unreachable, block all consequential actions and alert operators. Each degradation step narrows the scope of permitted action.
Fail-closed in DecisionHypervisor
DecisionHypervisor implements fail-closed enforcement at the architecture level. In ENFORCED, PROXY_EXECUTION, and DELEGATED_ENFORCEMENT modes, when no policy matches a proposed action, the system returns AUTHORITY_NOT_FOUND and denies execution. The system does not fail open.
The policy engine uses fixed effect precedence: terminal deny (0) → deny (1) → route (2) → review (3) → escrow (4) → modify (5) → allow (6). Within an effect class, higher priority wins; rule ID is the final tie-breaker. This deterministic resolution means that the system's behavior is predictable and auditable — the same input always produces the same output, regardless of timing or load.