MCP and OAuth2: Who Authorized the Agent's Action on Your MCP Server?

Why tool access makes identity harder

The Model Context Protocol (MCP) is now a standard piece of plumbing for agentic AI. It gives a model one way to discover and call external tools, resources and services. You don't wire a custom integration between an LLM and every API it touches; the application connects to an MCP server and finds out what that server offers. Searching a database, filing a GitHub issue, querying Salesforce, sending an email or pulling records out of an enterprise system all collapse into the same operation, a tool call.

Once an AI can act and not merely answer, identity and authorization get complicated quickly. Who is the AI, and who is the human behind it? Who authorized the action, and what exactly may the AI do? Which resource was the authorization meant for? Can the AI pass that authority on to another service? And the biggest question: can OAuth2, a protocol built mostly around software reaching protected resources, adequately represent an autonomous agent acting for a person?

The answer is complicated. The phrase "on behalf of" points toward the OAuth2 Token Exchange protocol. The current MCP spec doesn't mention it, though it's easy to see where it could fit, and it wouldn't cure the other shortcomings below.

How MCP works in practice

MCP defines a standard protocol between an AI client and an MCP server. A simplified picture looks like this.

The AI application is the MCP client, and the MCP server exposes capabilities to it. The model can discover those capabilities and decide when to call them. The notable shift is that the LLM is no longer just producing text. It takes part in a protocol.

Imagine an assistant attached to an MCP server for a corporate issue tracker. First the client asks the server which tools it has.

{
  "method": "tools/list",
  "params": {}
}

The server replies with its tool list.

{
  "tools": [
    {
      "name": "search_issues",
      "description": "Search project issues",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string"
          }
        }
      }
    },
    {
      "name": "create_issue",
      "description": "Create a new project issue",
      "inputSchema": {
        "type": "object",
        "properties": {
          "title": {
            "type": "string"
          },
          "description": {
            "type": "string"
          }
        }
      }
    }
  ]
}

Now the model knows two capabilities are on hand. Say the user asks it to find the open authentication bugs and create an issue summarizing the most important one. The agent might begin with a search call.

{
  "method": "tools/call",
  "params": {
    "name": "search_issues",
    "arguments": {
      "query": "authentication bugs status:open"
    }
  }
}

The server returns matching issues.

{
  "content": [
    {
      "type": "text",
      "text": "Found 17 open authentication issues."
    }
  ]
}

The model reads the results, picks the one that matters most and makes a second request.

{
  "method": "tools/call",
  "params": {
    "name": "create_issue",
    "arguments": {
      "title": "Critical authentication issue",
      "description": "Summary of the highest-priority authentication defect..."
    }
  }
}

The server confirms the creation.

{
  "content": [
    {
      "type": "text",
      "text": "Issue AUTH-4821 created successfully."
    }
  ]
}

Here the security problem becomes plain. The agent has moved from reading information to taking an action that's visible outside the system.

MCP doesn't solve identity

A common misconception is that MCP settles identity. It doesn't. MCP defines how clients and servers interact, and authentication and authorization are a separate concern.

For HTTP-based transports, the authorization section of the current specification (the 2026-07-28 revision) builds on OAuth 2.1. The section is titled authorization, probably because that's OAuth2's core focus, though it covers authentication mechanisms too. MCP servers act as OAuth2 protected resources and MCP clients act as OAuth2 clients. The spec also brings in Protected Resource Metadata, Authorization Server Metadata, Resource Indicators and client registration and discovery. It pulls together these specifications:

• the OAuth 2.1 IETF draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Bearer Token Usage (RFC 6750)
• OAuth 2.0 Authorization Server Metadata (RFC 8414)
• OAuth 2.0 Dynamic Client Registration (RFC 7591)
• Resource Indicators for OAuth 2.0 (RFC 8707)
• OAuth 2.0 Protected Resource Metadata (RFC 9728)
• Authorization Server Issuer Identification (RFC 9207)
• OAuth Client ID Metadata Documents (an IETF draft)
• OpenID Connect Discovery 1.0 and OpenID Connect Dynamic Client Registration 1.0

The protocol keeps tightening. In the July 2026 revision, clients must check the iss parameter to block authorization-server mix-up attacks, client credentials are tied to the issuer that created them, and Dynamic Client Registration is giving way to Client ID Metadata Documents. Whether OAuth2 suffices for agents is still an open question.

OAuth predates agents

OAuth 2.0 was standardized in 2012 to answer a fairly simple question: how can a client get limited access to a protected resource without learning the resource owner's password?

The model worked very well and became the base of delegated API access across the internet. Autonomous AI brings a different kind of client, though. An OAuth2 client used to mean an application. An agent can be autonomous, long-running and multi-step, able to pick tools dynamically, call several APIs, delegate work, act for a human and make decisions the human never spelled out. That's a very different authorization problem.

It isn't that OAuth is insecure

Nobody should exaggerate the criticism. RFC 6749 did include security considerations, and OAuth2 has grown a substantial security architecture since. The point is that OAuth2 was deliberately a framework, not a full prescriptive protocol for every modern deployment. Implementers got to make many security choices, and in time the industry learned that some combinations of those choices were dangerous. That's the reason for the additions that followed: client authentication and discovery, protected resource metadata and resource indicators, mutual TLS, DPoP and other sender-constrained tokens, token binding, PKCE and refreshed guidance. The accumulation was big enough that the IETF issued RFC 9700, a Best Current Practice document for OAuth 2.0 security, which builds on RFCs 6749, 6750 and 6819 and deprecates weaker modes of operation.

So OAuth2 didn't fail. It evolved. Yet that evolution is itself a sign of the underlying issue: the original abstraction has repeatedly needed extra mechanisms as security environments grew more complicated.

What does the token represent?

Return to the earlier example. The user asks for an issue to be created, the AI decides to call an MCP tool, and the server receives an OAuth2 access token. What does that token stand for? It could be the human user, the AI application, the MCP client, the MCP server acting for the human, or some mix of application and user. Those aren't equivalent, and under slightly different yet perfectly legitimate OAuth2 flows, any of them can occur.

It matters even more when the MCP server calls another API.

Several authorization domains now overlap. Before acting, the server may have to establish the user's identity, the agent doing the work, the MCP client that kicked off the request, what the user approved, the tools the agent may use, the downstream APIs within reach, and whether this action stays within the original grant. That's a good deal more than the simple shape below.

The confused deputy

Among MCP's most serious security risks is the confused deputy. Suppose the MCP server receives a token meant for itself and then calls a downstream API. A careless implementation might simply forward that token, and that's the behavior current MCP security guidance is written to stop. According to the specification, a server must check that a token was issued to it and must never hand the client's token to another service. When it needs an upstream API, it should obtain a different token issued for that downstream resource. The principle is this:

and not this:

The first model creates separate trust boundaries. Adding an MCP gateway complicates things further, but the rule stays the same: never pass tokens downstream.

Where OAuth2 sits in MCP

At a simplified level, the flow looks like this.

The MCP server is the protected resource. The client obtains an access token, presents it with each MCP operation, and the server validates it. That's conventional OAuth2. The spec reinforces it with Resource Indicators (the resource parameter), so the authorization request names the specific MCP server the token is for. That's a good thing, but it doesn't magically fix every agentic authorization problem.

What OIDC adds

OAuth2 answers what a client is authorized to access. OIDC adds an identity layer that says who the authenticated subject is, which is useful for agents. An identity provider might authenticate a user such as:

Alice

OIDC can supply identity claims about that user, OAuth2 can supply delegated authorization, and the MCP client can then get an access token representing an authorization granted to the client for a specific resource. Conceptually it looks like this.

A conceptual gap remains, though. Authenticating the user doesn't authorize each of the agent's decisions. A user might allow an application to read her email, which isn't the same as letting an AI agent send whatever email it decides to send on its own. That's a policy problem.

The trouble with scopes

Scopes are often presented as the answer. A calendar-read grant looks like this.

scope=calendar.read

and a sending grant like this.

scope=email.send

But agentic systems expose how coarse scopes are. Take a plain email-sending permission.

email.send

Does it let the AI mail anyone? Send unlimited messages? Send financial documents or confidential corporate data? Impersonate the user? Send without asking for confirmation? The scope doesn't say. The real decision may need more context, along these lines.

Subject
Agent
Tool
Action
Resource
Target
Context
Risk
Time
Policy

That looks less like traditional OAuth2 scopes and more like policy-based authorization. In older terms, it's the difference between coarse-grained and fine-grained authorization decisions.

The agent as a new security principal

This may be the most important conceptual change. Traditional applications usually have a fairly stable identity. An AI agent may be assembled dynamically, from several parts at once.

So who is the security principal? Possibly all of them. The authorization system may need to express more than "Alice may access Salesforce." It may need to say that Alice authorized this particular agent, running through this particular application, to perform certain classes of actions against this Salesforce tenant, subject to certain policies. That's a much richer statement.

It's also like any system caching many access tokens from a large pool of users, human and application, to reach many downstream resources. The question is whether the agent can be trusted to protect those tokens and pick the right one when it's time to act for a given user.

Is OAuth2 broken for agents?

That conclusion isn't justified. A better statement is that OAuth2 solves part of the agent authorization problem, and the full problem is bigger than OAuth2. It's very good at delegated access, which it establishes like this.

An agent ecosystem needs more answers than that: which agent, acting for which person, with which tool, for what purpose, on which resource, under what authority and policy, for how long, within what transaction limits and with what human approval. Having an access token doesn't remove any of those questions.

New proposals

Several directions are emerging.

GNAP

The most obvious standards-based candidate is GNAP, the Grant Negotiation and Authorization Protocol. It was built to get past limits in OAuth2-style authorization and delegation, with a way to delegate authorization to software and pass the resulting artifacts to it, covering API access as well as subject information. Its design explored richer delegation than OAuth2 offers. GNAP is now an IETF Proposed Standard as RFC 9635, and RFC 9767 covers resource-server connections. It does answer the question of whether anyone has proposed something beyond OAuth2, yet it's no MCP-specific replacement and OAuth2 remains dominant.

MCP-specific security protocols

Researchers are also proposing protocols built around MCP and agentic AI. Secure Model Context Protocol (SMCP) would extend MCP with unified identity management, mutual authentication, security-context propagation, fine-grained policy enforcement and audit logging. Another proposal, MCPSec, suggests capability attestation and message authentication to counter MCP-specific threats. These efforts recognize that authentication isn't the only issue. An agent ecosystem may have to establish not just who you are but what capabilities you claim and whether those claims can be verified cryptographically. That moves toward capability-based security.

Capability-based authorization

This may prove more important than replacing OAuth. Instead of giving an agent the scope email.send, the system could hand it a narrowly defined capability.

Capability:
    Principal: Agent-472
    Subject: Alice
    Action: send-email
    Resource: alice@example.com
    Destination: bob@example.com
    Maximum: 1 message
    Expiration: 10 minutes

The agent holds a cryptographically verifiable authorization artifact and can't reuse that authority for anything else. That's much closer to what agentic systems need, because the agent isn't just authenticated. It has been given a specific authority.

OAuth2 plus something else

The eventual architecture probably won't declare OAuth2 dead. It will look more like this.

OAuth2 keeps issuing access tokens, OIDC establishes human identity, MCP provides the tool protocol, a capability or policy system limits what the agent may actually do, and a policy enforcement point makes the final call.

The missing piece: intent

Intent is something traditional authorization wasn't designed to handle. Say a user asks an agent to find a Manila flight under $1,000 and book it. Along the way the agent might search airlines, compare fares, read the calendar, open passport details, reserve a seat and pay. The user never approved each of those API requests individually. She approved an intent, which differs sharply from conventional web authorization because the agent converts a broad instruction into a chain of machine actions. The security system may need to reason about the following.

This is why the claim that OAuth2 doesn't work for agents has some truth, as long as the criticism is read correctly. OAuth2 can authorize each call. It doesn't inherently provide a full way to judge whether those calls fit the person's intent and the agent's delegated authority.

MCP as the test case

MCP is forcing the identity and security community to face a problem that's been building for years. OAuth2 was designed around this chain.

Agentic AI brings in something different.

The chain turns dynamic. Participants can change, the agent makes decisions, tools are discovered on the fly, and the downstream service may never have heard of the original user. Yet the system still has to answer who authorized the action, which is a much harder question.

OAuth2 isn't going away

It's tempting to say OAuth2 predates AI and therefore can't work for it. That's too simple. OAuth2 has survived huge changes on the internet because it's a genuinely useful delegation framework, and the MCP specification builds explicitly on OAuth 2.1 and doesn't abandon it. The likelier future is evolutionary:

• OAuth2 as the foundation
• OIDC for identity
• MCP for standard tool interaction
• DPoP and related mechanisms for stronger token binding
• Resource Indicators to tie tokens to their intended resources
• Capability systems to limit what agents may do
• Policy engines to evaluate context
• Newer protocols such as GNAP for richer delegation semantics

The shift in one idea

Agentic AI doesn't chiefly produce a new authentication problem. The new problem is authorization and delegation. Authentication asks who you are, and OAuth2 asks what you may access. Agentic authorization has to ask what authority has been delegated to this agent, on whose behalf, against which resources and under what constraints, and whether this particular action falls inside it. That's a richer question, and it probably calls for a richer security model.

The future is probably not OAuth2 versus something new. More likely it's OAuth2, OIDC, MCP, capabilities, policy, stronger cryptographic binding and agent-aware delegation working together. MCP is simply making the limits of existing identity architecture impossible to ignore, which may end up being among its most important contributions to the AI ecosystem.