AI agent tool allowlists: why deny-by-default wins

Why deny-by-default works better than trying to block every bad call

When you start with a deny‑by‑default stance you only have to think about what the agent truly needs. Every other call is stopped automatically, without having to predict every possible misuse. This reduces the mental load on the reviewer and cuts the chance that a forgotten dangerous slip will slip through.

Consider an agent that writes reports. It needs to read a template file, pull data from a database, and send the finished PDF to an internal mailbox. If you list only those three calls, any attempt to run a shell command, query an external API, or delete a table is denied instantly. You never have to write a rule that says “block rm -rf”, “block curl to evil.com”, or “block DROP TABLE”. The deny‑by‑default rule covers them all.

In practice I have seen teams spend weeks building long blocklists that still miss a new attack vector, while a short allowlist of five items stopped the same attacks on day one. The effort saved on maintenance is real: you review the allowlist when a tool changes, not when a new threat appears.

How I build an allowlist for a new agent

I follow a repeatable checklist that keeps the list tight and reviewable.

- Write down the exact tasks the agent must perform today. Ignore “might be useful later” ideas. - For each task, find the single tool that does the job with the narrowest possible parameters. If a tool offers a flag that widens scope, do not enable it unless the task explicitly needs it. - Record the tool name, the exact command or API endpoint, and the allowed parameter values in a simple YAML file. This file lives next to the agent code so reviewers can see it at a glance. - Run the agent in a sandbox and verify that every listed call succeeds and that any call not in the file returns an error. - Ask a peer to review the list. The reviewer’s job is to confirm that each entry maps to a real task and that no extra capability is hidden behind defaults. - Store the file in version control. Tag each commit with the agent version so you can trace which allowlist shipped with which release. - Set up a CI step that fails the build if the YAML file is missing or if it contains a tool not approved in the project’s tool registry.

This process takes me about an hour for a simple agent and produces a document that anyone can audit.

Classifying tools by what they can change

Not all tools carry the same risk. I split allowed tools into three impact classes so I know where to add extra checks.

Impact class | What it means | Example tool | Typical safeguard Read only | Can fetch data but cannot alter state | File read, database SELECT, public API GET | Log the call, no extra approval needed Write or mutable | Can create, update, or delete data | File write, database INSERT/UPDATE/DELETE, internal message publish | Require a second‑approver for first use, log with user ID Irreversible external effect | Can affect systems outside the trust boundary | Send email, post to social media, initiate payment, call external webhook | Mandatory manual approval, detailed audit trail, timeout on the call

When I review a new tool I ask: “If this call runs, what is the worst thing that could happen?” The answer tells me which row of the table applies. For read‑only tools I add only a log line. For write tools I add a lightweight approval workflow. For irreversible effects I enforce a manual gate and keep the call window short.

Pairing allowlists with input and output filters

An allowlist removes unnecessary capability. Filters catch bad data that slips through the allowed calls. I treat them as complementary layers, not replacements.

On the input side I run a prompt‑injection checker that looks for known jailbreak patterns. I use the OWASP LLM Prompt Injection Prevention Cheat Sheet (link) as a reference for the rules I enable. If the checker flags a prompt I either reject it or sanitize the offending segment before the agent sees it.

On the output side I scan the agent’s generated text for secrets, SQL injection attempts, or disallowed URLs. The Secrets Management Cheat Sheet (link) helps me build regex patterns for API keys, passwords, and tokens. The SQL Injection Prevention Cheat Sheet (link) guides the patterns I use to catch dangerous query strings that might be echoed back in a response.

Both filter sets run as lightweight middleware. They add a few milliseconds of latency but stop many low‑effort attacks before they reach the tool layer. Because the allowlist already removed whole classes of calls, the filters have a smaller surface to inspect, which keeps false positives low.

What this is NOT

I want to be clear about the limits of an allowlist so you do not expect it to solve problems it was never meant to address.

- It is not a guarantee that the agent will never behave badly. A determined attacker who finds a way to invoke an allowed tool with malicious parameters can still cause harm. - It does not replace secure coding practices. If the agent’s own code contains a vulnerability, the allowlist cannot stop exploitation of that flaw. - It is not a substitute for proper secrets management. Even if the agent cannot call a secret‑exfiltration tool, secrets leaked in logs or output still pose a risk. - It does not stop indirect prompt injection that manipulates the agent into using an allowed tool in an unexpected way. You still need input validation and output filtering. - It is not a one‑time task. Whenever a tool is added, its parameters change, or the agent’s purpose shifts, you must revisit the list. - It is not a silver bullet for compliance. Regulations such as the EU AI Act require documentation, risk assessments, and human oversight that go beyond a simple allowlist.

Understanding these boundaries helps you allocate effort where it adds real security value.

Common pitfalls I have seen and how I avoid them

Even with a clear process teams sometimes drift into habits that weaken the allowlist. Below are the patterns I watch for and the concrete steps I take to keep the list honest.

- Over‑broad parameters – Someone adds a tool with a flag like “--recursive” or “--all” because it seems convenient. I counter this by asking: “What is the smallest set of options that satisfies the task?” If the answer is a subset, I lock the flag to that subset in the YAML. - Forgotten tool updates** – A library updates and adds a new command that is automatically exposed. I mitigate this by pinning the exact version of the tool in the agent’s dependency file and adding a CI step that fails if a new version introduces undocumented commands. - Mixing policy with prompt** – A developer tries to enforce limits by adding instructions like “do not call delete” inside the prompt. I remind the team that prompt‑level controls can be bypassed through clever rephrasing; the real guard must sit at the tool registry or execution layer. - Missing logging** – The allowlist blocks a call but no one knows it happened. I ensure every blocked attempt writes a structured log entry with timestamp, agent ID, and the rejected tool name. This log feeds into our alerting system so we can spot probing attempts. - Assuming the list is short enough to skip review** – Even a list of five items can hide a risky tool if the reviewer does not understand its impact. I make the review a required step in the pull‑request template and ask the reviewer to answer: “Which task needs this tool and what is the worst effect if it runs?” - Using the same list for multiple agents** – Different agents have different tasks, yet teams sometimes copy a generic list. I enforce that each agent gets its own YAML file, stored in a folder named after the agent, so the scope stays clear.

By treating each of these items as a concrete check in my workflow I keep the allowlist tight and the agent’s blast radius small.

References

- OWASP LLM Prompt Injection Prevention Cheat Sheet - OWASP SQL Injection Prevention Cheat Sheet - OWASP Secrets Management Cheat Sheet - Agent Squads – Config Files Guide

Frequently asked questions

Is a prompt instruction enough to restrict tools?

No. Prompt-level restrictions can be talked around. Enforce the allowlist at the tool registry or the execution layer.

What counts as an irreversible external effect?

Sending email or messages, moving money, deleting records, publishing content — anything you cannot take back.

How many tools is too many?

There is no number. The test is whether you can explain, for each tool on the list, which task requires it and what it can destroy.

Do filters replace an allowlist?

No. Filters catch bad content; allowlists remove unnecessary capability. Use both.

Does this cover indirect prompt injection?

It limits the damage one can do. Detecting and blocking the injection itself is a separate input-side control.

Is the review a security audit?

No. It is decision-support that rates calls and suggests filters. A full assessment of the deployment still needs a security review.

References

- OWASP — Top 10 for Large Language Model Applications - NIST — AI Risk Management Framework

Try the product: AgentGuard

2026-09-20 · primary sources only · no fabricated traffic metrics · decision-support only

Related articles

- Agent guardrails mapped to the NIST AI RMF - Explore the full AI micro-SaaS topic matrix →