MCP Authorization Isn’t Enough For AI Agents

As we delegate more and more tasks to AI agents, we need to ensure that they act with proper permissions. Users and organizations should treat an agent as another type of identity that acts in their systems and limit their capabilities accordingly. 

We're used to limiting permissions to users — we want to ensure that a user with access to a system operates with the minimum privileges required so that they do not abuse that access (either by themselves or when their credentials get stolen). The same principle applies to agents: when you delegate a task to an agent, you should ensure that the agent operates with minimum permissions to perform that task so that it does not misbehave.

Definition

Agentic authorization is the practice of granting AI agents only the minimum, revocable permissions needed to complete a specific task. Ideally, it should be governed by a centralized policy that the user and organization control, not the agent or the server it's calling.

The Model Context Protocol (MCP) specification and user-facing agents (like Claude Code) offer some features that are supposed to address the access problem:

• MCP authorization,

• step-up authorization in MCP

• tool call control in agents

While they offer some level of control, in this post I will explain why they fail to enable fine-grained agentic authorization where the user stays in control of the agent's capabilities. At the end, I explain what we, at Curity, think is the solution.

Why MCP Authorization Isn't Fine-Grained Enough

The MCP authorization part of the specification ensures that only authenticated and authorized agents access an MCP server. The specification uses OAuth to implement this protection, assuming that, at least initially, there is a user who runs the flow and delegates access to their resources through the MCP server. For example, when you connect Claude Code to the GitHub MCP server, you will run an OAuth flow, log in with your GitHub account, and grant the agent access to your resources.

This allows the MCP server to ensure that only authorized agents call its tools. It also allows the MCP server to use the agent's token to call any underlying services (APIs) that process tool calls. The server informs the client what scopes it should use when asking the user for authorization, which limits the capabilities of the agent.

 However, scopes offer only coarse-grained access control, are fairly static (once granted, the access token will have the scope for a longer time), and are at the discretion of the MCP server. This means that the user has limited control over what permissions they will grant to the agent and for how long. A usual MCP authorization flow looks similar to this:

• The user wants to connect an MCP server to their agent.

• The MCP server returns a request for authorization and indicates the scopes the user should grant to the agent.

• The agent initiates an OAuth flow asking the user to grant consent to the scopes. Once the user grants access, the agent gets an access token with the scopes that allows it to call any tools that require the given scope.

The user is not able to control which tools the agent can access, with what parameters, or for how long. It's also usually at the agent's discretion to ask only for the necessary scopes; however, it might be tricky for the agent to know upfront which minimum set of scopes is necessary. Again, the user has no control over this behavior.

Why Step-Up Authorization Still Leaves the MCP Server in Control

The MCP server can request step-up authorization in two ways: through a direct 403 MCP response or with URL elicitation. In the former case, the MCP server returns an `insufficient_scope` error response directly to the client, which triggers another authorization flow. When using elicitation, the MCP server returns a URL to which the client should redirect the user. The URL can direct the user to a page where they can provide consent to the high-privilege operation or enter some additional credentials required by the tool.

Both approaches lead to the same result — to allow the agent to perform a sensitive operation. However, there is one notable difference. With the direct approach, the agent receives the high-privilege token and then retries the operation. 

With the elicitation approach, the user performs the approval outside of the client, then asks the agent to retry the operation. It allows the agent to eventually fulfil the given task, but it does not handle any high-privilege tokens or credentials that were needed for that. With the direct approach, as the agent takes control of the high-privilege token, there is a risk that the agent will misuse it.

Step-up authorization enables the MCP server to implement greater control over agents' behavior. Yet again, the control stays in the MCP server's discretion. When connecting to third-party MCP servers, users and organizations cannot decide which tools they deem high-risk, nor can they apply fine-grained policies to tool calls. A tool's sensitivity can differ based on the parameters used to call it.

Why Tool Call Control Doesn't Solve the Issue

Agents that act as MCP clients usually implement some kind of tool call control in their harness. The agent informs the user that it plans to call a tool on a specific server with concrete parameters. The user has an option to accept or reject the action. Very often, the agent will also give the user an option to allow all future calls of the given tool.

This gives the user control over the agent's behavior. However, the feature has some limitations:

• It requires the agent to have an interface to the user — either direct (front channel) or indirect (back channel). The agent needs a way to collect the user's consent.

• Giving consent for future tool calls is not fine-grained. Usually, this means consenting to using the given tool, regardless of the parameters or context.

• The feature might be affected by the agent's non-deterministic behavior. For example, when the agent wants to get the user's consent for future tool calls, sometimes it will ask to consent to calling the tool with concrete parameters, and sometimes to consent to just the tool being called, even when the same prompt triggers the question.

• A tool call can be fairly technical. It might be hard for the user to understand what the agent is trying to achieve given just the tool name and parameters.

• Agents solve more and more complex issues, which usually means calling a number of tools to reach the goal. This can quickly lead to consent fatigue, where the user automatically approves tool calls without actually verifying what the agent is trying to do.

• Even if the user gets fairly fine-grained options to control the agent's behavior, the control is local and is not governed by a standard policy. This means that organizations cannot control the policy centrally, and the user cannot port the policies to other agents.

How the Approaches Compare

While the different approaches offer some control over the agent's behavior, neither of them provides fine-grained, contextual authorization that users and organizations can control centrally.

Token Vaulting: Centralized, Fine-Grained Agentic Authorization

Securing access to third-party MCP servers with OAuth access tokens gives a robust foundation on which you can build a fully-featured authorization solution. At Curity, we think that users and organizations can solve agentic authorization by implementing token intelligence patterns like the token vaulting approach.

In the token vaulting pattern, high-privilege access tokens are kept away from the agent by default. When the agent wants to call MCP servers, it performs a token exchange so that the MCP server eventually receives the vaulted token. During the exchange, the vault consults a policy using context information to make an informed authorization decision on whether the agent should perform the given action.

Such a solution leverages existing standards to hand back control over the agent’s behavior to users and organizations. It allows them to apply centralized, fine-grained policies, where the vault component makes authorization decisions based not only on static permissions but also on dynamic, context-aware attributes. For example, a policy can allow the agent to call a mail-sending tool only if it tries to send e-mails to pre-approved recipients.

Organizations can control agent behavior regardless of whether the agent has a user interface and do not rely on controls applied either by the agent or the MCP server. At Curity, we strongly believe such an approach is necessary to keep agents from misbehaving.