MCP server authentication needs three identities, not one shared key

At a glance

What this is: This is a technical explanation of how MCP server authentication should work, and the key finding is that shared API keys create the same breach pattern that has long plagued service accounts.

Why it matters: It matters because AI agent, NHI, and IAM programmes all need to govern the tool-broker layer with cryptographic identity, scoped authorisation, and audit attribution before shared-secret sprawl becomes the default.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.

👉 Read Scramble ID's analysis of MCP server authentication and tool-scoped identity

Context

MCP server authentication is the problem of proving who is allowed to call a tool broker, what they may do, and how each action is attributed across the agent, the server, and the downstream resource. The source article argues that treating the broker as a first-class cryptographic identity is the only way to avoid collapsing every caller into one shared secret.

For IAM and NHI teams, the issue is not the protocol label but the governance pattern. A single API key for every agent reproduces the same failure mode seen in service-account breaches: no sender constraint, no granular revocation, and no reliable audit trail when the key leaks.

The article’s primary keyword, MCP server authentication, sits at the centre of a broader identity-control shift. Tool access is moving from integration convenience to delegated execution, and that means authentication, scope, and attribution have to be designed together from the start.

Key questions

Q: How should security teams govern MCP servers that broker AI agent tool access?

A: Treat each MCP server as a first-class non-human identity with its own keys, owner, registration record, and revocation path. Then give callers short-lived sender-constrained tokens and map each tool to a separate scope. That combination keeps tool access bounded, supports attribution, and prevents a leaked credential from becoming a universal broker key.

Q: Why do shared API keys create such high risk for MCP servers?

A: Because one leaked key grants every caller the same authority across every tool the server exposes. There is no caller distinction, no sender constraint, and no meaningful revocation granularity. In practice, a single compromise can reach multiple downstream systems, and investigators will struggle to determine which agent actually made the call.

Q: What breaks when MCP access is scoped at the server instead of the tool?

A: Server-level scope collapses very different actions into one permission bucket, so read-only use and irreversible writes are governed the same way. That makes prompt injection and tool misuse more dangerous because the caller can reach any function the broker exposes. Tool-level scoping is the control that restores least privilege.

Q: Who should be accountable when an AI agent uses an MCP server to access data?

A: Accountability should follow the full delegation chain, not just the broker or the backend. The audit trail needs the agent identity, the MCP server identity, the scope used, and the downstream resource outcome. Without that traceability, recertification, investigations, and separation of duties all degrade into proxy-account ambiguity.

Technical breakdown

Why shared API keys fail at the MCP server boundary

A shared API key turns the MCP server into a single trust bucket. Every caller inherits the same authority, so a leak in logs, source control, environment files, or a developer laptop becomes a full-broker compromise. The server cannot distinguish one agent from another, which destroys attribution and makes least privilege impossible. In practice, the authentication layer becomes a concealed standing privilege pool, and the blast radius matches every tool the broker exposes. This is the same structural weakness that made shared service-account credentials so dangerous in machine identity programmes.

Practical implication: replace shared keys with per-caller identities before the MCP server is allowed into production.

How sender-constrained tokens and scope-per-tool change authorisation

The hardened pattern uses short-lived access tokens bound to the caller’s cryptographic proof, such as mTLS or DPoP, and each tool is mapped to its own OAuth scope. That means the agent can only invoke the tool class it was explicitly granted, and a stolen token cannot be replayed from another runtime without the proof-of-possession material. Scope-per-tool matters because MCP servers often broker many tools under one endpoint, so server-level access is too coarse for state-changing actions. The model also supports audience binding, which prevents token reuse across different brokers.

Practical implication: design scopes around tool function and risk level, not around the server name.

Why end-to-end audit attribution is part of authentication

In MCP, authentication is incomplete unless the audit trail preserves identity across the full agent-server-resource path. The article’s three-layer model records who requested the token, which MCP server accepted it, and what downstream resource executed the action. That closes a common forensic gap in delegated automation, where a broker can otherwise obscure the original caller. Token exchange is especially important in high-trust flows because it carries the original subject and the acting server through to the backend API, which preserves accountability without collapsing identities into one proxy account.

Practical implication: require audit events that retain agent identity, server identity, scope used, and downstream resource outcome.

Threat narrative

Attacker objective: Use one leaked credential to turn the MCP server into a broad, unattributable control point for tool abuse and downstream access.

1. entry: An attacker or careless operator obtains a shared MCP API key from code, logs, or an exposed configuration file.
2. escalation: The same key authorises every tool on the broker, so the actor gains broad access without needing to defeat per-tool controls.
3. impact: The broker can be used to reach downstream APIs and data sources with no reliable attribution, making exfiltration and destructive actions hard to unwind.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared-secret authentication is the wrong mental model for MCP. MCP servers are brokers, not passive APIs, and that makes them high-leverage identity intermediaries. When every agent uses the same key, the broker inherits the weakest properties of service-account passwords: no caller separation, no revocation granularity, and no defensible attribution. Practitioners should treat the pattern as an NHI control failure, not an integration detail.

Tool-level scope is the governing unit, not the server. A server can expose dozens of tools with very different risk profiles, from read-only lookups to irreversible writes. Server-wide access turns prompt injection into a privilege-amplification problem because the agent cannot be trusted to self-limit once it holds broad broker access. The implication is that tool granularity becomes the policy boundary IAM teams must reason about.

End-to-end attribution is becoming a non-negotiable identity requirement for agentic systems. If a backend cannot see both the MCP server and the original agent context, accountability collapses into a proxy pattern that is familiar from poor service-account governance. That weakens investigations, recertification, and separation of duties. Practitioners should assume the audit model will be judged on whether it can reconstruct the delegation chain.

MCP server authentication is where prompt injection meets identity governance. Scope-bound authorisation does not eliminate malicious prompting, but it prevents a compromised reasoning loop from creating new access on demand. That is the control distinction IAM teams should preserve: content manipulation is a threat, but unauthorized tool execution is an identity failure. The implication is that MCP security belongs in NHI governance, not only in application security.

Scope-per-tool is the named concept this category needs. The article shows that the real failure mode is not authentication alone, but coarse authority at the broker boundary. Scope-per-tool is the practical expression of least privilege for AI tool use, and without it the MCP layer becomes a standing-privilege multiplier. Practitioners should treat the concept as the design baseline for agent tool access.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why teams should also compare agent controls against the OWASP Agentic Applications Top 10 when designing broker authentication and scope boundaries.

What this signals

Scope-per-tool is likely to become the minimum viable control for any MCP deployment that reaches production. As agent fleets grow, server-level permissions will look increasingly crude beside tool-specific authorisation, especially where write actions or downstream APIs are involved.

The operational signal to watch is whether identity teams can trace each tool invocation back to a specific agent, server, and scope without relying on application logs. If they cannot, MCP has already outgrown the governance model supporting it, even if the integration still works.

As AI adoption increases, broker authentication will converge with workload identity and PAM thinking. Organisations that already align their controls to the Ultimate Guide to NHIs , Key Challenges and Risks will find it easier to absorb MCP without creating a parallel secret-management problem.

For practitioners

• Register MCP servers as first-class non-human identities Give each server its own asymmetric key pair, explicit owner, and registration record in the identity provider so it can be governed like any other workload identity.
• Replace shared keys with sender-constrained caller tokens Issue short-lived tokens bound to mTLS or DPoP proof and reject bearer-style reuse so a stolen token cannot be replayed from another runtime.
• Map every tool to a distinct OAuth scope Separate read, write, and irreversible actions into different scopes so the broker enforces tool-level least privilege instead of server-level access.
• Require audit events that preserve the delegation chain Log the agent identity, MCP server identity, scope used, downstream resource, and result in one trace so investigations can reconstruct who did what through the broker.

Key takeaways

• MCP server authentication is an identity problem, not just an integration problem, because the broker sits on the critical path between agents and downstream systems.
• Shared API keys recreate the same standing-credential failure mode that has long driven NHI breaches, only now at the agent-tool boundary.
• Tool-level scopes, sender-constrained tokens, and end-to-end audit attribution are the controls that turn MCP from a broad trust bucket into governable delegated access.

Key terms

• MCP Server Identity: The cryptographic identity assigned to a Model Context Protocol server so it can be governed as a distinct non-human identity. It includes keys, ownership, registration metadata, and auditability. This prevents the broker from becoming an anonymous shared trust point that hides who actually mediated access.
• Sender-constrained Token: An access token that is bound to proof held by the original caller, such as mTLS or DPoP, so it cannot be replayed from another runtime. In MCP deployments, this prevents stolen bearer tokens from functioning as universal access passes and narrows the value of credential theft.
• 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.
• Token Exchange: An OAuth pattern that lets one identity swap its token for another token while preserving subject and actor context. In MCP architectures, it allows the server to call downstream APIs without erasing which agent initiated the action, which is essential for accountability and downstream policy enforcement.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Scramble ID: What Is MCP Server Authentication? Read the original.