MCP Token Security: Why Your Clients Shouldn’t Hold OAuth Tokens
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 Model Context Protocol (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. In that sense, MCP security is the set of safeguards applied to the Model Context Protocol to protect sensitive systems from data leaks, remote code execution, and other misuse.
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. The token should define a trust boundary, so the AI agent submits requests to the MCP server and can never interact directly with enterprise databases or other external systems.
If the client is compromised, the attacker doesn’t just have access to your MCP tools. They have a working HubSpot credential, which can enable unauthorized actions outside MCP controls.
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, which is one of the emerging MCP security risks leaders must plan for.
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 for Malicious MCP Server Risks
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 handles token issuance for its own scoped token — an Obot token, in our case — while keeping the real credentials in a secure vault and exchanging them only when needed for a third-party API call. The client uses that token to make MCP tool calls. When a tool call arrives at the control plane, it validates the Obot token, validates any upstream token from the identity provider, retrieves the corresponding OAuth token internally, and ensures downstream tokens are meant for the target server by checking audience or resource indicators before using them to call the MCP server. The raw OAuth credential never leaves the control plane, and short-lived credentials tied to specific scopes reduce replay value if stolen. Access tokens and refresh tokens should be treated as secrets and never exposed in logs or UI surfaces. High-value secrets such as API keys and cloud credentials should stay in a password vault as well.
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 control plane can also enforce TLS trust to the MCP server with certificate pinning or mutual TLS so clients reach only authorized servers. This model also works cleanly with an external authorization server such as Keycloak for delegated auth, MFA, and SSO.
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 and a weaker security posture from secret sprawl across server implementation boundaries.
Try Obot Today
Click here to check out Obot’s Hosted MCP Platform for free, or visit GitHub to deploy our open-source gateway on your own infrastructure.
What This Looks Like in Practice
From the client’s perspective, the flow doesn’t change much. In a client server architecture, the MCP host is the environment where the MCP client acts inside an AI assistant or other AI application, and it communicates with lightweight MCP servers that expose capabilities over the protocol for seamless integration between AI models, external systems, external services, and external data sources. It still authenticates, gets a token, and makes tool calls with it, following the same high-level MCP authentication flows and security best practices. The difference is what the token actually is and where the real credential lives.
That fits cleanly because MCP operates through standardized request and response rules for capabilities, message handling, and results, with client-server behavior that also supports API calls through the host app while keeping tool access mediated.
This is the same architectural shift that enterprise API gateways made years ago — moving credentials out of clients and into a centralized control plane, much like a modern MCP gateway that centralizes routing and security. 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, especially when enforced through a centralized MCP proxy for security and observability.
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. Minimal scopes should map directly to tool descriptions or schemas, not broad service-wide permissions, which aligns with fine-grained MCP access control beyond server-level permissions. Scope checks should be enforced on every incoming request and at tool execution so any tool invocation outside the token’s allowed scopes is rejected.
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. Tool registration events are also logged, which enables auditing each MCP request and gives security teams more data to review and act upon, and helps answer the kinds of MCP enterprise security questions your security team will ask. 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.
Continuous authentication can re-check identity and permissions for each incoming request, verifying the AI’s identity and permissions for every tool call or data request instead of trusting only the initial connection, which helps maintain a strong security posture.
MCP Token Security and Token Validation Best Practices
Token brokering adds a layer to the MCP authentication flow. Understanding when that tradeoff is worth it helps you make the right call for your deployment, especially in production environments where short-lived credentials and a progressive, least-privilege scope model reduce the blast radius of token compromise while lowering user friction, and where robust enterprise MCP access control for servers is already in place.
It matters most when:
Your MCP tools touch sensitive data — HR records, financial data, customer PII — and need least-privilege access control, often by combining role-based and attribute-based rules so enforcement stays tightly scoped to specific repositories, branches, and actions, while also preventing PII leaks from MCP tool calls into agents and logs.
You’re running autonomous agents that operate without human review of every action. MCP requires explicit user or SSO authentication before an AI agent can request broader scopes, and consent should be tied to the requesting client to avoid confused deputy risks. This also helps reduce the blast radius of MCP prompt injection attacks that agents alone can’t prevent.
Your threat model includes compromised agents or insider threats.
You have compliance requirements that demand a complete credential audit trail.
Standardized OAuth 2.1 flows between client and server also help ensure only permitted entities can reach protected endpoints.
Repeated approval prompts can create consent fatigue, so providing a clear consent screen and per-client consent will help reduce uninformed or unauthorized approvals. Even with AI-driven tools, explicit approval still matters because weak approval flows can enable unauthorized actions.
Inbound verification on incoming requests is necessary to prevent prompt injection and session hijacking, and sessions should not be relied on for authentication.
If you’re in early experimentation and running MCP tools against less sensitive systems, the simpler direct token approach is probably fine for the time being. But if you’re heading toward production in an enterprise environment, the token brokering pattern is worth building in from the start so you avoid the dangerous MCP OAuth shortcuts that ruin security: integrating an external IdP can simplify user management as teams adopt OAuth 2.0 or OpenID Connect. Stronger transport protections such as mutual TLS for strong authentication matter, alongside regular audits to catch stale permissions, expanded roles, and broader security issues.
Retrofitting it later is harder than starting with it, or as the old adage goes, “an ounce of prevention is worth a pound of cure.”
Bottom Line
The OAuth token an MCP client holds is a credential, not just a session artifact. Because the MCP specification leaves authentication optional, MCP token security decisions need layered controls; keeping it inside the control plane rather than handing it to the client closes a class of risks that many MCP architectures leave open by default.
It’s one of those decisions that’s easy to get right early and painful to fix later, especially when a local MCP server or local machine setup can reach configuration files or other sensitive resources, and when weak isolation allows malicious code, prompt injection, data exfiltration, or access to cloud metadata endpoints. The risk is higher with broad network access, particularly if MCP hosting and server deployment aren’t designed with security in mind.
