MCP token brokering closes the OAuth boundary gap for agents

At a glance

What this is: This is an analysis of MCP token security, showing that clients should not hold raw OAuth tokens because those credentials can be reused outside MCP and bypass protocol-layer controls.

Why it matters: It matters because IAM, PAM, and NHI teams need a control boundary that constrains token use, preserves auditability, and limits blast radius when AI clients or workloads are compromised.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Obot's analysis of MCP token brokering and OAuth custody

Context

MCP token security is the governance problem that appears when a client holds a raw OAuth credential after authentication. In enterprise identity terms, that makes the token a reusable NHI secret rather than a narrowly mediated capability, and it can extend far beyond the intended MCP trust boundary.

The core failure is not authentication itself but credential reuse outside the protocol layer. Once the client can call the underlying API directly, audit scope, revocation scope, and enforcement scope diverge, which is exactly where IAM controls stop matching real runtime behaviour.

For AI-driven clients and autonomous agents, that divergence becomes sharper because tool use, data access, and token handling are happening inside the same runtime path. That makes MCP token brokering an identity governance question, not just a protocol design detail.

Key questions

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. That means inventorying every token, tying it to a clear owner and purpose, limiting scope to the minimum necessary, and ensuring revocation is possible before the next refresh cycle. If the token cannot be found, reviewed and revoked, it is already outside governance.

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. Keeping token custody in the control plane lets the enterprise scope, revoke, and audit access without exposing long-lived credentials to every client or integration.

Q: What breaks when MCP revocation does not reach the underlying OAuth token?

A: You get partial offboarding. The MCP layer may say access is closed, but the token can still work against the target service, which leaves hidden standing privilege and makes incident response slower because the true credential path is still live.

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.

Technical breakdown

Why raw OAuth tokens break the MCP trust boundary

When a client receives a raw OAuth access token, it becomes a bearer credential that can be replayed anywhere that token is accepted. In MCP, that means the same token used for tool calls can also reach the underlying service API directly, outside the protocol layer and outside MCP-specific logs. The architectural problem is boundary collapse: the protocol was supposed to mediate capability use, but the client now holds the authority to bypass that mediation entirely.

Practical implication: treat the client-held token as an exposed secret and redesign the flow so the client never receives the downstream OAuth credential.

How token brokering changes credential custody

Token brokering keeps the real OAuth token in a control plane and issues the client a separate scoped token for MCP requests. The control plane validates the client token, retrieves the appropriate downstream credential, and performs the exchange internally, often with audience or resource checks to ensure the token is only used for the intended service. This turns the client from a token holder into a request originator while preserving protocol mediation and reducing replay value.

Practical implication: centralise token custody in the control plane so scope decisions and token exchange happen before any downstream API call.

Why revocation, audit, and scope enforcement depend on where the token lives

If the client owns the token, revocation becomes partial because disabling MCP access does not necessarily invalidate direct API use. Audit visibility also fragments because credential use outside MCP never appears in protocol logs. Brokering reverses that: one revocation point, one audit path, and one place to enforce fine-grained scopes tied to the tool and the target service. That is the difference between controlling a protocol session and controlling an identity credential lifecycle.

Practical implication: enforce scope checks and logging at the brokering layer, not only at the MCP server or application layer.

Threat narrative

Attacker objective: The attacker wants a reusable delegated credential that can be used outside MCP to perform unauthorized API actions with the victim's scopes.

1. Entry occurs when a compromised MCP client, rogue dependency, or malicious local component obtains a usable OAuth access token from the authentication flow.
2. Escalation follows when the token is replayed directly against the underlying API, bypassing MCP mediation, audit logs, and any tool-level business logic.
3. Impact is unauthorized actions against the connected enterprise service, with revocation and investigation hampered by incomplete visibility into token use.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Raw OAuth token exposure creates a standing privilege pattern inside a supposedly mediated system. The token remains usable until it is revoked or expires, even if the MCP layer has been disabled or the tool relationship has changed. That is structurally similar to other NHI failures where the credential outlives the control that created it. The practical conclusion is that access decisions must follow the credential, not just the protocol session.

Token brokering is best understood as blast-radius control for delegated machine access. It does not eliminate OAuth risk, but it narrows the place where a compromise can be used and observed. That matters most when MCP tools touch customer data, HR records, or financial systems because the same credential can otherwise escape the intended workflow. Teams should evaluate whether their current MCP design can prove where a token can and cannot be used.

Guide to the Secret Sprawl Challenge: The named concept here is credential boundary drift, where a token issued for mediated tool use becomes a reusable secret across unrelated services. That drift is what turns an MCP integration into a broader NHI governance problem. The more distributed the token custody, the harder it becomes to prove least privilege or maintain audit integrity across the lifecycle.

Autonomous and AI-assisted clients make the custody question more urgent. When a client can act quickly and repeatedly, token reuse can outpace human review and invalidate assumptions built into access certification cycles. That means IAM teams need to govern not just who can authenticate, but which runtime is allowed to ever see the downstream credential. The decision point is architectural, not procedural.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the State of Non-Human Identity Security.
• From our research: Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to the same research.
• For a related control lens, see Guide to the Secret Sprawl Challenge for how distributed credentials create similar governance blind spots.

What this signals

Credential boundary drift is the operating risk that emerges when a token issued for mediated tool use becomes reusable outside the protocol layer. That is not a theoretical design flaw, it is a governance failure that turns audit boundaries into assumptions rather than controls.

With 85% of organisations lacking full visibility into OAuth-connected third parties, the condition described in this article is already common enough to be systemic, not exceptional. Teams that cannot see where delegated credentials are used will struggle to enforce least privilege or prove revocation.

The next programme decision is whether MCP integrations are being governed like identity boundaries or merely like application features. If the token can escape the control plane, the security model must assume compromise at the credential layer, not just misuse inside the protocol.

For practitioners

• 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. The client should never receive a bearer token it can replay directly against the target API.
• 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. Do not let a broad service token follow the user into unrelated API paths.
• 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. Protocol logs alone will miss abuse that occurs outside MCP.
• Test revocation at the credential layer Disable a control plane token and confirm that downstream access ends immediately without residual API reach. If revocation only works inside MCP, the trust boundary is still leaking.
• Harden third-party MCP integrations before production Require mutual TLS, certificate pinning, and per-client consent for integrations that touch sensitive systems. The goal is to keep the client as a request originator, not a secret holder.

Key takeaways

• Raw OAuth tokens in MCP clients collapse the intended trust boundary because the client can use the credential outside governed protocol paths.
• Revocation, audit, and least-privilege controls only work cleanly when the control plane retains custody of the downstream OAuth token.
• Enterprises should treat MCP token brokering as a credential governance design choice, especially where AI clients touch sensitive systems.

Key terms

• Credential Boundary Drift: Credential boundary drift is the condition where a token or secret issued for one mediated workflow becomes reusable in another context. In MCP environments, it means the client can use an OAuth credential outside the protocol controls that were supposed to contain it, which weakens auditability and revocation.
• Token Brokering: Token brokering is the process of mediating downstream access by exchanging, forwarding, or minting credentials on behalf of an agent. It lets a central identity layer decide which upstream service gets which privilege, which is why it is a core design pattern for controlled agent access.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

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.

👉 Obot's full post covers the control-plane exchange model, audit coverage, and revocation mechanics.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.