MCP authentication at enterprise scale exposes OAuth sprawl

At a glance

What this is: This is an analysis of why MCP authentication becomes an enterprise identity problem once OAuth, token storage, refresh, and revocation are distributed across many servers.

Why it matters: It matters because IAM teams must govern MCP servers like non-human identities, or they will inherit fragmented access, weak revocation, and poor auditability across the environment.

By the numbers:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Obot's analysis of MCP authentication and OAuth sprawl at enterprise scale

Context

MCP authentication is the mechanism that lets an MCP server prove which user or system it is acting for, and the article shows why that becomes difficult once OAuth is used across enterprise services. The primary IAM issue is not tool definition, but the lifecycle of access tokens, scopes, refresh handling, and revocation across many servers.

The governance gap is familiar to NHI teams: every new server can become another credential store, another audit boundary, and another offboarding problem. The article’s central point is that local success does not translate into enterprise control unless identity is centralised and governed across the whole MCP estate.

This is a typical scaling problem, not an edge case. When teams build MCP servers independently, they usually reproduce the same auth pattern many times, which turns authentication into sprawl rather than a control plane.

Key questions

Q: How should security teams govern MCP server authentication in production?

A: Treat MCP authentication as a governed access layer, not a developer convenience. Teams should verify runtime client registration, discovery, resource binding, audit logging, and enterprise identity integration before approving production use. If the provider cannot compose with SSO, provisioning, and revocation, it creates a parallel identity path that is harder to govern and harder to unwind.

Q: Why does MCP create the same kind of sprawl as NHI programmes?

A: Because every server can introduce its own client registration, token store, and refresh logic, which multiplies credential-bearing assets without a common governance model. That is the same structural problem seen in NHI sprawl: more identities, more exceptions, and less visibility. The issue is not the protocol alone, but the way it fragments control.

Q: What breaks when an MCP server passes client tokens to upstream APIs?

A: Token passthrough creates confused deputy risk because downstream services may accept a token that was issued for a different audience. That breaks authorization boundaries and can expose data or actions beyond the original MCP request. Each upstream dependency should receive its own token with its own audience and scope.

Q: What is the difference between local MCP auth and a shared control plane?

A: Local auth repeats the same OAuth logic inside each server, while a shared control plane centralises policy, token handling, and revocation. The difference matters because one model scales identity governance, and the other scales fragmentation. For enterprise use, the shared model is the one that creates a manageable audit boundary.

Technical breakdown

Why MCP OAuth implementations fragment at scale

MCP uses OAuth 2.0 to delegate authorisation, but each server still has to manage its own client registration, scopes, callback handling, and token lifecycle. That creates repeated implementation work and inconsistent control points across servers. In practice, the control plane is split across application code, token storage, and external identity provider configuration, which makes governance harder as the number of servers grows.

Practical implication: treat each new MCP server as a credential-bearing identity surface, not just an integration project.

Why token refresh and revocation become governance problems

Access tokens expire, refresh tokens can outlive expected use, and permissions change after initial consent. If the server stores and refreshes tokens locally, the organisation inherits separate revocation logic and separate recovery paths for every server. That makes incident response and access withdrawal depend on application-specific behaviour instead of a central policy.

Practical implication: centralise token issuance, renewal, and revocation so access withdrawal works consistently across all MCP servers.

Why a single control plane changes the identity model

A shared control plane moves authentication decisions out of each MCP server and into a consistent layer that can enforce scope, audit, and revocation centrally. This reduces duplicated token stores and gives security teams one place to answer who has access to what. The architectural value is not convenience alone, but a smaller identity attack surface and a clearer governance boundary.

Practical implication: design MCP access like an enterprise NHI programme, with one authoritative place for oversight and enforcement.

Threat narrative

Attacker objective: The objective is to obtain durable, distributed access through unmanaged OAuth tokens that outlive user intent and evade central governance.

1. Entry begins when a user authorises an MCP server through OAuth and the server receives an access token or refresh token that can act on enterprise services.
2. Escalation occurs when multiple servers each keep their own token stores and refresh logic, creating a wider credential footprint and inconsistent revocation behaviour.
3. Impact is fragmented access governance, where security teams cannot easily see, revoke, or audit all MCP-issued access across the environment.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity sprawl is the real MCP security problem: the article is not really about tool calls, it is about every MCP server becoming its own credential domain. That pattern mirrors NHI sprawl, where access is repeated across systems without a shared lifecycle, audit, or revocation model. The implication is that enterprise MCP adoption should be governed as an identity estate, not as isolated application plumbing.

OAuth delegation assumptions break down when MCP servers multiply: OAuth was designed for discrete integrations with clear consent and revocation boundaries, but distributed MCP deployments turn those boundaries into a patchwork. Each server introduces its own storage, refresh, and scope decisions, which means access control no longer has a single operational truth. Practitioners should recognise this as a governance architecture issue, not an implementation quirk.

Centralising MCP authentication is a control plane decision, not a convenience feature: one auth layer creates one place to enforce scope, log usage, and revoke access. That matters because NHI governance fails when token-bearing systems are left to self-manage. The field should treat shared auth infrastructure as the baseline for enterprise MCP, the same way it treats central IAM for users.

Runtime auth fragmentation: the article exposes a named concept that matters across NHI and AI-adjacent estates, because every independently built MCP server becomes a separate runtime authorisation boundary. Once that boundary is duplicated across teams, security loses the ability to reason about access consistently. Practitioners should see the pattern as a warning against decentralised token governance.

MCP will accelerate the convergence of IAM, NHI, and agent tooling governance: the same control patterns that govern service accounts, API keys, and OAuth tokens now have to cover tool-connected AI infrastructure. That means identity architecture teams, not just application developers, need to own the operating model. The practical conclusion is that MCP authentication cannot be left as an integration afterthought.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which explains why distributed token estates become difficult to unwind.
• The same lifecycle problem is explored in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, where revocation and rotation are treated as governance, not cleanup.

What this signals

Identity sprawl will become the default failure mode for enterprise MCP unless teams stop treating each server as a separate auth project. The governance problem is not whether a single implementation works, but whether access can be seen, scoped, and revoked consistently across many servers. That is the same structural issue NHI programmes face when token-bearing systems are left to proliferate without lifecycle ownership.

Runtime auth fragmentation: once OAuth handling is duplicated across teams, the organisation loses a stable boundary for audit and incident response. Security leaders should expect MCP to expose the same control gaps that service accounts and API keys already create when lifecycle discipline is weak.

MCP adoption will push IAM teams toward centralised policy enforcement, shared revocation, and better ownership of token-bearing integrations. For practitioners, the signal is clear: if identity architecture is not designed up front, tool growth will outpace governance capacity.

For practitioners

• Centralise MCP token governance Move OAuth app registration, token storage, refresh handling, and revocation into a shared control plane instead of repeating them in each server. This gives IAM teams one authoritative place to see issued access and one revocation path when access changes.
• Inventory every MCP server as an identity-bearing system Catalog each server, its scopes, its token store, and its callback configuration so the organisation can answer who has access to what. Treat unknown or ad hoc servers as shadow identity infrastructure and bring them under governance.
• Separate authentication from tool logic Keep tool execution logic out of the access boundary so changing scopes or revoking access does not require rewriting application code. That reduces drift between what the server does and what the organisation believes it can do.
• Build revocation tests into change management Test that access can be withdrawn centrally when a user loses access, a token expires, or a server is retired. Verify that revocation works across all connected enterprise systems, not just in the MCP server that requested the token.

Key takeaways

• MCP authentication becomes an identity governance problem as soon as OAuth, token storage, and revocation are distributed across many servers.
• The strongest evidence points to sprawl, not tool logic, as the real enterprise risk, because each server can create its own token lifecycle and audit boundary.
• Centralised authentication and revocation are the difference between manageable MCP adoption and a fragmented access estate.

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.
• Oauth Token Sprawl: The growth of separate access and refresh token stores across many applications or servers. It becomes risky when each system manages credentials independently, because revocation, audit, and lifecycle control fragment across the environment and security teams lose a complete view of who can access what.
• Shared control plane: A shared control plane is a central layer that connects policy, risk, privacy, and security workflows so teams work from the same source of truth. It reduces duplicated reviews and improves auditability when multiple groups must govern the same AI system.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full article

Obot's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step OAuth implementation choices for MCP servers that need per-user access.
• The specific token storage and refresh handling patterns the series recommends for enterprise rollout.
• How a shared control plane changes revocation, audit, and scope management across many servers.
• The implementation trade-offs between local auth handling and centralised MCP governance.

👉 The full Obot post covers the implementation detail behind token handling, revocation, and shared auth control.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.