Allowlists vs. Denylists: Writing Agent Action Policies That Hold Up in Production

An LLM asked to "figure it out" will figure it out — including tool combinations you never anticipated. Action policies are the boundary between a helpful agent and an incident.

Allowlist the routine, denylist the catastrophic

The two lists serve different purposes and you need both:

• Allowlist: the action verbs the agent may call without asking. Keep it short. If the agent's job is answering support tickets, the allowlist is search_knowledge_base, read_ticket, draft_reply — not send_reply. Sending is the boundary.
• Denylist: verbs that are never allowed, no matter what. delete_user, drop_database, wire_transfer, exfiltrate. The denylist is evaluated first and wins every conflict.

Anything on neither list falls through to risk-tier routing: automatic for reads, human approval for writes. This default-deny middle is the actual policy — the lists are just its edges.

Match on verbs, not on arguments (at first)

Beginners write argument-level policies: "allow send_email only to @ourcompany.com." That precision is valuable, but start with verb-level policies and add argument matching only where the blast radius justifies the complexity. A verb policy is enforceable in one line at the proxy; argument matching needs a schema for every tool and breaks the moment a tool renames a parameter.

Order of evaluation matters

A sane evaluation order, from most to least specific:

1. Agent disabled or killed → deny.
2. Denylist match → deny.
3. Allowlist match → allow (still subject to spend caps).
4. Spend cap would be breached → deny.
5. High-risk verb or tier → require approval.
6. Default → allow.

Write it down in this order, test it in this order, and simulate changes against recorded traffic before deploying them. A policy you can't dry-run is a policy you'll break in production.

Simulate before you ship

The most underused technique in agent governance: replay the last few hundred real authorization decisions against a proposed policy change and count what would have changed. If the new denylist would have denied 40% of last week's traffic, the policy is wrong — or the agent's behavior needs a conversation first. Policy simulation turns governance from guesswork into engineering.

Review on a cadence

Agents drift: tools get added, jobs expand. Put the policy on a quarterly review with the agent owner: read the deny log, read the approval log, and ask whether each rule still earns its place. Policies that never change are policies nobody is watching.