[THOUGHT LEADERSHIP]

[

1/27/26

]

Fail-Closed vs Fail-Open: The Default That Decides Whether Your AI Agent Is Safe

[Author]:

Amjad Fatmi

There is one question that exposes everything about how an agent system handles uncertainty.

What happens when no policy matches?

The action the agent wants to take isn't on the allow list. It isn't on the deny list. There's no rule for it. The governance layer has no opinion.

What happens?

In almost every system built today: the action executes.

That's fail-open. When uncertain, proceed. When no rule applies, allow. When the system doesn't know, trust the agent.

We think that's backwards.

What fail-open looks like in practice

You write policies for the cases you've thought of. An agent hits a case you haven't thought of. The governance layer has no matching rule. The action proceeds.

This is the exact moment that matters most. The moment something unexpected happens is the moment you most need a gate. Fail-open removes the gate precisely then.

Every guardrail in the industry works this way. Score below threshold: proceed. Pattern not matched: proceed. No rule found: proceed. The default everywhere is execution.

This made sense when agents were doing low-stakes work. When the worst case was a badly worded email draft, failing open was fine. The cost of over-blocking was higher than the cost of the occasional mistake.

That tradeoff has flipped.

The tradeoff that flipped

Agents now touch production systems. They issue refunds, modify databases, send external communications, provision infrastructure. When an agent hits an unexpected case in this environment, the question is not "will this be slightly wrong?" It's "how much damage can this do before someone notices?"

In that environment, fail-open is not a reasonable default. It is a liability.

The math changed. The cost of a blocked action is a human getting notified and approving it manually. The cost of an unintended action on a production system is an incident, potentially a serious one.

When the cost of false negatives is high and the cost of false positives is low, your default should be denial. That's not a philosophy. That's arithmetic.

What fail-closed actually means

Fail-closed means: if no policy matches, the action does not execute.

Not "probably doesn't execute." Not "executes with a warning." Does not execute. The agent stops. A human gets notified. Someone with authority makes a decision about whether this case should be permitted, and if so, adds a policy for it.

This has three consequences people don't expect.

First, it forces you to be explicit. You cannot accidentally permit something by failing to think of it. Every permitted action class is in the policy because someone put it there. Omission is denial.

Second, it improves your policy over time. Every time an agent hits a case with no matching rule, you get a signal. A real case, from production, that your policy didn't cover. You decide: allow, deny, or require approval. Your policy gets better with every gap it surfaces.

Third, it changes the trust model. You are no longer trusting that your policies cover everything. You are trusting that anything not covered is blocked. These feel similar. They are not. The second one is actually true.

The objection everyone raises

"Fail-closed will break everything. Agents will be constantly blocked. Users will turn it off."

This is a real concern stated incorrectly.

If fail-closed breaks everything, it means your policy doesn't reflect what your agent actually does. That is information. Critical information. Your agent is doing things you haven't explicitly authorized. The fail-closed system didn't create that problem. It made it visible.

The answer is not to go back to fail-open. The answer is to write the policies. Start with a default-allow policy for low-risk action classes during onboarding. Graduate toward explicit policies as you understand what your agent actually does. The system tells you what cases need policies. You add them.

Fail-open doesn't protect you from that problem. It hides it until something goes wrong.


The industry default is a design choice, not a law

Fail-open is not the only way to build this. It is the default that emerged because it was easy, because the stakes were low, and because nobody was thinking carefully about what happens at the execution boundary.

The precedents for fail-closed in security are everywhere. Firewalls deny by default. Kubernetes admission controllers block by default. Zero-trust networks deny by default. In every domain where the consequences of unexpected behavior are serious, the default is denial.

Agent execution is no different. The consequences are just as real. The principle is the same.

Everything in the agent ecosystem is fail-open. If the guardrail doesn't catch it, the action proceeds. If the policy doesn't match, the action proceeds. If the governance layer is uncertain, the action proceeds.

We think that's backwards.

The right default when a system doesn't know whether something should run is: it doesn't run.

That's not a product feature. That's a philosophy. And it's the one the industry needs to adopt before the incidents force it to.


Previous

More

Previous

More

[GET STARTED IN MINUTES]

Ready to give Faramesh a try?

The execution boundary your agents are missing.
Start free. No credit card required.

[GET STARTED IN MINUTES]

Ready to give Faramesh a try?

The execution boundary your agents are missing.
Start free. No credit card required.