Why Fail-Open Authorization Is Dangerous

Fail-open is a design choice where a system defaults to allowing access when the authorization mechanism is unavailable. The logic seems reasonable: if we cannot check the policy, let the action through rather than breaking the workflow. Availability over security. Keep things moving.

For traditional systems with human operators, fail-open is a defensible trade-off. A human who gets through an authorization check they should not have passed will usually notice when things look wrong, stop, and ask for help. The human provides a backup governance layer.

For AI agents, fail-open is an open door with nobody watching it. An agent that gets through a failed authorization check does not notice that governance is absent. It does not pause. It does not ask for help. It continues optimizing for its objective, taking every action its reasoning suggests, with zero oversight.

How Fail-Open Happens

Fail-open is not always an explicit design choice. It often creeps in through implementation patterns that seem reasonable in isolation.

**Try-catch with allow.** The authorization check is wrapped in a try-catch. If the check throws an exception (timeout, connection error, malformed response), the catch block returns "allow." The developer's reasoning: "I don't want the whole system to break because the auth service is having a bad day."

// This pattern is dangerous for AI agents
async function checkAuth(intent: Intent): Promise<boolean> {
  try {
    const decision = await authService.evaluate(intent);
    return decision.allowed;
  } catch (error) {
    logger.warn("Auth service unavailable, allowing action");
    return true; // fail-open
  }
}

**Timeout with default allow.** The authorization check has a 500ms timeout. If it does not respond in time, the default is "allow." The developer's reasoning: "We can't add 500ms of latency to every action. If the check is slow, just let it through."

**Cache with stale allow.** Authorization decisions are cached. When the cache expires and the auth service is unavailable, the system uses the stale cache entry. But the stale entry was "allow" from an hour ago, and the policy has since changed to "deny." The system allows an action that should be blocked, using outdated authorization data.

**Degraded mode.** The system has a "degraded mode" that activates when the auth service is unhealthy. Degraded mode allows all actions and logs them for later review. The "later review" never happens because nobody built the review workflow. Every period of auth service instability becomes a period of zero governance.

What Happens in Practice

Consider a production environment with an AI deployment agent. The agent has governance checks that verify each deployment against change management policies. The governance service experiences a 15-minute outage due to a pod restart.

With fail-open, the deployment agent continues operating without governance for 15 minutes. During that window, it processes three deployments. Two are routine. One is a deployment to the production database cluster that should have been flagged for manual review because it contains a schema migration.

The schema migration runs. It drops a column. A downstream service fails. The incident takes four hours to resolve. The root cause investigation reveals that the governance check was bypassed because the auth service was restarting.

The incident was not caused by the deployment agent being malicious. It was caused by the deployment agent being ungoverned for 15 minutes. The agent did exactly what it was designed to do: evaluate deployments and push them through. It just did it without the guardrail that would have caught the risky migration.

The Accumulation Problem

Fail-open is especially dangerous for AI agents because of the accumulation problem. A single ungoverned action might be fine. Dozens of ungoverned actions over a 15-minute window compound risk.

An agent making 10 API calls per minute generates 150 ungoverned actions during a 15-minute auth service outage. Each individual action might be low-risk. But the cumulative effect of 150 ungoverned actions, potentially including actions that would have been escalated or denied, can be severe.

With fail-closed, the agent makes zero ungoverned actions during the outage. The impact is that the agent stops working for 15 minutes. That is disruptive. It is not catastrophic. The team notices immediately because the agent stops, they investigate, they find the auth service is restarting, and they fix it. The total impact is 15 minutes of agent downtime. With fail-open, the total impact is unknown and unbounded.

Why Teams Choose Fail-Open Anyway

Teams choose fail-open for understandable reasons. Availability is visible. Security is invisible. When the auth service is down and agents stop working, people complain. Tickets get filed. Managers ask questions. The problem is acute and obvious.

When the auth service is down and agents continue working without governance, nobody notices. There is no ticket. There is no complaint. The problem is silent. It only becomes visible when an ungoverned action causes an incident, which might be hours, days, or weeks later.

This asymmetry biases teams toward fail-open. The pain of fail-closed is immediate and attributable. The pain of fail-open is delayed and diffuse. But the total cost of fail-open incidents vastly exceeds the total cost of fail-closed downtime.

Why Intended Is Fail-Closed

Intended defaults to fail-closed because the alternative is unacceptable for production AI agents. When Intended is unreachable, agent actions are blocked. The agent receives a clear error indicating that governance is unavailable. The operational team is notified.

This is a deliberate architectural choice, not a default that can be toggled off in production. The fail-closed behavior is enforced at the SDK level. The `IntendedGuard` does not have a production configuration option for fail-open.

To make fail-closed operationally viable, Intended is designed for high availability. The evaluation pipeline is fully redundant across availability zones. Policy caches are local to each evaluation node, so a database failure does not affect evaluation latency or availability. The target is 99.99% availability for the evaluation endpoint.

Additionally, the SDK supports a local evaluation mode where policies are cached on the agent's host. If the Intended API is unreachable, the SDK evaluates against the local cache. The local cache is updated every 30 seconds during normal operation. This means that even during a Intended outage, agents continue to be governed by the most recent policy snapshot, not by a blanket "allow all" default.

The Middle Ground That Is Not

Some teams ask for a middle ground: fail-open for low-risk actions, fail-closed for high-risk actions. This sounds reasonable but creates a classification problem. How do you determine the risk level of an action when the system that computes risk scores is the system that is unavailable?

If you pre-classify actions into risk tiers, you are making a static risk assessment that misses the context-dependent nature of risk. A "low-risk" read operation might be high-risk if it is the 10,000th read in the last hour (indicating data exfiltration). A "low-risk" configuration change might be high-risk if it follows a security group modification.

The only honest answer is: if you cannot evaluate risk, you cannot authorize the action. Fail-closed is the only consistent position.

Making Fail-Closed Work

Fail-closed requires investment in the reliability of the governance layer. If fail-closed means agents stop every time the auth service hiccups, teams will remove the governance. The governance layer needs to be as reliable as the systems it protects.

This means redundancy, local caching, health monitoring, and fast recovery. It means the governance system is treated as critical infrastructure, not as an add-on that can tolerate occasional downtime. It means the same engineering rigor that goes into database availability goes into governance availability.

Intended is built with this understanding. Governance is critical infrastructure. It must be available. And when it is not available, the safe default is to stop, not to proceed blindly. Your AI agents will thank you. Or rather, your incident response team will thank you, when they do not have to clean up after 15 minutes of ungoverned agent operations.