MCP servers are becoming the identity plane for AI agents

At a glance

What this is: This analysis argues that MCP servers are becoming the identity plane for AI agents, and that weak or absent authorization on those servers turns every connected tool into a governance problem.

Why it matters: IAM, NHI, and agentic AI teams need to treat MCP as entitlement infrastructure because the server now mediates identity, scope, and call-time authorisation for agents.

By the numbers:

• A May 2026 measurement study of 7,973 live remote MCP servers found that 40.55% expose their tools with no authentication at all.
• More than 300 CVEs have been filed against MCP infrastructure to date.

👉 Read P0 Security's analysis of why MCP servers are becoming the identity plane for AI agents

Context

MCP started as a way for AI clients to discover and call tools, but in practice it is also deciding how agents are identified, what they can reach, and which credentials get reused across calls. That makes MCP an identity governance problem as much as a protocol problem, especially when servers expose tools without authentication or rely on static secrets.

The governance gap is that many deployments treat MCP as plumbing, while the server is actually mediating authorisation on behalf of the user. Once a server holds credentials and evaluates scopes, it behaves like identity infrastructure, and weak configuration turns every connected agent into a vehicle for privilege inheritance.

Key questions

Q: What breaks when MCP servers do not require authentication?

A: When MCP servers do not require authentication, the access boundary disappears. Attackers and scanners can enumerate tools directly, invoke exposed functions, and abuse those surfaces as if they were intended users. That turns an integration protocol into a public attack surface and makes later authorisation checks largely irrelevant.

Q: Why do unvetted MCP servers create more risk than normal integrations?

A: Unvetted MCP servers can inherit broad tool reach while hiding what data they read, what they transmit, and what decisions they influence. Unlike a conventional integration with clear boundaries, they sit inside an agent workflow that can browse, write, and act in sequence. That makes the risk cumulative, because one connection can expand the agent’s authority across multiple systems.

Q: What are the signs that an MCP authorization flow is failing in practice?

A: Common failure signals include mismatched redirect URIs, missing PKCE parameters, stale authorization codes, unsupported protocol versions, and tokens accepted without scope or audience checks. Another red flag is consent that is not logged or auditable. When these controls are weak, agents can gain access outside intended boundaries or create gaps in incident investigation.

Q: How should organisations govern MCP servers in identity programmes?

A: Organisations should inventory MCP servers like any other machine-facing access layer, then recertify exposed capabilities, remove unused tools, and keep state-changing actions tightly scoped. The goal is to reduce what an agent can even see as callable. That is a governance control, not just a software design preference.

Technical breakdown

Why MCP servers become an identity plane

MCP is designed to let clients discover tools and invoke them, but the server sits in the middle of each call and decides what scope is available. When the server uses user-bound OAuth with per-call evaluation, the identity path is explicit. When it uses a static key or loose session state, the server becomes the effective identity for every downstream tool call. That changes the control model from “who can connect” to “what identity is the server projecting on behalf of the caller.” In identity terms, the server is no longer just an integration layer; it is an authorisation broker with its own security posture.

Practical implication: Treat every MCP server as a governed resource server, not a convenience connector.

How authorization flaws turn tool access into privilege inheritance

Authorization flaws in MCP matter because the agent rarely talks directly to the target application. Instead, it inherits whatever the server already holds, and that can exceed or undercut the user’s own entitlements. This is a blended identity problem: the effective actor is a mix of user, agent, and server policy, not a clean handoff between fixed identities. If dynamic client registration is misconfigured or a token is too broadly scoped, the server can become a confused deputy that authorises actions the user never intended. That is why tool discovery without strict caller verification becomes a privilege multiplication layer.

Practical implication: Bind each tool invocation to the triggering user and validate scope at call time, not just at onboarding.

Why shadow MCP behaves like shadow IT with credentials attached

Shadow MCP is not just hidden software. It is hidden identity infrastructure because each server can carry its own credentials, scopes, and trust decisions. A local server installed beside an agent can create a direct credential path that bypasses central enforcement entirely. That means inventory, revocation, and lifecycle discipline are as important as protocol choice. The security failure is not simply unknown software on the network. It is unknown authority in the identity plane, where the agent inherits access from a server no one in governance approved.

Practical implication: Inventory every reachable MCP server and remove any server whose authority cannot be explicitly governed.

Threat narrative

Attacker objective: Use the MCP server as an identity intermediary to expand agent authority, expose data, and execute unauthorised tool actions.

1. Entry occurs when an AI agent connects to an MCP server that exposes tools without authentication or accepts weak OAuth configuration.
2. The server then projects its own credentials and scopes onto the agent, allowing privilege inheritance through mis-scoped authorization.
3. A compromised or malicious connected server can poison tool descriptions or expand effective access, leading to broader data exposure and unauthorized actions.
4. Impact is realised when the agent performs calls with the server’s inherited authority, extending access across multiple connected systems.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP servers are becoming a blended identity layer, not just a transport for tools. The protocol now decides who can call what, under which scopes, and with which credentials, so the server is functioning as an authorisation broker in the middle of agent activity. That means identity governance has to move from the agent alone to the server-agent boundary. Practitioners should treat each MCP server as part of the identity plane, not a sidecar to it.

Authorization defects in MCP are a governance failure, not a configuration nuisance. If every OAuth-enabled server in a measured sample shows flaws, the issue is not isolated misimplementation but a repeatable control pattern failure. The field is revealing that protocol optionality becomes operational ambiguity, and ambiguity is where entitlement drift starts. Identity teams should assume that loose server policy will be inherited by the agent unless the server is explicitly governed.

Blended identity is the right concept for MCP because the effective actor is a mix of user, agent, and server policy. A clean handoff model no longer describes what is happening when the middle layer supplies credentials, scopes, and call authorisation. This is the governance concept practitioners need to use when they evaluate MCP deployments: effective access may be narrower than the user’s rights, broader than the user’s rights, or simply different. Teams should stop asking whether the tool is connected and start asking which identity is actually acting.

Static keys inside MCP infrastructure create credential inheritance debt. The longer a server caches or reuses a key, the more its authorisation decisions outlive the caller, the session, and sometimes the project itself. That debt accumulates across every connected tool and becomes harder to unwind as agents multiply. Practitioners should assume that long-lived server credentials will turn into long-lived governance exceptions unless they are deliberately eliminated.

Shadow MCP exposes the same visibility problem as shadow IT, but with a direct entitlement consequence. An unsanctioned server does not merely widen the inventory. It creates a hidden policy layer that can mint, reuse, or project access without the central team ever seeing the transaction. The practical implication is simple: discovery and lifecycle controls are now identity controls for MCP, not just asset management tasks.

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.
• Read next: AI Agent Authorisation Guide

What this signals

Blended identity is the right lens for MCP governance because the effective actor is a mix of user, agent, and server policy. That makes call-time authorisation and scoped credential issuance more important than simple connector approval, and it pushes teams to review the middle layer as part of the identity plane rather than as plumbing.

The scale of the problem is already visible: according to the State of Secrets Sprawl 2026, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone. For practitioners, that means discovery and revocation are now identity controls for agent integrations, not optional hygiene.

For practitioners

• Govern MCP servers as identity infrastructure Classify each server as a resource server in your identity perimeter and require explicit ownership, scope, and review for any server that can authorise agent actions.
• Inventory every agent-reachable MCP server Build a live inventory of servers, connected agents, and exposed tools so that unsanctioned authority can be removed before it becomes embedded in workflows.
• Refuse static keys for production agents Require OAuth 2.1 with resource indicators and short-lived, caller-bound credentials instead of shared secrets that turn the server into the de-facto identity.
• Bind authorisation to the triggering user Evaluate each tool invocation against the user who initiated it and the exact server scope in force at call time, not against cached session state.
• Scope and revoke grants as NHI lifecycle items Treat each MCP grant as a non-human identity with joiner-mover-leaver style lifecycle controls, including expiry, revocation, and periodic recertification.

Key takeaways

• MCP is no longer just a tool-discovery layer. In practice, it is becoming the authorisation plane that governs what AI agents can do.
• Weak server-side controls matter because agents inherit the server's authority, not just the user's intent. That changes the control point from connection approval to call-time governance.
• Identity teams need inventory, scoped credentials, and lifecycle controls for MCP servers before agent deployment outpaces oversight.

Key terms

• MCP Server Identity Plane: The MCP server identity plane is the practical layer where an AI agent’s tool access is authenticated, scoped, and authorised. In this article’s context, the server is no longer just an integration endpoint. It is the policy-bearing middle layer that can expand or constrain what the agent can do.
• Blended Identity: Blended identity occurs when an autonomous system acts partly on behalf of a person and partly under its own machine authority. This creates split accountability because one actor may initiate the task while another identity performs the privileged action across different systems.
• Shadow MCP: Shadow MCP is an unauthorized or ungoverned use of the Model Context Protocol inside an organization. It appears when AI agents, scripts, or tools connect to data or actions through MCP servers without security review, inventory, policy control, or monitoring. This creates hidden access paths, data exposure, and weak accountability.
• Caller-Bound Credential: A short-lived credential issued for a specific caller and specific action, rather than reused across sessions or servers. For MCP, caller-bound credentials reduce privilege inheritance because the server cannot silently project standing access into every connected tool call.

What's in the full article

P0 Security's full article covers the operational detail this post intentionally leaves for the source:

• The full measurement-study breakdown behind the 7,973-server sample and the 40.55% unauthenticated figure
• Discussion of OAuth-enabled server flaws, including why the tested servers still failed security checks
• Examples of concrete MCP deployment patterns that turn the server into an identity issuer
• Recommendations for treating MCP servers as governed identity infrastructure in production

👉 P0 Security's full article covers the MCP authorization model, measurement findings, and deployment recommendations

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.