Series: Enabling MCP at Enterprise Scale — Post 4 of 10
Most teams securing MCP focus on who can connect and which tools they can call. That’s the right instinct. But there’s a related MCP token security problem that gets less attention: what happens to the OAuth token after the client authenticates.
In the best case situation the MCP server holds on to the OAuth access token, and worst the client gets the OAuth access token and uses it directly. That works. It also creates a security boundary most teams don’t think about until something goes wrong.
The Problem With Clients Holding Raw MCP OAuth Tokens
When an MCP client holds a raw OAuth access token, it has a usable credential — not just for MCP tool calls, but for anything that token permits against the underlying service.
Think about what that means. Your MCP client authenticates to HubSpot and gets an OAuth token scoped to read and write contacts. The client uses it to call MCP tools. But that same token can also call the HubSpot API directly — outside of MCP, outside of your audit logs, outside of any business logic and access controls you’ve put in place at the MCP layer.
If the client is compromised, the attacker doesn’t just have access to your MCP tools. They have a working HubSpot credential.
Token exfiltration. A compromised MCP client — whether that’s a rogue agent, a vulnerable dependency, or something more deliberate — can extract the OAuth token and use it elsewhere. Your MCP audit logs won’t show anything, because the token is being used outside of MCP.
Scope overreach. MCP OAuth tokens are often scoped more broadly than any single MCP tool needs. A token that grants read/write access to your CRM gets issued to a client that only needs to run a read query. The extra permissions sit there unused — until they’re not.
Revocation gaps. If you revoke access at the MCP layer — remove a user from a registry, disable a server — the underlying OAuth token may still be valid. You’ve closed the MCP door but left the window open.
Audit blind spots. Token usage that happens outside of MCP doesn’t appear in your MCP audit logs. If something goes wrong, your investigation starts with incomplete data.
What MCP Token Brokering Solves
The idea behind MCP token brokering is simple: the control plane (the centralized layer that manages MCP traffic and credentials) holds the real OAuth tokens, and clients never see them.
Instead of issuing a raw OAuth token to the MCP client, the control plane issues its own scoped token — an Obot token, in our case. The client uses that token to make MCP tool calls. When a tool call arrives at the control plane, it validates the Obot token, retrieves the corresponding OAuth token internally, and uses it to call the MCP server. The raw OAuth credential never leaves the control plane.
Here’s what changes:
Before: MCP client authenticates → receives OAuth access token → uses it directly for tool calls → token can also be used against the underlying API directly.
After: MCP client authenticates → receives control plane token → uses it for tool calls → control plane exchanges internally for OAuth token → raw token stays inside the control plane.
The client ends up with a token that’s only useful for MCP tool calls through the control plane. It can’t be used to hit the underlying API directly. If it’s exfiltrated, it’s useless outside of the controlled environment.
This could also be handled per MCP server, but then you have distributed token stores in your organization introducing other challenges.
Try Obot Today
⬇️ Download the Obot open-source gateway on GitHub and begin integrating your systems with a secure, extensible MCP foundation.
What This Looks Like in Practice
From the client’s perspective, the flow doesn’t change much. It still authenticates, gets a token, and makes tool calls with it. The difference is what the token actually is and where the real credential lives.
This is the same architectural shift that enterprise API gateways made years ago — moving credentials out of clients and into a centralized control plane. MCP token brokering applies that same pattern to the AI tool layer.
A few things this enables that weren’t possible before:
Tighter revocation. Revoke the control plane token and access ends immediately — across all MCP servers, for all tools. The underlying OAuth token is never exposed, so there’s nothing left to clean up elsewhere.
Scope isolation. The control plane requests OAuth tokens scoped to exactly what each MCP server needs, regardless of what the client asked for. The client’s token is scoped to its MCP access. The OAuth token is scoped to the specific service. They’re separate.
Complete audit coverage. Because all tool calls go through the control plane, every credential use is logged — including the exchange between the Obot token and the underlying OAuth token. For a detailed look at how audit logging works in Obot, including role-based access to logs, see our security guide. There are no blind spots.
MCP Token Security Best Practices: When This Matters Most
Token brokering adds a layer to the auth flow. Understanding when that tradeoff is worth it helps you make the right call for your deployment.
It matters most when:
Your MCP tools touch sensitive data — HR records, financial data, customer PII
You’re running autonomous agents that operate without human review of every action
Your threat model includes compromised agents or insider threats
You have compliance requirements that demand a complete credential audit trail
If you’re in early experimentation and running MCP tools against non-sensitive systems, the simpler direct token approach is probably fine for now. But if you’re heading toward production in an enterprise environment, the token brokering pattern is worth building in from the start. Retrofitting it later is harder than starting with it.
Bottom Line
The OAuth token an MCP client holds is a credential, not just a session artifact. Treating it that way — keeping it inside the control plane rather than handing it to the client — closes a class of MCP token security risks that most MCP architectures leave open by default.
It’s one of those decisions that’s easy to get right early and painful to fix later.
Next in the series: Integrating Third-Party MCP Servers With Your Enterprise IdP
