Why denylist fails for agents
Denylist-based enforcement works when the attack surface is known and bounded. Block these IP ranges. Block these file extensions. Block these commands. The list of bad things is finite enough to enumerate.
AI agents don't have a finite attack surface. The same tool call that's legitimate in one context is a data exfiltration vector in another. A novel attack technique your denylist hasn't seen passes straight through. And agents can be manipulated into achieving unauthorized outcomes through sequences of individually-permitted actions — none of which trigger a denylist rule on their own.
Denylist
BLOCK KNOWN BAD
Requires knowing every attack vector in advance. Novel techniques pass through. Grows brittle as agent capabilities expand. A determined attacker finds the gaps.
Allowlist
PERMIT KNOWN GOOD
Everything not explicitly permitted is blocked by default. Novel attacks don't need a new rule — they're blocked automatically. The policy surface shrinks as you scope agent permissions tightly.
What this looks like in practice
⊗ DENYLIST APPROACH
BLOCK send_email(to="external*")
BLOCK write_file(path="/etc/*")
BLOCK exec_shell(cmd="rm*")
// Attacker uses:
send_email(to="internal-relay@co.com")
→ Forwards externally. Not on denylist.
✓ ALLOWLIST APPROACH
ALLOW read_file(path="/data/reports/*")
ALLOW send_email(to="@company.com")
ALLOW query_db(table="invoices")
// Everything else:
→ BLOCKED by default. No rule needed.
The tradeoff is real — here's how to handle it
Allowlist enforcement requires more upfront work. You have to define what each agent is actually allowed to do — which tools, which endpoints, which data scopes. Teams deploying agents quickly often skip this because it slows initial rollout.
That's the wrong tradeoff. An agent running under allowlist-only enforcement that gets compromised via prompt injection, a poisoned dependency, or a malicious MCP server cannot take an unpermitted action. The attack may succeed — but the blast radius is scoped to exactly what the policy permits. With a denylist, the blast radius is everything the denylist missed.
THE PRACTICAL STARTING POINT
Start with the narrowest possible allowlist for each agent — only the tools and data it needs for its specific task. Expand permissions deliberately as you validate behavior. It's far easier to add permissions than to recover from an agent operating outside intended scope.
The effort required to define a tight allowlist is also the work of understanding what your agents actually do in production. Teams that skip it usually discover the gaps the hard way.