Default-deny is the only safe posture for AI agents

Most security incidents with AI agents don't come from an attacker. They come from the agent itself doing something plausible, confident, and wrong. That's what makes agents different from ordinary software: the actor is non-deterministic. You cannot enumerate everything it might try. So you cannot secure it with a blocklist.

The only posture that holds is the opposite one: deny by default, allow on purpose.

Blocklists assume you can predict the mistake

A blocklist says "everything is allowed except these known-bad things." That works when behavior is bounded. An agent's behavior is not. It can phrase a database query a thousand ways, chain tools you didn't anticipate, or interpret an instruction in a direction no one on your team imagined. Every gap in your blocklist is an action waiting to happen.

An allowlist inverts the risk. "Nothing is allowed except these known-good things." Now the gaps fail safe. An action you didn't think of is denied, not permitted -- and you find out because it shows up in your audit log, not in your incident report.

What default-deny looks like in Enforgate

Enforgate's policy engine is default-deny to the core:

• Rules are evaluated in priority order, and the first match wins.
• If no rule matches, the call is denied. Silence is not consent.
• If a policy has a malformed rule -- say, an invalid regex -- that rule simply never matches, and the default-deny behind it catches the call.
• If the audit write fails, the call fails too. An action that can't be recorded doesn't run.

// A policy that allows exactly one thing -- everything else is denied.
[
  { "tool": "db_query", "decision": "allow" }
]

With that policy, db_query runs. delete_file, send_email, and any tool you've never heard of are all denied, because nothing allowed them.

Fail closed, everywhere

Default-deny is only meaningful if every failure mode agrees with it. A boundary that denies by default but "allows on error" is just a blocklist with extra steps. Enforgate is deliberate about this: no policy means deny, a bad rule means deny, an infrastructure failure means deny. The safe direction is the default direction.

The objection, and the answer

"Won't an allowlist slow us down?" A little, at first -- you have to name what your agent is allowed to do. But that list is small, it's explicit, and it's the same list your security team was going to ask for anyway. Naming it up front is far cheaper than discovering it after an agent did something you can't take back.

Start from deny. Add each capability on purpose. That's the posture that lets you put an agent near production and sleep at night.