Fail-closed gate

A fail-closed gate is a control whose own failure blocks the action it guards rather than letting it through, so that a check which is skipped, errored, misrouted, or left unattended denies by default instead of allowing; it is the security-oriented counterpart to a fail-open gate.

How it works

Fail-closed is a posture a control takes, not a separate mechanism: a validator, a runtime hook, or an approval step is fail-closed when it treats every outcome other than an explicit pass as denial. So if the check is skipped, throws an error, returns an ambiguous signal, or never runs on the route it should guard, the action it protects does not proceed. The principle predates agents and comes from security engineering: when the mechanism fails it should follow the same path as a denial, so an authorization or validation routine denies on exception rather than accidentally allowing. The contrast is the accidental fail-open gate, which lets the action through on its own failure and so keeps minting the appearance of control while enforcing nothing; a deliberate fail-open mode is different, and is legitimate when it is explicit, logged, and limited to cases where blocking is the greater hazard. Making a gate fail closed is a deliberate design choice at each failure branch, not a default that comes for free, because the convenient branch is usually the one that lets work continue. The cost is that a brittle or noisy gate now blocks real work when it misfires, which is the price the posture trades for never failing silent.

Why it matters

The failure mode of a gate matters more than its happy path, because a control you lean on is most dangerous exactly when it quietly stops working. A fail-open gate that errors leaves a system that looks guarded in its configuration while being unguarded in its behavior, and the audit trail says protected while the execution path disagrees. Fail-closed is what makes a gate's green signal mean something, because a pass becomes a real verdict rather than the default that happens when nothing ran. The trade-off is honest, since a fail-closed control will sometimes block legitimate work when it breaks, and that friction is the visible cost of refusing to fail silently. For security and integrity controls, where an unsafe allow is worse than a temporary stop, that is the right trade, because a blocked-but-loud failure is recoverable while an allowed-but-silent one is the incident you find out about later. The posture is not universal: on life-safety, emergency-access, or availability-critical paths, blocking can be the greater hazard, so the failure posture, whether fail-closed, fail-open, fail-operational, or break-glass, should be chosen by what the gate guards.

In practice

A deterministic check runs before an agent's change can merge, and it is wired so that if the check cannot fetch the artifact it is supposed to inspect, it returns a failure rather than a pass. A non-interactive run with no human present resolves an approval step to denied, not approved, so an unattended pipeline cannot wave work through. When the check itself throws, the merge is blocked and the error surfaces, rather than the change slipping in because the guard fell over quietly. The gate's job in every one of those cases is the same: when it cannot prove the work is safe, it says no.

Practical considerations

Decide the behavior of each failure branch explicitly, because the default a quick implementation reaches for is usually fail-open: a missing config, an empty input, or an unhandled exception that lets work continue. Test the gate by breaking it, not only by passing it, since a gate that has only ever been exercised on clean input has an unverified failure path. Pair fail-closed with a clear, loud error, so the block is debuggable rather than mysterious and the friction pushes toward fixing the gate rather than removing it. Be deliberate about noisy gates, because a control that fails closed too often on false alarms trains people to bypass it, which reintroduces the fail-open risk through the side door. Reserve the strict posture for the controls that are genuinely load-bearing, and let lower-stakes checks warn rather than block, so the friction lands where it is worth paying. On a critical path a fail-closed gate becomes availability-critical infrastructure, so it needs monitoring, a bounded blast radius, and an audited break-glass path, or the control itself becomes a denial-of-service vector.

Defined by Ready Solutions AI