TL;DR: As MCP adoption spreads across BI, HR, legal, and support use cases, each server tends to grow its own OAuth stack, creating fragmented token storage, revocation, and audit paths, according to Obot. The real issue is not individual server auth, but the governance assumption that identity can stay local when AI access becomes shared infrastructure.
At a glance
What this is: Obot argues that MCP at enterprise scale turns OAuth from a per-server implementation detail into a control-plane governance problem because identity, token handling and audit paths fragment across servers.
Why it matters: IAM, NHI and PAM teams need a shared control plane for MCP because distributed auth stacks make revocation, visibility and policy consistency harder as AI access spreads across business functions.
Context
MCP identity management is the problem of governing authentication, authorization, token handling and auditability across many MCP servers instead of leaving each server to build its own OAuth stack. At enterprise scale, that matters because the same protocol starts serving BI, HR, legal and support use cases, and the identity model becomes shared infrastructure rather than a local implementation detail.
The governance gap is not just operational duplication. Once multiple teams ship their own server-side auth, the organisation loses a central view of issued tokens, a single revocation path and a consistent audit trail, which makes access review and offboarding materially harder across both human users and AI agents.
Key questions
Q: How should security teams govern MCP OAuth flows in enterprise environments?
A: Treat MCP OAuth as an identity control plane, not a convenience layer. Bind authorization state to the initiating session, display clear consent context, restrict redirect URIs, and review every proxy-style client registration. If the server cannot prove who initiated the request and where the callback should go, it should not issue a usable authorization code.
Q: Why does fragmented credential management increase identity risk?
A: Fragmentation creates separate sources of truth for access, so lifecycle events, exception handling, and audit evidence no longer line up. That weakens offboarding, obscures lingering access, and makes policy enforcement uneven. In practice, the organisation can authenticate users successfully while still failing to govern their access coherently.
Q: What breaks when MCP revocation is not centralised?
A: Revocation becomes slow, incomplete and difficult to verify. If a token is compromised or a user leaves, teams must chase access across multiple servers and identity providers instead of cutting off one control point. That leaves residual access alive longer than the business expects and makes audit evidence fragmented.
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 per-server OAuth creates identity sprawl in MCP
MCP standardises how clients reach tools and data, but it does not remove the need to govern who can reach them. When each server implements OAuth, callback handling, scopes, token storage and refresh logic separately, the result is not a single identity model but many inconsistent ones. That makes governance drift inevitable because each server inherits a different security posture, logging format and revocation behaviour. The technical problem is duplication of identity logic across infrastructure that should behave as one control surface.
Practical implication: treat per-server OAuth as a scaling anti-pattern and design for shared identity policy before you add another MCP server.
What a control plane centralises in MCP authentication
A control plane pulls Dynamic Client Registration, OAuth delegation, token exchange, encrypted token storage, audit logging and revocation into one layer that sits between MCP clients and servers. The servers then focus on tools, resources and prompts while the control plane becomes the place where identity decisions are enforced. This architecture matters because it reduces the number of independently managed trust decisions and creates a single revocation point. It also aligns with least privilege by letting each agent or client receive only the scope required for the task.
Practical implication: centralise token brokering and revocation so new MCP servers inherit policy instead of replicating it.
Why raw OAuth tokens should stay out of MCP servers
When raw OAuth tokens are stored across multiple MCP servers, exposure risk multiplies with every deployment, backup and log path. A control plane changes the exposure model by keeping token handling in one place and using short-lived credentials instead of long-lived ones wherever possible. That does not eliminate trust, but it narrows the places where a compromise can turn into broad access. In practical terms, the architecture moves from dispersed token custody to governed token brokering, which is the only model that scales cleanly across many servers.
Practical implication: keep raw OAuth tokens out of server-local storage and enforce short-lived token handling in a central layer.
Threat narrative
Attacker objective: The objective is to exploit fragmented MCP identity governance so access can persist unnoticed across multiple servers and identity providers.
- Entry occurs when each MCP server is allowed to build and store its own OAuth implementation, creating many separate trust paths instead of one governed access layer.
- Credential exposure and abuse happen when tokens, refresh logic and callback handling are scattered across servers, making revocation and audit response inconsistent.
- Impact follows as the organisation loses a single point to answer who has access, where tokens live and how to cut off access across the whole MCP estate.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- 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 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity sprawl is the real MCP scaling problem, not individual server authentication. When every team builds its own OAuth stack, the organisation creates multiple local trust regimes that cannot be governed as one system. That is not just duplication; it is a governance failure because the identity model stops being portable across the enterprise. Practitioners should treat each new MCP server as another source of control-plane fragmentation, not just another integration.
Centralised identity governance becomes mandatory once MCP is used as shared infrastructure. BI, HR, legal and support may all connect through the same protocol, but the access model cannot be allowed to remain local to each team. Without a shared control plane, auditability, revocation and scope consistency depend on implementation quality in each silo. The field should stop describing this as an auth convenience problem and start treating it as enterprise identity architecture.
Ephemeral access only helps if the control point is shared. Short-lived tokens reduce exposure window, but they do not solve the more fundamental problem of duplicated issuance and revocation logic across servers. The important concept here is identity blast radius: once access decisions are distributed, a single compromise or configuration error can propagate unevenly across the estate. Practitioners need to reduce the number of places where identity state can diverge.
MCP changes the meaning of least privilege because the same agent may touch many business systems through one protocol. A shared protocol does not equal a shared permission model, and that mismatch is where governance breaks down. If the identity plane is fragmented, least privilege becomes a server-by-server hope rather than an enforceable policy. Security teams should assume that access review, offboarding and audit all become unreliable when the control plane is missing.
The market is moving toward control-plane governance for AI access. As more organisations standardise on MCP, the security question shifts from whether a server can authenticate to whether the enterprise can govern identity consistently across all servers. That aligns more closely with NHI governance than traditional app-by-app IAM, because the same machine or agent identity may need to be recognised, scoped and revoked across many services. The practical conclusion is simple: architecture now decides governance quality.
From our research library:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
- Read next: MCP Security Guide
What this signals
Identity sprawl is the control failure that emerges first: when each MCP server owns its own OAuth stack, revocation and auditability fragment before the business notices the scale problem. The practical response is to stop treating authentication as a per-integration task and treat it as shared infrastructure governance.
Control-plane thinking is becoming the default architecture for enterprise MCP: once AI access crosses BI, HR, legal and support, the identity question is no longer who can reach one server but who can govern access consistently across all of them. That is where identity architecture and operational security converge.
Protocol sprawl creates token sprawl: the average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms, according to the OAuth 2.0 and OpenID Connect Guide for Identity Teams. MCP extends that same governance problem into AI-connected workflows, so token custody and revocation discipline need to move upstream.
For practitioners
- Define a single MCP control plane Centralise client registration, token brokering, callback handling, audit logging and revocation instead of implementing OAuth separately in each server.
- Constrain token custody to one layer Keep raw OAuth tokens out of individual MCP servers and require short-lived tokens with encrypted storage in the control plane.
- Map every MCP server to a shared policy model Assign consistent scope rules, logging retention and access review ownership across BI, HR, legal and support servers so governance does not drift by team.
- Design revocation as a single action Test whether a departing employee or compromised token can be cut off once and have that decision cascade across every MCP server and downstream integration.
- Separate server logic from identity logic Keep tools, resources and prompts in the server layer while moving authentication and authorization decisions into the control plane.
Key takeaways
- MCP scaling turns identity from a server-level implementation detail into a shared governance problem because each new server can introduce its own OAuth stack.
- Fragmented token storage, revocation and audit paths increase the chance that access persists after an employee leaves or a token is compromised.
- A central control plane gives security teams one place to manage registration, token handling, logging and revocation across all MCP servers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared MCP servers can accumulate excessive scopes and inconsistent permissions across teams. |
| NHI-07 — Long-Lived Secrets | The article warns against long-lived tokens and scattered credential storage across servers. | |
| Recommendation — Audit MCP server scopes for overprivilege and remove permissions that exceed each agent or client task. Replace long-lived token storage with short-lived credentials and centralise renewal policy. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post is fundamentally about consistent authorisation across many MCP servers. |
| Recommendation — Apply PR.AA-05 to enforce consistent access permissions and revocation across the MCP estate. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen or misplaced OAuth tokens can be used to move through connected SaaS environments. |
| Recommendation — Map fragmented token governance to credential access and lateral movement risks in connected SaaS. | ||
| NIST Zero Trust (SP 800-207) | Control plane — Control plane governance | The article's core remedy is a central trust-enforcement layer for AI access. |
| Recommendation — Place authentication and revocation decisions in a shared control plane instead of per-server logic. | ||
Key terms
- MCP Control Plane: The policy layer that governs which identities can reach which MCP servers and tools. In practice, it centralises registration, authorisation, and audit so access does not depend on the specific AI client a person or workflow happens to use.
- Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.
- Token Brokering: Token brokering is the process of mediating downstream access by exchanging, forwarding, or minting credentials on behalf of an agent. It lets a central identity layer decide which upstream service gets which privilege, which is why it is a core design pattern for controlled agent access.
- Session revocation: The ability to invalidate active sessions so access ends immediately instead of waiting for tokens or browser state to expire. For identity governance, this is the control that determines whether authentication still matters after a compromise is detected.
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.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org