Notifications
Clear all
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.
NHIMG editorial — based on content published by Stacklok: Beyond API keys: token exchange, identity federation, and MCP
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Stacklok's analysis of token exchange, federation, and MCP identity →
MCP server identity and token exchange: what should teams change?
Explore further
20/08/2026 6:16 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server identity should move from shared keys to token exchange
