by AgentGuard (LX AI)
A tool allowlist is an explicit list of the functions an agent may call; everything not on the list is denied by default. It is the cheapest control that meaningfully limits blast radius, because it removes whole classes of failure instead of filtering each one.
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.
I follow a repeatable checklist that keeps the list tight and reviewable.
This process takes me about an hour for a simple agent and produces a document that anyone can audit.
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.
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.
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.
Understanding these boundaries helps you allocate effort where it adds real security value.
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.
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.
No. Prompt-level restrictions can be talked around. Enforce the allowlist at the tool registry or the execution layer.
Sending email or messages, moving money, deleting records, publishing content — anything you cannot take back.
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.
No. Filters catch bad content; allowlists remove unnecessary capability. Use both.
It limits the damage one can do. Detecting and blocking the injection itself is a separate input-side control.
No. It is decision-support that rates calls and suggests filters. A full assessment of the deployment still needs a security review.
Try the product: AgentGuard
A blocklist has to anticipate every dangerous call. An allowlist only has to enumerate the calls the agent legitimately needs — a much smaller, reviewable list. When the agent is prompted into something outside it, the call is refused simply because it was never granted.
AgentGuard reviews the agent's prompt and tool list, rates the risk of each tool call and suggests input/output filters — which makes the classification step above a repeatable review rather than a one-off judgement call. It also returns an EU AI Act mapping for the governance owner.
AgentGuard reviews the agent's prompt and tool list, rates the risk of each tool call and suggests input/output filters — which makes the classification step above a repeatable review rather than a one-off judgement call. It also returns an EU AI Act mapping for the governance owner.
No. Prompt-level restrictions can be talked around. Enforce the allowlist at the tool registry or the execution layer.