Deny by Default

A finance agent may only need to post journal entries.

It calls execute_journal with an account code, an amount, and a description. It may do this correctly hundreds of times a day.

But if the connected MCP server also exposes delete_account, run_shell, or export_all_customers, the agent may be able to call those tools too.

Nobody intended that outcome. The extra capability exists simply because the server exposed it and nothing prevented the agent from reaching it.

That is not least privilege. It is broad access by default.

How Agents Accumulate Privilege

An MCP server exposes a catalogue of tools. The agent calls tools/list, receives the available operations, and selects the one it needs.

In a basic implementation, that exchange does not establish which tools the agent is authorised to use. The server presents what it supports and relies on the caller to behave as expected.

That may be acceptable for a local development tool or a personal assistant operating in a low-risk environment.

It is much harder to justify when the agent is connected to systems containing cardholder data, customer records, financial transactions, or other regulated information.

Human access in these environments is usually controlled more carefully. Users are assigned permissions based on their role, access is limited to what they need, and entitlements are reviewed over time.

AI agents should be treated in the same way. An agent that posts journal entries should not automatically inherit access to every administrative or destructive operation exposed by the same server.

Least Privilege Still Applies

PCI DSS Requirement 7 states that access to system components and cardholder data should be restricted to individuals whose job requires it.

AI agents are not individuals, and organisations should take advice on how specific regulatory requirements apply to their own implementation. Even so, the underlying control principle is directly relevant: access should be limited to what is necessary for the task.

ISO 27001 access-control guidance is based on the same idea. Permissions should reflect a defined business need rather than technical availability.

This is not a new security concept. Least privilege has been part of access-control design for decades.

What is new is the execution model. Agents interact with systems through tool calls, so the control must operate at that layer. It is not enough to secure the model, authenticate the connection, or trust the prompt. The system must decide whether a particular agent is allowed to call a particular tool.

Privilege Expands as the Backend Changes

The risk increases as MCP servers evolve.

Backend teams add tools as new features are released. A server that exposed ten operations last month may expose fifteen today.

Without explicit tool-level controls, each new operation may become available to every connected agent as soon as it appears. No access review is triggered. No policy is updated. The agent's effective privilege grows with the server.

Consider a finance server that initially exposes:

• execute_journal
• get_account_balance
• list_periods

A later release adds:

• close_financial_period
• export_ledger
• delete_account

The finance agent may still need only the original two or three tools. However, unless access is restricted explicitly, the new operations can become part of its reachable surface.

An allow list changes that behaviour. New tools remain unavailable until someone deliberately adds them to policy.

This makes backend change safer. The server can evolve without silently increasing the authority of every agent connected to it.

What Deny by Default Looks Like

I built a strict allow-listing mode into the MCP Audit and Compliance Gateway.

For a route, the policy can be configured with:

UnlistedTools: Deny

Once enabled, any tool not named explicitly in policy is rejected.

A finance agent might be allowed to call:

• execute_journal
• get_account_balance

Everything else returns a structured denial using:

DenyReason.UnlistedTool

This creates a clear boundary. The agent can perform the work it was designed for, but it cannot use unrelated tools merely because the backend exposes them.

Identity rules can narrow access further.

For example:

• finance-agent-* can call execute_journal
• research-agent-* can call search_documents
• Neither group inherits access to the other's tools

The server may expose all of these operations through the same connection, but policy determines which identities can use them.

When the backend team adds a new tool, nothing changes for existing agents. The tool remains unavailable until it is reviewed and added to the relevant policy.

The exposed catalogue grows. The agent's approved capability does not.

Discovery and Execution Are Different Decisions

There is also an important distinction between seeing that a tool exists and being permitted to call it.

Some architectures may choose to filter the tool catalogue so an agent only discovers approved tools. Others may allow discovery but enforce authorisation when the call is made.

Both approaches can reduce risk, but execution-time enforcement is essential. Tool descriptions, prompts, and model behaviour are not security boundaries. The gateway must reject unauthorised calls even if the agent attempts them directly.

A useful control therefore answers two separate questions:

1. Should this agent know that the tool exists?
2. Is this agent authorised to execute it?

The second decision must not depend on the agent choosing to comply.

Measure the Excess Privilege Surface

There is a simple way to assess the problem.

For each MCP server:

1. Count the tools it exposes.
2. Count the tools each connected agent genuinely needs.
3. Review the difference.

That gap is the agent's excess privilege surface.

A server might expose 40 tools while a particular agent needs only four. In that case, the concern is not whether the agent usually calls the correct four. The concern is that 36 unnecessary operations may still be reachable.

For human users, most organisations would address that through role-based access, least-privilege design, and periodic entitlement reviews.

AI agents need the same discipline, applied to tool calls.

Make Availability Explicit

Deny by default does not mean blocking useful automation. It means making access deliberate.

An agent should be able to perform its assigned function reliably, without inheriting every capability of the systems around it.

The practical question is simple: if one of your MCP servers added a destructive tool tomorrow, which agents would be able to call it without any policy change?

Learn more about the MCP Audit and Compliance Gateway