Notifications
Clear all
Topic starter
19/08/2026 4:06 pm
TL;DR: Raw OAuth tokens in MCP clients create a trust boundary problem because the token can be reused outside the protocol layer, bypassing audit logs, scope checks, and revocation intent, according to Obot. Brokering the token in a control plane instead of exposing it to the client turns MCP into a governed credential boundary, not just a tool-calling path.
NHIMG editorial — based on content published by Obot: MCP Token Security: Why Your Clients Shouldn’t Hold OAuth Tokens Series: Enabling MCP at Enterprise Scale - Post 4 of 10
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams handle MCP-delegated OAuth tokens in developer tools?
A: Treat them as governed non-human identities, not as hidden configuration.
Q: Why do raw OAuth tokens create risk in MCP environments?
A: Raw tokens expand the compromise surface because they can be reused outside the intended workflow and often outlive the session that created them.
Q: What breaks when MCP revocation does not reach the underlying OAuth token?
A: You get partial offboarding.
Practitioner guidance
- Keep downstream OAuth tokens out of MCP clients Route authentication through a control plane that exchanges its own scoped token for the downstream OAuth credential internally.
- Bind scopes to the tool and target service Issue credentials that are narrow enough for the specific MCP tool, then verify audience or resource indicators before each downstream call.
- Log token exchange, not only tool invocation Capture the exchange between the client token and the downstream OAuth token so investigations can reconstruct where the credential was used and by whom.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step brokered token flow showing how the control plane exchanges credentials without exposing the downstream OAuth token to the client.
- Implementation detail on audience and resource indicator checks for downstream API calls, including how scope checks are enforced at request time.
- Guidance on mutual TLS, certificate pinning, and delegated auth patterns when MCP clients connect to sensitive enterprise services.
- The article's distinction between direct-token and brokered-token architectures for production MCP deployments.
👉 Read Obot's analysis of MCP token brokering and OAuth custody →
MCP token brokering: are your clients still holding raw OAuth tokens?
Explore further
19/08/2026 4:39 pm
MCP token security is an identity custody problem, not just an authentication problem. The article is right to focus on where the OAuth token lives after login, because custody determines whether the token can be used only through governed protocol paths or anywhere the underlying service accepts it. Once a client holds the raw credential, the control plane loses meaningful enforcement over scope, logging, and revocation. Practitioners should treat token location as a first-class governance decision.
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, according to the same research.
A question worth separating out:
Q: Who is accountable when an MCP client token is reused outside the protocol boundary?
A: The organisation that allowed the client to hold a reusable credential remains accountable for the resulting access. OAuth governance, secret custody, and MCP policy need to be aligned so delegated identity cannot outlive the controls that were supposed to contain it.
👉 Read our full editorial: MCP token brokering closes the OAuth boundary gap for agents
