Notifications
Clear all
Topic starter
20/08/2026 5:28 pm
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.
NHIMG editorial — based on content published by Obot: MCP identity management at enterprise scale and the control-plane pattern
Questions worth separating out
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: Why does MCP create identity sprawl in practice?
A: Because each server often gets built by a different team on a different timeline, with separate OAuth logic and separate token handling.
Q: What breaks when MCP servers do not require authentication?
A: When MCP servers do not require authentication, the access boundary disappears.
Practitioner guidance
- Centralize MCP identity governance Move OAuth registration, token brokering, logging, and revocation into a shared control plane so every server inherits the same policy boundary.
- Eliminate local token storage Keep raw OAuth tokens out of individual MCP servers and store them only in the control plane with encrypted handling and short-lived exposure.
- Standardize revocation workflows Define one revocation path that cuts off access across all MCP servers at once, including offboarding and compromise response.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step control-plane mechanics for Dynamic Client Registration, token brokering, and callback handling.
- Architecture-specific guidance on where MCP servers end and the identity layer begins.
- Detailed examples of how unified revocation works across multiple MCP servers.
- Implementation notes on how different teams can inherit one security model without rebuilding OAuth each time.
👉 Read Obot's analysis of MCP identity management at enterprise scale →
MCP identity sprawl at scale: is your control plane ready?
Explore further
20/08/2026 6:16 pm
Identity sprawl is the real MCP scaling risk. When every MCP server implements its own OAuth stack, the programme loses a shared view of issuance, storage, and revocation. That is not just a technical inconvenience, it is a governance failure because access can no longer be governed consistently across the full server estate. Practitioners should read this as a signal to define MCP identity as a platform service, not a per-server task.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows that confidence and control rarely move together.
A question worth separating out:
Q: What is the difference between an MCP server and an MCP control plane?
A: The server should host tools, resources, and prompts. The control plane should handle authentication, authorization, token exchange, storage, logging, and revocation. If those responsibilities stay inside the server, every new integration duplicates security logic and makes identity governance harder instead of easier.
👉 Read our full editorial: MCP identity management at scale demands a control plane
