Fail-Closed Control

How it works

A fail-closed control treats permission as something the harness must positively establish, not infer from the absence of an objection. Before an agent crosses a control boundary, the harness evaluates explicit evidence: the proposed action, applicable policy, current authorization, validation results, and any required approval. The action proceeds only when every required condition resolves to an allowed state.

A typical control sequence is:

1. Normalize the proposed action into a form that policy code can inspect.
2. Identify the permission, approval, and validation requirements for that action.
3. Verify the evidence against authoritative state rather than relying on the agent’s description.
4. Permit execution only when all mandatory checks return an unambiguous pass.
5. Otherwise block the action and record which requirement was absent, invalid, or unresolved.

The closed state must include more than an explicit denial. Timeouts, malformed approvals, unavailable policy services, mismatched proposal identifiers, stale credentials, and indeterminate verifier results should also block execution when the action is consequential. This does not mean terminating the entire run. The harness can preserve state, request clarification, retry a safe read, or route the proposal for review. What it must not do is reinterpret uncertainty as permission.

Why it matters in an agent harness

Agents routinely operate across boundaries that language alone cannot secure. A model can misunderstand scope, carry stale instructions forward, or produce a plausible explanation for an action it was never authorized to take. Fail-closed control makes the harness, rather than the model, responsible for deciding whether execution is allowed.

This separation improves control because capability and permission remain distinct. Giving an agent access to a deployment tool does not authorize every deployment. The harness can require a matching approval, a validated target, an acceptable diff, and credentials scoped to that environment before the tool call is released.

It also limits blast radius. If an approval store is unavailable, a policy result cannot be parsed, or a proposal changes after review, the safe result is a blocked write rather than an unverified mutation. Reads and reversible preparation may continue under separate policies, so one failed control does not have to collapse unrelated work.

Observability is part of the mechanism. A useful fail-closed decision records the proposed action, policy version, evidence checked, decision, reason, and resulting state transition. Without that record, operators cannot distinguish a deliberate denial from an infrastructure failure or a harness defect. Repeated closed decisions can reveal broken approval flows, expired credentials, overly broad policies, or controls placed at the wrong boundary.

The tradeoff is availability. A strict control may delay legitimate work when evidence systems fail. That cost is justified at boundaries where an incorrect action is harder to recover from than a delayed one. It is usually excessive for low-risk, read-only exploration. The engineering task is therefore to classify actions by consequence and place fail-closed enforcement around the mutations, disclosures, and authority changes that demand positive proof.

Fail-Closed Control vs fail-open control

The distinction changes what happens when the harness cannot reach a confident decision.

Fail-open behavior is not automatically defective. A cache, optional enrichment step, or non-authoritative advisory check may reasonably degrade without stopping safe work. The dangerous pattern is accidental fail-open behavior at an authorization boundary, often introduced by permissive defaults, broad exception handling, or treating a missing decision as false for “deny” and then negating it incorrectly. The policy should name which failures may degrade and which must close the gate.

The Rifty take

We optimize for positive evidence at consequential boundaries. We accept delayed execution when the alternative is silently converting missing state into authority, while allowing separately authorized read-only or reversible work to continue. A closed gate should preserve enough state and explanation for recovery, not leave the operator with an opaque refusal.

Implementation checks

• Define the exact actions and resources protected by the control boundary.
• Represent allow, deny, and unresolved as distinct outcomes. Do not collapse uncertainty into a Boolean.
• Read approvals and policy inputs from authoritative state, not from agent-authored prose.
• Bind approval to the reviewed proposal, target, parameters, and relevant version or hash.
• Treat missing, expired, malformed, mismatched, and unverifiable evidence as non-authorizing.
• Keep enforcement outside the model prompt and immediately before the protected action.
• Record the decision inputs, policy version, outcome, reason, and resulting state transition.
• Provide a recovery path such as safe retry, renewed approval, corrected proposal, or operator review.
• Test timeouts, partial outages, stale approvals, changed proposals, and verifier exceptions.
• Confirm that blocked writes cannot be bypassed through another tool, worker, or orchestration path.

Frequently asked questions

Which agent actions should use fail-closed control?

Use fail-closed control where an incorrect action could create material, difficult-to-reverse consequences. Common boundaries include external publication, destructive writes, credential use, sensitive disclosure, financial commitments, production changes, and permission expansion. Low-risk reads or reversible preparation can follow separate policies when blocking them would add little containment value.

Should a policy-service outage stop the entire agent run?

Not necessarily. It should block actions whose authorization depends on that unavailable service. The harness may preserve the checkpoint, continue independently authorized reads, retry safely, or request review. It should not permit the protected action using cached assumptions or permissive defaults unless an explicit, bounded degradation policy already authorizes that behavior.

How is fail-closed control different from an approval gate?

An approval gate is one possible control point, while fail-closed describes its decision behavior under missing or unresolved evidence. An approval gate is fail-closed only if absent, stale, malformed, or mismatched approval blocks execution. A gate that continues after a timeout or validation error is effectively fail-open.

Can fail-closed controls make an agent harness unreliable?

They can reduce availability if applied too broadly or backed by fragile evidence services. Reliability therefore includes both containment and recoverability: narrow the protected boundary, preserve resumable state, distinguish denial from infrastructure failure, and provide safe retry paths. Removing the control merely converts visible delay into the risk of unauthorized execution.

How should fail-closed behavior be tested?

Test negative and indeterminate paths, not only explicit denials. Remove approvals, expire credentials, alter a reviewed proposal, corrupt policy evidence, time out the verifier, and throw enforcement exceptions. Each case should block the protected action, emit a specific reason, preserve recoverable state, and resist bypass through alternate execution paths.