Topic starter
20/08/2026 5:28 pm
TL;DR: Static API keys and shared service accounts break user-level attribution and least-privilege in MCP deployments, while token exchange and federation let backend calls inherit the right identity context across trust domains, according to Stacklok. For practitioners, the real shift is that MCP authorization must be paired with downstream identity translation, because shared credentials hide who acted and widen blast radius.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Beyond API keys: Token exchange, identity federation, and MCP”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
Bottom line: Shared credentials in MCP deployments hide who actually acted and force downstream access to be broader than necessary.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:16 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server identity should move from shared keys to token exchange