AI Agent Tool Allow-List: Enforce at Call Time

OWASP, the MCP specification and two 2025 advisories on MCP reference servers all say the same thing about tools: the list is a menu, and the control has to run when the call arrives.

By Harinderpal Hanspal on October 2026

A tool list tells the model what it may ask for. It does not decide what runs. OWASP's excessive-agency guidance asks for authorization in the downstream system, and the MCP specification tells clients to treat tool annotations as untrusted.

Hiding a tool from the list does not stop a call that names it; a call-time check doesSketch of an agent with a short tool list showing two read tools. A call naming a third tool, write, arrives anyway and meets a check at call time marked refuse, drawn with a red cross before the tool. A note says the list is a menu and the check is the control.agentlist shows: read, readcall names: writecheck at call timerefusewrite toolthe list is a menu,the check is the controloutside servers add entries to the menu
Hiding a tool from the list does not stop a call that names it; a call-time check does

OWASP's list of risks for language-model applications puts excessive agency at LLM06 and names three causes. The first is excessive functionality: its example is a developer who wants an agent to read documents from a repository, and picks a third-party extension that can also modify and delete them. The second is excessive permissions, such as a read-only tool that connects to a database with an identity that can also update and delete. The third is excessive autonomy (OWASP LLM06:2025).

The first two are about what the tool list contains and what sits behind each entry. Neither is about the model.

Two advisories where the scope check failed

Both come from the project's collection of reference servers for the Model Context Protocol (MCP).

In December 2025 the record for CVE-2025-68143 described a Git server whose git_init tool accepted arbitrary filesystem paths without validating the target. The fix, in version 2025.9.25, removed the tool entirely (NVD).

In July 2025 the record for CVE-2025-53109 said the Filesystem server could allow access to unintended files through symlinks inside allowed directories, fixed in 2025.7.01 (NVD).

In each, a tool was meant to stay inside a boundary, and a request could reach beyond it. In the first case the fix was to delete the tool. A list of allowed things is only as good as the check that runs when something is requested.

The list is a menu, the call is the order

Picture an agent that drafts maintenance summaries from a plant historian. Its tool list shows two read tools. Removing the write tool from that list changes what the model is likely to propose. It does not change what the executor does if a call naming the write tool arrives anyway, from a mistaken model or from text the agent read in a document. In the MCP specification, tools are "model-controlled", and the same page tells servers to implement access controls and clients to log tool use (MCP specification, 2025-11-25). Enforcement belongs where the call lands, which is what OWASP calls complete mediation: authorization checked in the downstream system, not left to the model.

That points to three practices:

Tools from outside servers

A tool from an external server arrives with its own name, description and schema, and the model sees all of them. OWASP's MCP cheat sheet lists what follows: descriptions that carry instructions, a server that changes its tool definitions after approval, and one server's descriptions steering how the agent uses another's. Its advice is to treat each server as its own untrusted security domain and to pin reviewed definitions by hash. It adds that this detects changes to the metadata, not to behavior behind an unchanged definition (OWASP MCP Security Cheat Sheet).

The MCP specification itself says clients must treat tool annotations, the properties a tool declares about its own behavior, as untrusted "unless they come from trusted servers". A policy that sorts tools into safe and unsafe by what each one says about itself has handed the decision to the tool.

For plants, CISA and eight partner agencies advise brokered or push-based designs that move data out of operational technology without giving the AI persistent inbound access (CISA joint guidance, 3 December 2025). That is guidance, not regulation, and it does not use the words "tool list". It answers the same question: what can the agent reach, and who decides.

Questions to put to a vendor about the tool list

  1. When a call names a tool that is not on the agent's list, what happens, and is that logged?
  2. Is the allow-list set per agent or per deployment?
  3. Are tools from external servers reviewed before use, pinned, and re-reviewed when the server changes its definitions?
  4. Does the policy rely on what a tool says about itself, such as a read-only label?
  5. What credential sits behind each tool, and can it do more than the tool's name suggests?
  6. Can equipment-facing tools be kept off any external server connection?

A vendor who answers the first question with "the agent never sees that tool" has described the menu.

Drawn from OWASP LLM06:2025 and the OWASP MCP Security Cheat Sheet, the Model Context Protocol specification (revision 2025-11-25), NVD records for CVE-2025-68143 and CVE-2025-53109, and joint CISA guidance on AI in operational technology (3 December 2025), all read on 6 October 2026. The reasoning about call-time checks is ours.

Related notes

Related paper: Governing agents in production: what to ask before an agent acts