Skip to main content
GLOSSARY

Fail open vs fail closed

Toshendra Sharma

By Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

What a system does when a check cannot complete: fail open lets the request proceed as normal, fail closed applies the stricter path or denies it.

What the terms mean

Every check that sits in a request path can fail to produce an answer: a dependency times out, a signal is missing, a key cannot be fetched. Fail open means the request proceeds as if the check were not there. Fail closed means the request takes the stricter path: it is denied, challenged or sent to an existing stronger control.

Neither is correct in general. The right choice depends on what the route does and what a wrong decision costs.

Why it matters for actor checks

Actor checks add context to requests: whether the interaction looks human, AI-assisted, agent-driven or unknown. When that context is unavailable, the application still has to respond. Two failure patterns are common:

  • Accidental fail closed. A timeout or a missing signal is treated as suspicious, and real users get blocked during an outage.
  • Accidental fail open on sensitive actions. A missing result is silently treated as human, and a high-impact action proceeds with less scrutiny than intended.

Both come from leaving the choice implicit. The fix is to decide it explicitly, per route. Our post on designing app-level policies for humans and AI agents shows how failure behavior fits into a per-route policy.

How to choose

A practical approach is to group routes into risk tiers:

  • Low impact (public pages, documentation, read-only catalog routes): fail open. A missing actor result should not change anything.
  • Medium impact (signups, form submissions, searches with cost): usually fail open with logging, or apply a mild adaptation such as a standard rate limit.
  • High impact (account changes, data exports, irreversible actions): fail closed to your existing stronger control, such as re-authentication or confirmation. The point is not to block, but to fall back to the check you would use anyway.

Then define the same behavior for related cases:

  • Timeout: the check did not answer in time.
  • Missing telemetry: the integration did not run or a signal was absent.
  • Unknown: the check ran but the evidence did not support a determination.
  • Stale evidence: the result is from earlier and should not be reused for a more sensitive action.

Common misconceptions

  • "Fail closed is safer." It moves the cost to legitimate users. For low-impact routes, failing closed during an incident can do more harm than the risk it prevents.
  • "Unknown is a failure." Unknown is a valid result. It deserves its own explicit handling, which may or may not match your timeout handling.
  • "A missing result means human." Never infer an actor class from the absence of evidence.

How Proof of Actor treats it

Proof of Actor never assigns Human to a timeout or an Unknown result, and installing it does not block anything: teams start in observation mode. The fail-open or fail-closed behavior for each route and risk tier is the application owner's choice, applied in your own code through Route. That keeps enforcement predictable and lets you check outcomes before any policy goes live.

Read how routing decisions fit in, or apply for early access.

See actor intelligence in your own app.

Prefer to talk first? Talk to the founders