MCP server identity should move from shared keys to token exchange

At a glance

What this is: This article explains why MCP servers should stop using shared keys and instead use token exchange and federation so backend calls carry the right user or service identity context.

Why it matters: It matters because IAM, PAM, and NHI teams need a governable way to preserve attribution and scope when MCP servers call downstream APIs across trust boundaries.

Context

MCP server identity becomes difficult to govern when a single shared credential stands in for many users, tools, and downstream actions. The core problem is not just authentication to the MCP server, but how the server proves identity to the backend service it calls next. That is an NHI governance issue because the credential is non-human, reusable, and often broader than any one task requires.

Static keys and shared service accounts create a tracing problem as well as a privilege problem. When every call flows through the same identity, audit logs lose the user context needed for accountability, and permission scope expands to avoid breaking tool execution. In practice, that makes MCP deployments harder to govern across multi-tenant and cross-domain environments.

Token exchange and federation address the identity translation gap by separating user authentication from backend authorization. The article frames ToolHive as the operational layer that validates the inbound token, then acquires the downstream token with the right audience and scope. That pattern is typical of the kind of identity plumbing modern MCP deployments now need, not an edge case.

Key questions

Q: What breaks when an MCP server uses one shared API key for every agent?

A: A shared key collapses identity, scope, and attribution into one credential, so any leak becomes universal access to every tool and backend resource the server brokers. It also makes revocation blunt, because removing the key breaks all legitimate callers at once. That is the same structural failure seen in weak service-account design.

Q: Why do token exchange and federation reduce MCP identity risk?

A: They let the inbound user or service token be translated into a downstream token that matches the right audience, scope, and trust domain. That preserves identity context across calls, narrows privilege, and avoids using one durable secret for every backend action.

Q: How do security teams know whether an MCP deployment is using a safe identity model?

A: Look for evidence of runtime secret retrieval, scoped delegation, explicit ownership, and revocation that does not depend on editing a config file. If access only exists because a secret was copied into the runtime, the model is still relying on static trust.

Q: What should organisations do when an MCP backend sits in a different trust domain?

A: Use federation or token exchange instead of issuing a separate static credential. The goal is to let the server act with a backend-specific token that still reflects the original subject, so the trust boundary is explicit and revocation stays manageable.

Technical breakdown

Why shared credentials fail in MCP server identity

MCP authorization covers access to the MCP server itself, but it does not define how the server authenticates to the downstream resource it is calling. That gap leads developers to embed a service-account key or long-lived API key in configuration, then reuse it as a shared identity for all requests. The result is broad permission scope, poor audit fidelity, and a revocation problem because one key can represent many users and many tenants. In identity terms, the backend cannot distinguish who actually initiated the action.

Practical implication: treat downstream authentication as a separate identity problem from MCP server access.

How token exchange preserves user context across trust domains

Token exchange lets one security token be presented to a security token service and exchanged for a new token valid for a different audience, scope, or trust domain. In an MCP pattern, the user authenticates to an identity provider, the MCP gateway validates that token, and the backend call uses a new token with the correct downstream permissions. When the same issuer is used end to end, the model is simpler; when a different trust domain is involved, federation extends the same idea across cloud or organisational boundaries.

Practical implication: use token exchange where the same IdP exists, and federation where the backend lives in a different trust domain.

Why short-lived tokens change auditability and least privilege

Short-lived tokens are not just a replacement for static secrets. They force the permission decision to stay close to the user session, which reduces the blast radius if something is compromised and improves attribution because the token carries the caller’s identity context. That matters for MCP servers because they often mediate many tool calls on behalf of many users. If the backend token is narrow and time-limited, the server can remain mostly auth-agnostic while still enforcing scoped access downstream.

Practical implication: issue time-bound, audience-specific tokens for downstream calls rather than sharing one durable credential.

Threat narrative

Attacker objective: The attacker wants durable, reusable access to backend services through a single compromised MCP credential rather than one user-scoped session.

1. Entry occurs when developers embed a service-account JSON key or long-lived API key into MCP configuration files and runtime settings.
2. Credential abuse follows when the shared identity is reused for all backend calls, so one compromise exposes access across many users or tenants.
3. Impact occurs when the shared credential widens blast radius, weakens least-privilege, and breaks auditability across downstream services.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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

Shared MCP credentials create identity blast radius: when one API key or service account stands in for many users, the backend cannot preserve the identity of the true actor. That is not a minor implementation flaw; it is a structural governance weakness that turns every downstream call into a shared-risk event. For NHI programmes, the issue is whether the credential is scoped to the caller or merely convenient for the server.

Token exchange is the identity translation layer MCP deployments were missing: MCP server authorization and backend authorization are different control points, and they should not be collapsed into one shared secret. By exchanging a user token for a backend-specific token, the system preserves user context while narrowing privilege to the downstream audience. Practitioners should treat that translation boundary as part of the identity model, not just an integration detail.

Least privilege was designed for stable actors, not broad shared identities: the assumption fails when a single server credential must represent different users, tools, and trust domains. In that condition, least privilege becomes impossible to express precisely because the backend sees only the shared credential, not the initiating subject. The implication is that governance has to move from credential-centric control to context-preserving token design.

Auditability depends on identity continuity across the call chain: if the MCP server authenticates one way and the backend sees an unrelated shared identity, the record of who acted is broken. That creates friction for access review, incident investigation, and tenant separation. The broader lesson is that MCP deployments need downstream identity translation as a first-class control, not an optional enhancement.

Identity-agnostic MCP servers are only safe when the gateway carries the governance burden: offloading authentication and token exchange to a control layer can simplify the server, but it also concentrates trust in the gateway. That means the programme must be able to explain, review, and revoke the translation path as clearly as any direct credential. Practitioners should govern the gateway as part of the identity perimeter, not a convenience proxy.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: MCP Security Guide

What this signals

Identity translation is becoming the real control point for MCP deployments: the security boundary is no longer just who can reach the server, but how that server proves the caller’s identity to every downstream dependency. If the backend token does not preserve the initiating subject, governance collapses into shared-account administration.

Shared-key MCP patterns will keep creating hidden NHI debt: the more teams embed long-lived secrets into tool-serving infrastructure, the more they accumulate revocation risk, audit gaps, and over-privilege. That is a familiar NHI pattern, but MCP makes it more visible because the same backend path may serve many different users and tenants.

Token exchange should be evaluated as part of the identity architecture, not just auth plumbing: the question for practitioners is whether their gateway can mint the right downstream credential without breaking user context. If it cannot, the programme still depends on static trust where dynamic trust is required.

For practitioners

• Separate server access from backend identity translation Design MCP so the token used to reach the MCP server is not reused as the token for downstream APIs. The backend call should always use a token minted for the correct audience, scope, and trust domain.
• Replace shared API keys with short-lived user-scoped tokens Move configuration out of embedded secrets and into time-limited tokens issued through an identity provider. Keep permissions minimal so one compromised token cannot stand in for the whole tool estate.
• Use federation when the backend sits in another trust domain When the MCP server and the target API do not share an identity provider, exchange the inbound token through an STS or federation service rather than minting a separate static credential.
• Treat the gateway as part of the identity control plane Review the component that validates inbound tokens and mints downstream credentials with the same care you would apply to any privileged identity broker. Its logs, policies, and revocation path should be governed explicitly.

Key takeaways

• Shared credentials in MCP deployments hide who actually acted and force downstream access to be broader than necessary.
• Token exchange and federation let the server call backend APIs with a token that matches the right user, audience, and trust domain.
• The practical control issue is identity translation across the call chain, not just authentication to the MCP server.

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.
• Identity Federation: Identity federation is the practice of trusting one identity system to authenticate a user or workload for another system. It reduces login friction, but it also creates a dependency on assertion trust, policy consistency, and strong control over downstream authorization.
• Shared Identity Context: Shared identity context is the ability for one control to use identity, entitlement, and relationship data produced by another control without manual reconciliation. It is the operational condition that turns a collection of tools into a coordinated identity programme.
• Downstream Identity Translation: The act of converting an inbound user or service identity into a backend-specific credential that preserves context and scope. It is the missing control when a server can authenticate to itself but cannot represent the caller correctly to the next service.

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.