Fail-closed AI systems

Fail-open systems optimize availability: they execute unless a guard explicitly blocks. Fail-closed systems optimize safety: they do not execute unless explicitly permitted. AI systems that touch money, safety, or regulated data usually require fail-closed semantics at the execution boundary.

TrigGuard's three-valued decision model includes SILENCE for cases where proceeding or explicitly denying would be misleading. This is part of conservative automation, see decision model.

Most SaaS and internal platforms optimize for throughput: if nothing obvious blocks a request, it runs. That posture is rational for read-heavy traffic and reversible UI actions. It breaks down when automation can commit faster than humans can review: agents, pipelines, and controllers issue writes, transfers, and control-plane mutations at machine cadence. Fail-open at the execution boundary means uncertainty becomes a successful commit; the incident is discovered in logs or in a customer dispute, not prevented at the choke point.

Fail-closed is not "turn everything off." It means the executor treats missing authorization, ambiguous policy, or unverifiable evidence the same way a safety interlock treats an open circuit: do not proceed until a valid permit exists for this exact request context. That shifts engineering effort from post-hoc triage to making authorization fast and reliable enough that withheld work is rare and explainable.

Fail-closed behavior requires three concrete properties: a defined execution surface where side effects attach; an authorization evaluation that runs before that surface accepts work; and a default mapping from "no usable outcome" to withhold rather than permit. In TG-01 terms, evaluation returns PERMIT, DENY, or SILENCE; only PERMIT is consumable as evidence that execution may proceed for the bound frame.

Enforcement is separate: runtimes record whether work was executed or blocked. Decisions deny; systems block. That separation keeps dashboards from silently rewriting policy truth when an action slips through without a permit. For the full path from intent to enforcement, read the execution trace walkthrough.

Partial outages. Policy service slow or unreachable: a fail-open executor may race ahead; a fail-closed executor withholds until evaluation completes or returns an explicit deny.

Agent tool chains. Each hop can be externally visible; the last hop before a wire or export needs the same permit contract as the first, or the chain is only as safe as its weakest gate.

Drift between environments. If staging "mostly matches" production policy, teams learn the wrong muscle memory. Deterministic evaluation against a pinned policy version is what makes cross-environment behavior legible; see deterministic authorization.

TrigGuard places evaluation in front of execution surfaces and issues signed receipts on PERMIT so downstream systems and auditors can verify what was authorized without trusting a single log stream. Integrators wire Gate or the SDK so the runtime refuses commits that lack a valid permit for the declared frame. Policy lifecycle and separation of duties sit with Arbiter; offline checks use Verify. Commercial boundaries and deployment options are on Pricing.

Return to the cluster hub: AI execution governance.