MCP servers are becoming the identity plane for AI agents

At a glance

What this is: This analysis argues that MCP servers are now acting as identity issuers for AI agents, with authorization defects and credential inheritance creating a new control plane risk.

Why it matters: It matters because IAM, PAM, and NHI programmes must decide who authorises tool calls, whose identity is evaluated, and whether MCP servers are governed like production APIs or shadow infrastructure.

By the numbers:

• A May 2026 study of 7,973 live remote MCP servers found that 40.55% expose their tools with no authentication at all.
• 300 CVEs have been filed against MCP infrastructure, astructure to date.
• Only 47.1% of deployed AI agents were actively monitored or secured in a February 2026 survey of 900-plus enterprise respondents.
• In that same survey, 88% of organisations reported a confirmed or suspected agent incident in the prior twelve months.

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

Context

Model Context Protocol is meant to let AI clients discover and call tools, but the article shows that many deployments are already treating MCP servers as the place where identity is asserted, scoped, and authorised. That makes the server itself part of the trust boundary, because the agent does not simply call a tool, it inherits whatever credential and policy model the server enforces.

For IAM and NHI programmes, the important shift is that the middle layer is no longer neutral plumbing. Each MCP server can become a credential-bearing control point, which means static keys, weak caller verification, and unaudited server installations create governance problems that look more like shadow IT with authorization logic than conventional application integration. See the Ultimate Guide to NHIs for the broader governance model around service accounts, tokens, and lifecycle control.

The article’s central warning is that optional protocol primitives are not enough when the deployed reality defaults to long-lived secrets and inconsistent authorisation. That is a familiar NHI pattern: the control exists in theory, but the operational environment normalises inheritance, reuse, and weak scoping until the effective identity becomes whatever the last server decided it should be.

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 MCP servers create new authorization risks compared with traditional OAuth flows?

A: MCP changes the model because agents discover tools dynamically and may request capabilities after initial login. Traditional consent assumes a fixed set of scopes chosen up front by a human. In MCP, authorization has to handle per-tool decisions, dynamic consent, and identities that travel with each tool call, or the server ends up granting broader access than intended.

Q: How can organisations tell whether MCP access is actually being governed?

A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.

Q: What is the difference between agent access and server access in MCP?

A: Agent access is the capability the AI system appears to have, while server access is the credential and policy layer that actually governs each tool call. In MCP, the server often decides what the agent can do in practice, which is why teams must manage the server as an identity control point rather than assuming the agent’s own permissions tell the full story.

Technical breakdown

Why MCP servers become identity issuers

An MCP server does more than expose tools. It defines which tools exist, which scopes they require, and which caller identities are accepted, so the server becomes a resource server in the practical identity sense. When the server uses user-bound OAuth tokens and evaluates each call, identity flows through a defined boundary. When it uses a static key or shared secret, the server’s credential becomes the de facto identity for every request routed through it. That is why MCP changes the identity model rather than simply adding another integration layer.

Practical implication: Treat each MCP server as an identity control point and require per-server authorization, not shared secrets.

Blended identity and the confused deputy problem

The article’s “blended identity” idea describes what happens when the effective actor behind a tool call is a mix of user, agent, and session rather than a clean handoff. That creates a classic confused deputy condition: the server acts with its own authority while believing it is acting on behalf of the user, and the backend accepts the request because the caller looks privileged. In practice, this means the trust decision is being made one layer away from the real human or workflow intent, which weakens accountability and scope control.

Practical implication: Bind authorization to the initiating user and invocation context, not to cached server session state.

Shadow MCP turns visibility gaps into credential exposure

Shadow MCP is not just undiscovered tooling. It is undiscovered credential-bearing infrastructure that defines scopes, authorises calls, and extends the agent’s access without security review. A local server next to a developer’s agent can bypass the normal enforcement boundary because the boundary was never created. Once that pattern spreads, the effective access of the agent becomes the union of every connected server and its misconfigurations, which is exactly how NHI sprawl turns into governance loss.

Practical implication: Inventory every reachable MCP server and revoke or isolate any server that cannot prove its credential model.

Threat narrative

Attacker objective: The attacker wants to turn the MCP server into an unauthorized identity broker that expands an agent’s effective access and enables tool misuse or data exposure.

1. Entry occurs when an agent connects to an MCP server that exposes tools without authentication or uses a weakly scoped credential model.
2. Escalation follows when the server’s identity becomes the de facto authority for tool calls, allowing the agent to inherit broader access than the user intended.
3. Impact is the misuse of tool access, credential inheritance, or poisoned tool descriptions to reach data, systems, or actions outside approved scope.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• United Nations Breach — Ethical hackers discover United Nations systems exposed via GitLab credential misconfiguration.

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

NHI Mgmt Group analysis

MCP servers are now non-human identity infrastructure, not just integration plumbing. When a server holds credentials, defines scopes, and authorises tool calls, it is operating inside the identity perimeter whether teams acknowledge it or not. That makes MCP governance a direct extension of NHI governance, because the control question is no longer only what the agent can do, but which server is allowed to speak for it. Practitioners should classify every MCP server as a governed identity-bearing resource.

Blended identity is the right term for the control failure here. The article shows that the effective actor behind an MCP call is neither only the user nor only the agent nor only the session. That matters because least privilege is hard to enforce when the authorisation subject is unstable, and unstable identity is exactly what many MCP deployments create by design. The implication is that entitlement models built for clean handoffs do not hold at the point of tool invocation.

Static credentials in MCP are a standing privilege problem disguised as an AI problem. The article repeatedly points to long-lived secrets, shared keys, and inherited authority as the actual failure modes. That is familiar NHI territory: if a server can be copied, installed, or chained without lifecycle control, then its access lives longer than its trust basis. Practitioners should treat every static MCP secret as potential standing access across the agent ecosystem.

Shadow MCP expands the attack surface faster than policy can catch up. The operational issue is not only that some servers are unauthenticated, but that unsanctioned servers can introduce their own scopes, their own credentials, and their own call paths outside review. That makes discovery and offboarding as important as authorization design. The field should expect MCP governance to converge with workload identity governance, where inventory, scope, and revocation are the core controls.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why shadow MCP risk is a governance problem as much as a technical one.
• For a broader control model, see 52 NHI Breaches Analysis, which shows how identity gaps turn into repeatable compromise patterns.

What this signals

Blended identity is the operational problem that most current IAM programmes are not designed to observe. Once an MCP server starts speaking for an agent, the effective subject of the call is no longer stable enough for old-style entitlement assumptions. Teams that already struggle with service-account inventory will find that agent-connected servers create the same visibility problem at a faster cadence, especially when the server holds the credential boundary.

The practical next step is to fold MCP into the same governance processes used for workload identity and privileged access. That means discovery, ownership, scope review, revocation, and exception handling all need to apply to servers that mediate agent action, not just to the agents themselves. For control design, the OWASP Top 10 for Agentic Applications 2026 is the right external anchor for tool misuse and identity abuse patterns.

Identity control point: the server sitting between the agent and the resource is where authorisation now happens, and that is where policy must attach. If that layer is not inventoried, owned, and revocable, the agent’s apparent permissions are largely meaningless. The governance signal is simple: if you cannot prove who can install a server, what it can call, and when its grants expire, you do not have controlled delegation.

For practitioners

• Inventory every MCP server as an identity-bearing resource Build a register of all remote and local MCP servers reachable from agents, including the credential type they hold, the scopes they request, and the business owner responsible for them.
• Replace static keys with per-call authorization Refuse shared API keys for production agent paths and require OAuth 2.1 or equivalent scoped credentials that are evaluated at invocation time, not cached for the life of a session.
• Bind access decisions to the initiating user and context Ensure the authorization check uses the real user or workflow trigger, not the first server that authenticated successfully, so delegated calls cannot inherit broader authority than intended.
• Gate destructive tool actions at the argument level Approve what the agent is about to pass to the tool, not just whether the tool itself is allowed, because tool descriptions are not policy and can be manipulated.
• Apply lifecycle control to agent grants Treat MCP-related OAuth grants like other non-human identities and revoke them when the project, connector, or server is no longer sanctioned.

Key takeaways

• MCP servers are functioning as identity brokers for AI agents, which means their authorization model is now a security control, not a convenience feature.
• The most visible failure pattern is credential inheritance through static or weakly scoped server access, which expands agent privilege beyond intended boundaries.
• Practitioners should govern MCP with NHI discipline: inventory, ownership, scoped credentials, per-call checks, and lifecycle revocation.

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 Authorization: Caller-bound authorization means the server evaluates each request against the identity that actually initiated the action, not against a cached session or previous approval. For MCP, this is the difference between a controlled tool call and a delegated access path that can drift beyond its original intent.

What's in the full article

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

• Measurement methodology behind the 7,973-server study and the authorisation flaws it found
• The specific MCP implementation patterns that produced auth gaps, including dynamic client registration issues
• Examples of exploit paths and protocol weaknesses described by the vendor
• The recommended server-side controls and deployment patterns in more implementation detail

👉 P0 Security's full post covers the measurement study, auth flaws, and MCP control recommendations in more detail.

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