Token exchange for MCP servers reduces secret sprawl and audit gaps

At a glance

What this is: This is a practical walkthrough of using token exchange so an MCP server can call a backend API with properly scoped, short-lived OAuth tokens.

Why it matters: It matters because IAM teams need to govern MCP servers as NHI actors that should not hold reusable backend secrets, while preserving traceable, least-privilege access paths.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read Stacklok's blog post on token exchange for MCP server authentication

Context

MCP server identity security is really about how a non-human intermediary proves who it is, what it is allowed to call, and how those permissions are constrained at runtime. In this article, the central governance gap is not API access itself, but the tendency to collapse client authentication, backend authorisation, and service-to-service trust into one brittle credential path.

Token exchange separates those concerns. The MCP server receives a token for the MCP boundary, then swaps it for a downstream token that matches the backend audience and scope. For IAM and NHI teams, that is the difference between governed delegation and a long-lived secret embedded somewhere in the toolchain.

The article uses a GraphQL backend and Okta as the example identity provider, but the operating pattern is broader than either product. The starting position is typical for teams building AI toolchains and custom MCP services: they need access orchestration before they have mature NHI lifecycle controls.

Key questions

Q: How should security teams govern MCP servers that wrap REST APIs?

A: Security teams should govern MCP servers as agent-facing identity surfaces, not as simple API adapters. The key controls are tool scoping, resource separation, token-based authentication, and clear usage guidance so the model cannot infer broader privilege than intended. If those controls are weak, the MCP layer can concentrate access in ways that are harder to audit than the original API.

Q: Why do MCP integrations create new NHI risk if they reuse one token everywhere?

A: Because a single bearer token collapses authentication, authorisation, and backend access into one reusable credential. If that token leaks, the attacker inherits both trust boundaries. Token exchange reduces that risk by limiting each token to one audience and one operational purpose.

Q: What breaks when an MCP server is given direct backend secrets instead of exchanged tokens?

A: You lose privilege separation, audit clarity, and revocation precision. The backend secret can be copied, reused, or buried in configuration, and offboarding becomes secret hunting instead of policy revocation. That is exactly the kind of lifecycle weakness NHI governance is meant to avoid.

Q: How do IAM teams decide whether token exchange is enough for MCP governance?

A: Use token exchange when the intermediary only needs to mediate access and should not hold long-lived backend credentials. If the design requires persistent backend privileges, then the architecture is already too broad and should be reworked before it is productionised.

Technical breakdown

How token exchange separates the MCP boundary from backend access

Token exchange is an OAuth pattern in which one token is exchanged for another token with different audience and scope claims. In this setup, the MCP-facing token authorises the client to call the MCP server, while the exchanged token authorises the MCP server to call the backend API. That prevents a single bearer token from being reused across trust boundaries. It also keeps the frontend identity and backend identity distinct, which is essential when the intermediary is a non-human system acting on behalf of a user.

Practical implication: treat the MCP server and the backend API as different identity domains, not as one shared access path.

Why audience and scope claims matter for MCP authentication

The aud claim tells the verifier who the token is meant for, while scopes define the operations the holder may perform. In the article, the MCP token is constrained to the MCP server audience and tools scope, and the downstream token is constrained to the backend audience and read scope. That design reduces privilege bleed between components. It also means a valid token for one service should be rejected by the other, which is how token exchange supports least privilege at the protocol layer rather than relying on code discipline alone.

Practical implication: validate audience and scope separately at each boundary, and do not assume a token accepted by one service should be accepted downstream.

What ToolHive is doing in the trust chain

ToolHive acts as the broker that authenticates the incoming MCP client token, then performs the exchange against the identity provider to obtain the backend token. The important identity control is not the transport layer itself, but the trust relationship between authorization servers and the policy that permits exchange for the intended client, scope, and grant type. Without that policy separation, the broker becomes an over-privileged relay. With it, the broker can mediate access without storing reusable backend secrets in the MCP integration path.

Practical implication: govern the broker as an NHI intermediary with explicit trust, policy, and revocation boundaries.

NHI Mgmt Group analysis

Token exchange is a governance control, not just an integration convenience. The article shows that MCP security improves when the intermediary never carries the same credential into both the user-facing and backend-facing legs of the flow. That matters because NHI programmes often fail when a single secret becomes the bridge across domains. Practitioners should see this as identity partitioning, not only OAuth plumbing.

Scoped backend calls are only meaningful if the trust chain is policy-backed end to end. The article separates client authentication, authorization-server trust, and exchange policy, which is the right mental model for NHI governance. A broker that can authenticate but cannot constrain exchange is still a weak control point. The practical conclusion is that access governance must extend to the token exchange step itself, not stop at login.

Identity blast radius shrinks when the backend token is audience-specific and short-lived. That is the named concept this article surfaces: the downstream token should only exist for one backend purpose and one backend audience. It limits reuse if a token leaks and makes audit trails more defensible because the backend call remains tied to the originating user identity. Practitioners should measure blast radius, not just token issuance success.

This pattern fits the NHI lifecycle model better than embedded API secrets do. An MCP server that exchanges tokens can be onboarded, scoped, and eventually offboarded through policy and trust revocation instead of secret hunting. That aligns with NHI governance because the identity is explicit, the permissions are bounded, and the downstream privilege can be withdrawn without rewriting the integration. Teams should treat token exchange as part of NHI lifecycle design.

Auditability improves only when the exchanged identity is preserved through the call chain. The article’s stated benefit is cleaner audit trails, and that requires the backend to receive a token that still reflects the originating user context rather than a generic service credential. For IAM and IGA teams, that means traceability is a design outcome, not a logging afterthought. The implication is that token exchange should be assessed alongside access reviews and attribution requirements.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to Astrix Security's The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how far many implementations still are from least-privilege design.
• MCP teams should compare that exposure pattern with Guide to the Secret Sprawl Challenge to reduce static credential use before it becomes operational debt.

What this signals

Identity blast radius: MCP programmes need to be measured by how far a credential can travel, not just whether authentication succeeds. When a broker can exchange a token into a narrower backend audience, the programme is moving in the right direction, but only if the exchange policy is tightly controlled and revocable.

The wider signal is that MCP governance is converging with classic NHI lifecycle work. Access scoping, attribution, and offboarding now matter for tool brokers and AI integrations in the same way they matter for service accounts and API keys, which is why teams should align MCP controls with the Secret Sprawl Challenge and external guidance such as OWASP Agentic AI Top 10.

As MCP adoption expands, the deciding question will be whether organisations can govern token exchange as a first-class identity boundary. If they cannot, the default outcome is more hidden secrets, broader delegation, and weaker attribution across human, NHI, and agent-driven workflows.

For practitioners

• Separate MCP and backend trust domains Create distinct authorization servers, policies, and scopes for the MCP boundary and the backend API so one token cannot be reused everywhere. Keep the MCP-facing token limited to tool invocation and the downstream token limited to the backend operation set.
• Constrain token exchange to explicit broker policies Require the exchange client, grant type, audience, and scopes to be approved together so the broker cannot mint broader backend access than intended. Review the exchange policy as part of NHI access governance, not as a one-time setup task.
• Preserve user attribution through the downstream call Ensure the exchanged token retains the originating identity context needed for audit and recertification, rather than collapsing everything into a shared service account. That makes downstream access reviewable and supports cleaner operational accountability.
• Eliminate reusable backend secrets from MCP integrations Prefer short-lived exchanged tokens over embedded client secrets, static API keys, or copied bearer tokens in MCP server configuration. If a secret is unavoidable in a demo or bootstrap flow, isolate it and rotate it out of the operational path immediately.

Key takeaways

• MCP token exchange reduces credential sprawl by separating the client token from the backend token and limiting each to a specific audience.
• The main governance win is not convenience but identity partitioning, which shrinks blast radius and improves attribution across backend calls.
• Teams that still embed reusable secrets in MCP integrations are carrying the same lifecycle risk that has already driven widespread NHI exposure elsewhere.

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 Claim: The audience claim is the value inside a token that identifies who or what should accept it. For non-human identity governance, it is the enforcement point that prevents a token issued for one resource from being accepted by another resource with a different trust boundary.
• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Stacklok's full blog post covers the implementation detail this post intentionally leaves at the governance level:

• Step-by-step Okta authorization server configuration for separate MCP and backend audiences
• ToolHive command-line examples showing token exchange parameters and issuer validation
• MCP server configuration details for forwarding downstream bearer tokens to the backend API
• Practical token claim examples that show the difference between client and exchanged access tokens

👉 Stacklok's full post covers the Okta setup, ToolHive parameters, and token flow details in implementation order.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.