TL;DR: MCP server authentication breaks the old shared-secret pattern by treating the server, the caller, and the downstream resource as distinct identities, with sender-constrained tokens and per-tool scopes, according to Scramble ID. That shift turns MCP into an IAM problem, not just an integration pattern: without it, prompt injection and token leakage become high-leverage control failures.
At a glance
What this is: This is an analysis of MCP server authentication that argues for three distinct identities in the path, not one shared key, and shows why scope-per-tool and sender-constrained tokens matter.
Why it matters: IAM and NHI teams need to treat MCP as a governance boundary because shared secrets at the agent-tool layer create the same breach conditions seen in traditional service-account sprawl.
Context
MCP server authentication is the control point between AI agents and the tools they call. The core governance problem is simple: if the server, the caller, and the downstream resource are treated as one identity, least privilege and attribution break down at the point where agentic systems are most likely to concentrate access.
In practice, early MCP deployments often fall back to a single shared API key. That turns the broker into a high-value shared-secret target, with the same leakage, replay, and revocation problems that have long affected non-human identity programmes.
The article's central claim is that MCP should be governed as a three-identity path, with separate authentication for the server, the caller, and the backend resource. That is the typical failure mode when teams try to shortcut identity design for convenience.
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 sender-constrained tokens matter for MCP caller authentication?
A: They bind the token to the client that obtained it, which makes replay from another device or runtime much harder. That matters in MCP because agents can run in ephemeral environments where bearer tokens are easy to copy. Sender-constrained tokens narrow the abuse window and preserve the value of short-lived access.
Q: How should security teams govern MCP tool access in enterprise environments?
A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.
Q: How do security teams know whether MCP authorization is actually working?
A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently. If a server accepts session-only state, relayed tokens, or vague consent prompts, authorization is functioning as a convenience layer rather than a control.
Technical breakdown
Why a shared MCP API key collapses authorization boundaries
A shared key makes every caller look identical to the MCP server, which means the broker cannot distinguish one agent from another or restrict actions by tool. Once a key is reused across callers, scope becomes coarse, revocation becomes all-or-nothing, and forensic attribution disappears. The result is structurally similar to the worst service-account patterns in NHI security: a leaked secret inherits every permission the broker exposes. In agentic systems, that is more dangerous because tool invocation is frequent and often state-changing.
Practical implication: replace shared broker keys with caller-specific credentials and per-tool authorization scopes.
How sender-constrained tokens change MCP authentication
Sender-constrained authentication binds the token to the client that requested it, usually with mTLS or DPoP, so a stolen token cannot simply be replayed elsewhere. In an MCP flow, that matters because agents may run in distributed or ephemeral environments where bearer-token exposure is otherwise easy. Short-lived tokens plus audience binding narrow the replay window, while JWT client assertions let the authorization server verify the caller's cryptographic identity before issuing access. That moves trust from static secrets to proof-of-possession.
Practical implication: require proof-of-possession for MCP callers so stolen tokens do not become reusable broker credentials.
Why scope-per-tool is the real control plane for MCP
The important unit is not the MCP server as a whole but each tool it exposes. A read-only tool, a write tool, and an irreversible action should not share the same permission boundary, because prompt injection and tool misuse exploit broad scopes first. Per-tool scoping turns the broker into a policy enforcement point where the token's scope is evaluated before the tool is invoked. That creates a hard authorization boundary that the model's reasoning cannot override, which is exactly what agentic systems need when language and intent are easy to manipulate.
Practical implication: map each MCP tool to a distinct scope and require approval for high-impact actions.
Threat narrative
Attacker objective: The attacker aims to reuse one exposed broker credential to call any MCP tool, reach downstream resources, and erase attribution.
- Entry occurs when an MCP server is exposed behind a single shared API key that every agent uses to authenticate to the broker.
- Credential exposure follows when that key is committed to code, logged, stored in environment files, or copied across runtimes.
- Escalation happens because the stolen key inherits every tool and every backend resource the MCP server can reach.
- Impact is broad tool misuse, weak attribution, and the ability to invoke brokered actions from any runtime on the internet.
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
Three-identity MCP authentication is the correct governance model for agentic tool access. The server, the caller, and the downstream resource are different trust decisions, and collapsing them into one shared key creates a false sense of simplicity. That broken assumption is the real problem: a broker can only enforce least privilege if it knows which identity is acting at each hop. Practitioners should treat MCP registration, caller authorization, and downstream access as separate control points.
Shared-secret authentication at the MCP layer recreates the NHI breach pattern in a new place. The article describes the same failure mode security teams already know from service accounts: one leaked secret grants broad, unattributable access. What changes here is the velocity of abuse, because agents and tools generate far more frequent authorization events than human operators do. The governance lesson is that convenience at the broker boundary scales breach impact faster than it scales integration.
Scope-per-tool is the named concept that should replace server-level permission thinking. A server-level scope is too coarse once an MCP endpoint brokers reads, writes, and irreversible actions. Tool-level scopes force policy to match actual risk, and they make prompt injection materially less useful because the model cannot invent permissions it was never issued. IAM teams should stop treating MCP as a generic API and start treating each tool as a distinct authorization surface.
Audit attribution must become end-to-end, not server-only. If the agent, the MCP server, and the backend resource are not all captured in the audit chain, incident response loses the ability to reconstruct who asked for what and who executed it. That is especially important when token exchange preserves original caller identity across hops. The practical standard is simple: no tool invocation should reach production without identity, scope, and resource attribution at every layer.
Hardware-bound credentials matter because MCP is another NHI control plane, not a special-case protocol. The article's architecture only works if the private keys stay in protected storage and the tokens are short-lived, audience-bound, and sender-constrained. That is a governance problem as much as a technical one: if the agent runtime cannot be trusted to hold secrets safely, the organisation has merely moved the shared-secret risk into a new wrapper. The implication for practitioners is to govern MCP like any other high-value NHI estate.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Scope-per-tool is the governance shift that matters most. MCP only becomes manageable when teams stop thinking in terms of one server permission and start thinking in terms of per-tool authorization. That changes access design from broad broker trust to explicit task-scoped permissions, which is the right pattern for irreversible actions in agentic systems.
Identity attribution has to follow the full delegation path. When an agent calls an MCP server and that server calls a backend API, the audit chain must preserve both identities or incident response will flatten the whole sequence into a single opaque event. This is where token exchange, resource binding, and signed audit events become governance controls rather than implementation details.
For practitioners
- Treat each MCP tool as a separate authorization surface Define scopes per tool, not per server, and require state-changing or irreversible actions to use explicit high-risk scopes rather than broad broker access.
- Replace shared broker keys with proof-of-possession credentials Use sender-constrained tokens with mTLS or DPoP so a stolen token cannot be replayed from another runtime or agent instance.
- Register MCP servers as first-class non-human identities Maintain an owner, a signed tool catalog, and lifecycle recertification for each server so stale brokers can be found and revoked.
- Preserve end-to-end attribution across the agent-server-resource path Log agent identity, MCP server identity, tool name, scope used, and downstream resource call in one audit chain for every invocation.
- Harden the agent runtime that holds private keys Use hardware-backed storage or equivalent isolation for agent credentials and keep token lifetimes short enough that replay windows stay narrow.
Key takeaways
- A shared MCP key turns one broker credential into a single point of failure for every caller, tool, and backend resource.
- The article's stronger architecture separates the agent, the MCP server, and the downstream resource into distinct identities with distinct scopes.
- For practitioners, the control question is no longer whether MCP works, but whether each tool invocation is both attributable and constrained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on replacing shared-key MCP authentication with distinct cryptographic identities. |
| NHI-05 — Overprivileged NHI | Server-level permissions are too coarse for tool brokers that expose read, write, and irreversible actions. | |
| NHI-07 — Long-Lived Secrets | Shared API keys and bearer tokens create the replay and leakage window the article warns against. | |
| Recommendation — Replace shared MCP secrets with distinct, sender-constrained authentication for each identity in the path. Scope each MCP tool separately so no caller inherits broader access than the task requires. Shorten credential lifetime and eliminate reusable secrets from MCP caller authentication. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is fundamentally about credential issuance, rotation, binding, and revocation. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | MCP callers and downstream services are non-human identities authenticating machine-to-machine. | |
| Recommendation — Manage MCP authenticators so each caller credential is unique, short-lived, and revocable. Apply non-organizational identity authentication controls to agents, brokers, and backend services. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Per-tool scopes and downstream delegation are the article's central authorization concern. |
| Recommendation — Enforce tool-level entitlements and verify that MCP access matches the intended resource scope. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Leaked broker credentials enable access reuse and movement from the MCP surface to backend resources. |
| Recommendation — Map MCP credential leaks to credential access and lateral movement detections in your monitoring pipeline. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Sender-constrained token: A sender-constrained token is tied to a specific client or cryptographic proof, rather than being usable by anyone who steals it. This reduces replay risk and is especially important where tokens can reach automation, services, or agents with broad API access.
- Scope-per-tool: A policy model that assigns separate permissions to each tool exposed by an MCP server rather than granting access to the whole broker. It turns least privilege into a tool-level decision, which matters when read, write, and irreversible actions coexist behind the same protocol endpoint.
- Audit Attribution: The ability to prove who requested an action, which actor executed it, and what resource was affected. In AI agent governance, attribution must be richer than a single username because accountability breaks when the human and the agent share one visible identity.
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.
Published by the NHIMG editorial team on June 22, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org