MCP Tool Exposure is a Privilege Grant: A Two-Gate Authorization Model for Agentic AI

Model Context Protocol is quickly becoming a common way for AI agents to connect to the systems around them. Through MCP, an agent can search a repository, query a database, create a ticket, send a message, update a record, invoke an API, or trigger a workflow.

That makes interoperability much easier. It also changes the security significance of something that can look fairly harmless: the tool catalog.

Consider an agent that can see four tools:

searchDocuments()

sendEmail()

createUser()

deleteEnvironment()

These are not equivalent pieces of application functionality. They represent very different levels of authority.

Once a tool is exposed to an agent, we have given the model the ability to consider that capability as part of its plan. That is not the same as granting backend authorization, but it does expand the agent's operational privilege surface.

This is where I think MCP security needs to keep two decisions clearly separated.

Gate 1: Capability Admission. Should this capability be available to this agent in the first place?

Gate 2: Execution Authorization. Given the current identity and context, should this particular use of the capability be allowed against this particular resource?

Authentication to the MCP server is a prerequisite. These two gates come after identity has been established.

The distinction matters because discovering a capability and being authorized to exercise it are not the same thing.

 

Gate 1: Control What Enters the Agent's Capability Surface

We already apply least privilege to users, service accounts, applications, and workloads. The same principle needs to start one step earlier for agents, with the capabilities placed in front of the model.

OWASP's work on excessive agency makes this point from another direction: risk grows when an AI system is given more functionality, permission, or autonomy than it needs.

The shape of the tool itself matters.

Compare:

executeCommand(command)

with:

restartApprovedService(serviceId)

Both could ultimately restart a service, but they create very different security boundaries. In the first case, the model controls a generic execution primitive. In the second, sensitive execution logic remains inside deterministic application code.

The same principle applies to writeFile(path, content) versus writeGeneratedReport(reportId, content), or a generic sendEmail() capability versus a constrained function for sending an approved workflow notification.

This suggests an extension to least privilege that is particularly relevant to agents:

Apply least capability before relying on least privilege.

Do not give a probabilistic decision-maker a general-purpose function when a narrower capability can satisfy the task.

This is not only about malicious agents. An agent may choose the wrong tool because of prompt injection, poisoned content, ambiguous instructions, bad context, or ordinary model error. Reducing the available capability surface limits what any of those failures can turn into.

 

tools/list Is Useful, but It Is Not an Authorization Boundary

MCP's tool discovery model gives us an opportunity to reduce that surface.

If a research agent has no legitimate reason to administer cloud infrastructure, there is little value in showing it deleteCluster. A customer-support agent should not discover payroll administration tools simply because the same MCP environment happens to expose them.

Filtering or constructing the tool list according to the agent's purpose can reduce accidental selection and shrink the capability surface available to an attacker who succeeds in manipulating the model.

But this control has an important limit.

A tool that is absent from tools/list must not become executable simply because a caller constructs a direct request for it.

Discovery filtering is risk reduction. It is not authorization.

That is why a second gate is necessary.

 

Gate 2: Treat the Tool Call as a Request, Not a Command

When the model chooses a tool, what it has really done is express intent.

"I want to invoke this capability."

The security architecture should not translate that automatically into:

"Execute it."

For consequential operations, a trusted enforcement point outside the model should decide whether the request is authorized.

This is consistent with the direction CSA has been taking in its work on the Agentic AI Runtime Security Model and its research on agentic tool misuse: once AI systems can act, security has to move closer to the action itself.

The authorization decision also needs more information than "Does the caller have a valid access token?"

For an agentic transaction, we may need to know who initiated the activity, which application is involved, which agent selected the action, which workload is executing it, how authority reached that agent, which tool is being requested, what operation it will perform, which resource it will affect, and what the current risk or transaction context looks like.

The useful question is no longer simply:

Can this agent call this tool?

It becomes:

Can this agent, acting under this authority, use this tool to perform this action against this resource now?

That is a much stronger authorization boundary.

 

MCP Server Access Should Not Collapse Into Tool Access

Imagine an MCP server that exposes:

getDeploymentStatus

restartDeployment

rotateCredential

modifyFirewall

deleteDeployment

An agent might have a perfectly legitimate reason to call getDeploymentStatus.

That does not mean successful authentication to the MCP server should grant equivalent authority over every other tool.

There are separate decisions hiding behind that connection.

Can the client reach the MCP server?

Which capabilities should the agent discover?

Which capabilities may it invoke?

And if an invocation is allowed, which target resources may it affect?

OAuth is an important part of this architecture. Scopes, resource indicators, token exchange, and sender-constrained credentials can all help establish and protect an authorization envelope.

But an OAuth scope does not necessarily express the complete transaction.

A scope such as payments.write may tell us something important about the kind of access being requested. It does not, by itself, answer which payment, from which account, for what amount, under whose delegated authority, or whether the current circumstances make the transaction acceptable.

The closer an agent gets to a consequential action, the closer authorization needs to get to the actual resource and transaction.

 

Keep the Final Security Decision Outside the Model

There is another reason the second gate matters.

The model cannot be the component responsible for deciding whether its own requested action is authorized.

A system prompt that says, "Never call this tool unless the user is authorized," may be useful behavioral guidance. It is not an access-control mechanism.

Agentic systems consume untrusted inputs. They retrieve external data. They reason over changing context. Their plans can be influenced by prompt injection, tool output, memory, or other agents.

Security architecture should therefore assume that an agent will eventually request an action that should not be allowed.

The objective is not to make unauthorized intent impossible.

The objective is to stop unauthorized intent from becoming execution.

Put differently:

The model can propose the action. A deterministic security control should decide whether that action is allowed to run.

That control might be implemented directly in the application, at the MCP server, through an authorization service, or through an externalized Policy Enforcement Point and Policy Decision Point model such as the one standardized by OpenID AuthZEN.

The implementation can vary. The separation of responsibility should not.

 

Do Not Stop at the Tool Name

Even authorizing the tool may still be too coarse.

Suppose an agent may invoke updateCustomerRecord.

Which customer's record?

If the tool is deployApplication, does the authorization cover development, production, or both?

If the tool is transferFunds, which account and what transaction limit?

The target resource is part of the authorization decision.

This is particularly important when an MCP server itself holds credentials to downstream systems. A tool invocation can appear perfectly authenticated while still causing the server to exercise authority the caller should never have been able to trigger.

The tool name tells us what capability is being requested.

The resource tells us where the consequence lands.

Security needs both.

 

Five Rules I Would Apply to MCP Tool Authorization

Organizations adopting MCP do not need a new identity protocol to start applying this model. They can begin with five rules:

• Treat adding a tool as a privilege change. A new agent-callable tool changes what the autonomous system can potentially do, especially when the tool can write, delete, execute, administer, communicate externally, or initiate transactions.
• Prefer narrow capabilities over generic primitives. Keep security-sensitive choices in trusted code wherever possible instead of exposing them as model-controlled parameters.
• Reduce unnecessary discovery, but never depend on it. Use tools/list to minimize capability exposure while still enforcing authorization independently at invocation time.
• Authorize the action against the target resource. "Agent A can use Tool B" is often too broad. The decision should include what the tool is trying to do and what it is trying to affect.
• Keep enforcement outside the reasoning layer. The agent can decide what action it wants to request. A trusted security component decides whether it is permitted.

 

From Tool Governance to Action Governance

MCP is helping AI systems make the transition from generating information to taking action.

That changes what security teams need to govern.

When an agent can send a message, modify infrastructure, change a customer record, deploy code, or initiate a transaction, the tools placed in front of that agent are part of the privilege model.

Controlling which capabilities become available is the first gate.

Controlling whether a requested capability may actually be exercised against a particular resource is the second.

The distinction can be summarized simply:

tools/list describes the capabilities an agent may be able to discover. tools/call expresses an action the agent wants to take. Neither, on its own, proves that the action is authorized.

As agentic systems become more capable, identity security cannot stop at authenticating the actor or issuing a token.

It also has to govern what capabilities enter the agent's reach and what happens when the agent decides to use them.

An MCP tool is part of that privilege surface.

We should treat it like one.