Notifications
Clear all
Topic starter
20/08/2026 5:32 pm
TL;DR: MCP authentication looks simple in local tutorials, but enterprise deployment quickly turns OAuth into a distributed identity problem as each server needs its own scopes, token storage, refresh logic, and revocation path, according to Obot. The real risk is identity sprawl, because access governance fragments once MCP servers scale beyond a single implementation.
NHIMG editorial — based on content published by Obot: MCP authentication at enterprise scale exposes OAuth sprawl
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.
Questions worth separating out
Q: How should security teams govern MCP server authentication in production?
A: Treat MCP authentication as a governed access layer, not a developer convenience.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Obot's analysis of MCP authentication and OAuth sprawl at enterprise scale →
MCP authentication and OAuth sprawl: what teams need to fix?
Explore further
20/08/2026 6:19 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP authentication at enterprise scale exposes OAuth sprawl
