Token exchange for MCP servers reduces secret sprawl and audit gaps

At a glance

What this is: Stacklok demonstrates an MCP token-exchange flow that separates client, MCP server and backend API tokens so the backend can be reached without embedded secrets.

Why it matters: This matters because IAM teams now have to govern MCP access as a trust-brokered token flow, not just a server-to-server secret distribution problem.

Context

MCP authentication becomes materially different when the server is not the end user, but a brokered runtime that needs to call downstream APIs on behalf of that user. In that pattern, the security question is no longer only whether a token is valid, but whether it is valid for the right audience, scope and service boundary.

This article focuses on a practical token-exchange setup using Okta and ToolHive to keep the MCP server and the backend GraphQL service on separate authorization planes. The governance issue is familiar to identity teams: preserve user attribution and least privilege without turning the MCP layer into a long-lived secret container.

For IAM and NHI programmes, the important shift is that the MCP server itself becomes a governed non-human execution point. That means token exchange, audience separation and trust configuration are now part of the access model, not implementation details hidden inside middleware.

Key questions

Q: How should teams govern MCP servers that act as token brokers?

A: Treat the MCP server as a governed delegation point, not a passive proxy. Give it tightly scoped audiences, explicit exchange policies and separate trust relationships for each downstream service. The aim is to keep the brokered server from becoming a reusable credential path while preserving user-level attribution.

Q: Why does audience separation matter in MCP token exchange?

A: Audience separation keeps a token issued for one service from being accepted by another. In an MCP flow, that prevents the client token from being used directly against the backend API and forces the broker to mint a backend-specific credential with the correct scope.

Q: What do security teams get wrong about replacing secrets with token exchange?

A: They assume short-lived tokens automatically solve the problem. In practice, the exchange policy becomes the new control surface, and if scopes are broad or trust is loose, the integration still creates an over-privileged access path with better packaging but the same governance weakness.

Q: How can IAM teams verify that MCP access remains auditable after exchange?

A: Check that downstream logs still carry the originating user identity and not only the broker service identity. If the audit trail stops at the MCP layer, you have technically successful delegation but weak accountability, which is exactly where investigations and recertification break down.

Technical breakdown

Audience-scoped tokens for MCP and backend separation

The demo uses distinct authorization servers and audiences so the MCP-facing token and the backend-facing token are not interchangeable. The incoming token is meant for the MCP server, while the exchanged token is meant for the GraphQL API, with scopes narrowed to the downstream action. That separation matters because audience binding stops a token from being replayed across service boundaries, and scope binding stops a valid token from becoming a general-purpose credential. In IAM terms, this is a trust-chain design, not just an authentication flow.

Practical implication: model each MCP hop as a separate audience and scope boundary instead of reusing one token across services.

Token exchange as a control plane for delegated access

Token exchange changes how delegation works in practice. The MCP client authenticates once, but the server then swaps that token for a second token that is appropriate for the backend service. This avoids embedding backend secrets in the MCP layer and gives the brokered server a credential that is both time-bound and purpose-bound. The important architectural point is that the MCP server does not need blanket backend standing access if the exchange policy is precise enough. That makes the exchange service the real control plane for downstream authorization.

Practical implication: treat the token-exchange policy as the authorisation boundary and review it like a privileged access rule.

Auditability depends on preserving user identity through the exchange

A common failure in brokered access designs is losing the original user context once a middle tier acts on behalf of that user. Here, the exchanged token retains the user identity while changing the audience and scope, which keeps logs attributable to the individual rather than to a generic service account. That distinction is important for investigations, approval workflows and usage review. Without that lineage, teams end up with technically valid access and operationally weak accountability. The point is not just that the call succeeds, but that the audit trail remains useful.

Practical implication: verify that downstream logs preserve the originating user identity, not just the broker service identity.

Breaches seen in the wild

• Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
• Cloudflare Thanksgiving breach 2023: One service token and three service accounts left unrotated after the Okta breach gave a nation-state attacker access to Cloudflare's Atlassian systems.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Token exchange is becoming the governance layer for MCP access. Once an MCP server is allowed to act as a broker to third-party APIs, static secrets stop being the right unit of control. The real question becomes which token may be minted, for which audience, and under what trust relationship. For identity teams, that means the MCP server is not a passive integration point but a governed delegation actor.

Secret minimisation is only half the control problem. Replacing embedded credentials with short-lived tokens reduces exposure, but it does not by itself solve over-broad trust. If the exchange policy is too permissive, the server still becomes a reusable access path, just with cleaner mechanics. The implication is that scope design and token audience design now matter as much as secret storage once did.

MCP introduces a new class of NHI governance pressure because the broker sits between human intent and machine execution. The user initiates the action, but the server performs the downstream call. That split makes the audit trail stronger only if token lineage survives the exchange and if the backend never sees a token that can be repurposed outside its intended service boundary. Practitioners should govern the brokered server as a privileged non-human identity, not as a simple transport layer.

Audience separation is the named control pattern worth carrying forward. The article shows that one token should authenticate to the MCP surface while another should authorise the backend API, with trust established explicitly between authorization servers. That pattern is the practical alternative to long-lived secrets, and it is the difference between a constrained delegation path and a latent credential sprawl problem. Teams should design MCP integrations around explicit audience boundaries.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Audience separation is now a core MCP governance pattern: the brokered server should hold one token for the MCP surface and a different token for the backend API. That design keeps the control plane legible, but only if the exchange policy is reviewed as carefully as any privileged access rule.

The practical shift for identity programmes is that MCP integrations now sit between human intent and non-human execution. That means lifecycle, scope and trust decisions have to be documented at the broker layer, not inferred from application code or left inside a service account.

For teams building AI-connected workflows, token exchange can reduce secret sprawl without removing the need for identity governance. The important question is whether the brokered path still exposes a clear audit trail and a tightly bounded audience for every downstream call.

For practitioners

• Define separate token audiences for each MCP hop Use one audience for the MCP-facing token and a different audience for the backend API so the same credential cannot be replayed across layers.
• Broker downstream API access through token exchange Require the MCP layer to exchange the user token for a backend-specific token instead of storing or forwarding long-lived backend secrets.
• Preserve the originating user identity in backend logs Ensure the exchanged token and downstream telemetry keep user attribution so audit trails show who initiated the action even when the MCP server executed it.
• Treat authorization-server trust as a reviewable control Inventory which authorization servers trust each other and confirm the exchange policy only allows the scopes needed by the backend service.

Key takeaways

• MCP token exchange replaces embedded backend secrets with short-lived, audience-scoped credentials, which narrows exposure but shifts governance to trust configuration.
• The backend API only remains protected if the MCP token and the backend token are separated by audience, scope and explicit authorization-server trust.
• Identity teams should govern the brokered MCP server as a privileged non-human execution point and verify that audit trails preserve the initiating user.

Key terms

• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• Audience-bound token: An access token that can only be used against a specific resource server or API. Audience binding limits replay, reduces token portability, and ensures that a credential minted for one task cannot be reused elsewhere.
• Brokered Access: Brokered access is a model where the user or workload proves identity to an intermediate control plane that issues short-lived access instead of exposing a reusable secret. For privileged operations, this shifts governance from secret storage to session control, auditability, and timely revocation.
• Authorization Server Trust: Authorization server trust is the explicit relationship that allows one issuer to accept or exchange tokens issued by another. In NHI architectures, it is the policy boundary that decides whether a broker can mediate access without becoming a hidden privilege escalator.

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 building or maturing an IAM programme, it is worth exploring.