MCP server identity should move from shared keys to token exchange

At a glance

What this is: This is a Stacklok analysis of why MCP server identity should move away from static credentials toward short-lived token exchange and federation.

Why it matters: It matters because IAM, NHI, and PAM teams need identity context to survive across tool calls, clouds, and trust domains if they want auditability and least privilege to hold.

👉 Read Stacklok's analysis of token exchange, federation, and MCP identity

Context

MCP server identity is the control point that determines whether backend calls are made under a shared credential or under a user-scoped, traceable identity. The problem with static credentials is not just rotation overhead. It is that one long-lived secret can collapse attribution, least privilege, and tenant isolation across every downstream request.

For NHI and IAM programmes, this is a governance problem as much as an integration problem. If the server can authenticate to tools but cannot translate identity correctly across trust boundaries, then the access model is still effectively shared and over-broad, even when the front door looks modern.

Key questions

Q: How should security teams handle identity in MCP servers that call backend tools on behalf of users?

A: They should preserve user context end to end by using short-lived tokens, token exchange, or federation instead of shared service credentials. That lets the backend see a scoped identity tied to the originating user, which improves attribution, reduces blast radius, and makes access reviews meaningful.

Q: Why do shared service accounts create problems in MCP deployments?

A: Shared service accounts make the backend see one identity for many users, so attribution disappears and privilege usually expands to make the account usable everywhere. That pattern turns a convenience shortcut into a governance gap. It also creates a high-value credential that can be reused across tasks and backend systems.

Q: What breaks when API keys are used as the main MCP credential?

A: Persistent API keys create a standing secret that can outlive the task, the session, and sometimes the user who triggered it. If that key is copied, logged, or reused, the server has no built-in way to distinguish legitimate use from abuse. Short-lived credentials reduce that exposure window.

Q: How do token exchange and federation help with least privilege in AI toolchains?

A: They let the system mint a backend token that is narrower than the original session and valid only for the intended audience. That means the front-end login can remain user-friendly while the backend still receives only the permissions required for the specific call.

Technical breakdown

Why shared MCP identities break auditability and scope control

A shared identity turns many user actions into one backend principal, which makes audit logs less useful and makes entitlement review almost meaningless. In MCP deployments, that pattern often appears as a service-account JSON key or a long-lived API key embedded in configuration. The result is a single credential with broad permissions that must serve every request, every tenant, and every user context. That is not just a secrets problem. It is an identity translation failure where the backend can no longer distinguish who initiated the action.

Practical implication: replace shared backend identities with per-user or per-session identity context before tool calls reach downstream services.

How token exchange preserves identity across trust domains

Token exchange lets one token be swapped for another that is valid for a different audience, scope, or trust domain. In practice, an MCP server can accept a user token from an Identity Provider, then exchange it for a backend-scoped token that matches the downstream service. RFC 8693 defines the exchange model, and the important governance point is that the backend token can carry narrower permissions than the front-end session. That preserves least privilege without forcing a second login or hardcoding backend secrets.

Practical implication: design MCP integrations so downstream access is mediated by short-lived exchanged tokens, not by static credentials.

Why federation is the right model across IdPs and clouds

Federation extends token exchange when the MCP server and the backend resource do not share the same identity domain. Instead of issuing duplicate credentials or asking the user to authenticate twice, the system uses a trust relationship between domains to mint a valid identity in the target environment. That makes the architecture more portable across clouds and IdPs, but it also increases governance demands: trust configuration, audience mapping, and issuer validation all become part of the access path. Without that discipline, federation becomes another way to spread credentials across environments.

Practical implication: govern federation as an identity control plane, with explicit trust mappings and validation rules for every backend domain.

NHI Mgmt Group analysis

Shared backend identity is the wrong governance primitive for MCP servers. The article is pointing at a structural failure in modern backend access: one credential being reused across many users, tools, and tenants. That pattern destroys attribution and makes least privilege impossible to enforce meaningfully. In NHI terms, the problem is not just secret sprawl, it is identity collapse under load. Practitioners should treat shared credentials in MCP as an anti-pattern, not a convenience.

Token exchange is the governance bridge between user identity and machine execution. It preserves the user context while allowing the backend to receive a token suited to its own audience and scope. That matters because downstream services should not need to trust the original session shape; they should trust a translated identity with the narrowest viable permissions. This aligns with OWASP-NHI and zero trust thinking: credentials must be both short-lived and context-specific.

Federation becomes unavoidable once MCP servers cross trust domains. The article shows that the real design challenge is not authentication at the edge, but identity continuity across identity domains. When the backend lives in another cloud or another IdP ecosystem, governance shifts from credential storage to trust orchestration. That means IAM teams, NHI owners, and cloud architects need one shared policy model for issuer, audience, and token scope.

Identity translation is the missing control in many AI-agent toolchains. MCP servers are often discussed as tooling infrastructure, but the more important issue is whether the identity presented to the backend still reflects the actor that initiated the request. If it does not, access review, forensics, and policy enforcement all degrade. The field should stop treating auth as a wrapper around MCP and start treating it as a first-class part of the architecture.

From our research:

• 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to the 2024 Non-Human Identity Security Report.
• 59.8% of organisations see value in dynamic ephemeral credentials, a sign that short-lived identity patterns are becoming an operational expectation rather than an edge case.
• For a broader breach lens, 52 NHI Breaches Analysis shows how exposed credentials and weak lifecycle controls turn identity design flaws into real incidents.

What this signals

Token exchange is becoming the practical bridge between IAM policy and machine-to-machine execution. As AI agents and MCP servers spread across cloud and on-prem systems, identity programmes will need a clean handoff from user authentication to backend authorisation. That makes federated trust mappings, token audience controls, and session-level attribution part of core IAM engineering rather than optional integration detail.

With 35.6% of organisations already struggling to manage consistent access across hybrid and multi-cloud environments, the governance problem is now architectural, not operational. Teams that still treat backend credentials as implementation shortcuts will keep paying for that choice in audit gaps, broader blast radius, and fragmented accountability.

Identity translation debt: When a server can call many services but cannot preserve the initiating identity, the organisation accumulates a hidden governance liability. The fix is not just better secrets handling. It is a consistent model for who the backend believes is acting, across every trust boundary and every cloud.

For practitioners

• Eliminate shared backend credentials for MCP services Inventory every MCP server and tooling path that still relies on a service-account key or long-lived API key. Replace shared identities with user-scoped or session-scoped tokens so downstream actions can be attributed to the originating principal.
• Map every MCP backend to a specific token audience Define the expected issuer, audience, and scope for each downstream service before you wire up token exchange. If the backend cannot validate those claims cleanly, the trust boundary is not ready for production use.
• Treat federation trust as a governed asset Document every cross-domain trust relationship, including which IdP or STS mints the token, what claims are required, and which downstream APIs accept it. Re-certify those mappings when cloud, IdP, or tenant boundaries change.
• Keep MCP servers auth-agnostic by design Move login, token issuance, and backend token acquisition out of application code and into the identity layer. That reduces hardcoded secret handling and makes it easier to apply one policy path across multiple backend services.
• Review audit logs for identity continuity gaps Check whether backend events still show the original user identity after token exchange or federation. If logs only show a shared service principal, your audit trail is too coarse for incident response or access certification.

Key takeaways

• MCP server security fails when one shared identity stands in for many users, because attribution and least privilege disappear together.
• Token exchange and federation restore identity continuity across trust boundaries, which is the real requirement for governed AI tool use.
• IAM and NHI teams should treat backend identity translation as a first-class design decision, not a late-stage integration detail.

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 asset: A shared identity asset is any credential store, account, or access structure used by more than one person or team and therefore requiring explicit ownership. These assets need lifecycle control because membership changes, delegation, and offboarding can otherwise leave access active beyond its intended purpose.

What's in the full article

Stacklok's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step token exchange flow for same-IdP deployments, including the claim changes between front-end and backend tokens.
• A second pattern for cross-domain federation, with the trust-service sequence used when the downstream service sits in another cloud or IdP.
• Concrete token examples showing how issuer, audience, scope, and subject differ across the MCP and backend layers.
• ToolHive deployment details for containerised MCP servers, including where policy enforcement and backend token acquisition sit in the request path.

👉 The full Stacklok post covers the exchange flow, federation pattern, and ToolHive request path in more operational detail.

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 or identity security programme, it is worth exploring.