MCP authentication shows where AI agent identity breaks down

At a glance

What this is: This article explains how MCP authentication and authorisation work and finds that standardising OAuth 2.1 still leaves material implementation burden for AI-native tool access.

Why it matters: IAM and security teams need to understand where MCP shifts control into server-side identity infrastructure, because model-driven access changes how delegation, token handling, and governance have to be enforced.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.

Context

Model Context Protocol, or MCP, is a standard interface for letting LLM-driven tools call external services with scoped identity and context. The security problem is not whether the protocol can authenticate a client, but whether the surrounding governance model can keep up when model-driven action, delegated authorisation, and token handling all move into the same control plane.

In practice, MCP pushes identity teams into a new operating pattern: the server may need to authenticate clients, validate user context, and mediate tool use across local and remote environments. That matters for NHI governance because the hard part is no longer just granting access, but deciding who owns token lifecycle, revocation, and trust boundaries when an AI workflow initiates the action.

The article treats OAuth 2.1, PKCE, metadata discovery, and dynamic client registration as the main building blocks, but the underlying issue is implementation burden. Once an MCP server starts issuing or managing tokens, it inherits responsibilities that look less like simple application auth and more like identity infrastructure.

Key questions

Q: What breaks when MCP servers are not governed like integrations?

A: What breaks is the trust boundary. If an MCP server can connect an agent to tools or data without clear ownership, logging, and access limits, the server becomes part of the effective attack path. That creates hidden delegation and makes it harder to prove which actions were authorised.

Q: Why do MCP workflows increase authorisation risk for AI tools?

A: Because the model can initiate actions across tools and services without the stable human request pattern that many identity controls assume. That makes scope management and session trust more important than the login event itself. If the server over-trusts the client or reuses broad tokens, the model can overreach within an otherwise legitimate workflow.

Q: How can teams tell whether their MCP implementation is becoming an identity system?

A: Look for server-side token storage, refresh handling, registration logic, audit logging, and policy decisions that sit between the user, the model, and the target service. Those are signs that the MCP layer is functioning as identity infrastructure. When that happens, IAM and security governance need to own it as such.

Q: What should teams do when an MCP server must rely on a third-party identity provider?

A: Define the server’s role in the delegation chain before deployment. If the server still issues its own access token after upstream validation, that intermediate step needs logging, scope controls, and revocation handling. Teams should not assume the external provider removes the server’s governance burden, because the MCP server still remains an identity boundary.

Technical breakdown

How MCP separates host, client, and server identity

MCP uses three distinct roles: the host, which is the AI application; the client, which is the runtime bridge; and the server, where tools and side effects live. The client is important because it manages authentication, authorisation, and context transfer between the host and the server. That separation lets the model invoke tools without directly embedding server logic, but it also means identity decisions are distributed across components rather than centralized in a single login flow. In practice, this makes the server the enforcement point for access scope, context validation, and session trust.

Practical implication: map each MCP component to a clear identity owner and audit who controls token issuance, validation, and revocation.

Why OAuth 2.1 and PKCE matter in MCP

MCP’s adoption of OAuth 2.1 matters because it brings a familiar delegation model into AI-native workflows. PKCE protects public clients against code interception, while metadata discovery removes the need to hardcode auth endpoints and scopes. Dynamic client registration reduces setup friction by allowing a client to register on the fly. Together, these features make the protocol easier to integrate with existing enterprise identity systems, but they do not remove the need for careful token handling or server-side enforcement. The design improves consistency, not automatic governance.

Practical implication: treat OAuth 2.1 support as a baseline and validate how the MCP server stores, scopes, and refreshes tokens.

Why MCP servers become identity infrastructure

The article’s hardest point is that an MCP server may need to behave like a mini authorisation server, not just a tool host. If it receives an upstream token, it may still need to validate that token or issue its own session-bound token. That creates storage, logging, compliance, and lifecycle obligations that are easy to underestimate. This is where the protocol’s promise and operational reality diverge: the more the server mediates trust, the more it resembles a core identity service with all the associated control requirements.

Practical implication: review MCP servers as critical identity components, not lightweight integrations, before exposing high-impact actions.

Threat narrative

Attacker objective: The objective is to abuse a trusted MCP workflow to obtain authorisation for actions or data access that should have remained constrained.

1. Entry begins when a client registers or authenticates through MCP using OAuth 2.1, API keys, or another supported pattern.
2. Credential access and authorisation occur when the server receives tokens, scopes them, and decides whether the requested tool action is permitted.
3. Impact follows if token handling, delegation, or server-side trust is too broad, allowing high-impact actions or data access through an approved model workflow.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Protocol standardisation does not equal governance completion: MCP’s OAuth 2.1 layer improves consistency, but the real control problem shifts to who owns token lifecycle, delegation boundaries, and session validity. Once a server mediates trust for tool use, it becomes part of the identity plane rather than a simple integration endpoint. Practitioners should treat MCP adoption as an identity governance decision, not just a protocol choice.

Identity review models assume a stable subject, and MCP unsettles that assumption: Traditional access review and certification processes were built around human or service identities with durable entitlements. MCP workflows can create short-lived, session-bound authorisation states that are initiated by model-driven action rather than a person clicking through a request. The implication is that governance has to move closer to issuance and runtime control, not rely on periodic review alone.

Server-side token handling is now an NHI control surface: The moment an MCP server stores, validates, or reissues tokens, it inherits the same lifecycle risks seen in other NHI estates. That includes secret leakage, over-scoped delegation, and unclear offboarding when a tool, client, or provider changes. NHI governance is no longer limited to service accounts and API keys; it now extends to AI mediation layers that look like identity infrastructure in disguise.

MCP introduces an identity blast radius problem: A single client-server trust relationship can fan out across many tools, data sources, and user tasks. That is why the named concept here is identity blast radius: one mis-scoped token or weak server trust boundary can cascade across multiple downstream actions. The practitioner conclusion is simple: scope, session, and server trust must be designed together, or the protocol will amplify rather than contain access risk.

Dynamic client registration is convenient, but convenience changes the attack surface: Removing manual setup reduces friction for developers, yet it also increases the number of trust decisions made at runtime. That is useful for scale, but it raises the bar for inventory, policy enforcement, and auditability. The field should expect MCP deployments to expose governance gaps that were previously hidden by static onboarding and hand-configured integrations.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Identity blast radius: MCP turns a single authorisation decision into a chain of downstream tool, data, and action permissions. That means governance has to follow the session path, not just the login event, because the real risk is how far one trusted token can travel once a model starts acting on it.

MCP adoption will force IAM teams to think beyond user authentication and into delegated runtime control for non-human actors. The practical question is no longer whether an application can log in, but whether the protocol exposes enough structure to constrain model-initiated actions without turning every server into a bespoke identity platform.

For practitioners

• Define MCP server ownership Assign one team to own authentication, token validation, and revocation for every MCP server before it handles sensitive actions.
• Inventory all delegated tool paths Map which tools, APIs, and data sources each MCP client can reach so you can see where model-driven workflows inherit excess scope.
• Treat metadata discovery as a control point Review OAuth metadata, scopes, and registration settings for every server rather than assuming the defaults are safe enough.
• Restrict high-impact tool actions Separate read-only operations from write or destructive actions so the server cannot turn a low-risk session into broad operational access.

Key takeaways

• MCP standardisation helps AI-native tools authenticate more consistently, but it also pushes more identity responsibility into the server layer.
• The governance gap is not the login flow itself, but the amount of token handling, delegation, and trust management the server must now absorb.
• IAM teams should evaluate MCP deployments as identity infrastructure, because model-driven access can widen blast radius even when authentication is standards-based.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
• Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.