Microsoft
released a patch on March 10, 2026, for CVE-2026-26118, a server-side request forgery (SSRF) vulnerability in the Azure MCP Server. The vulnerability allows an authorized attacker to increase their network privilege. An attacker can exploit this because the MCP server can be manipulated into making outbound requests that contain its managed identity token. If an attacker captures this token, they will gain access to all the permissions that the server's identity can reach.
This is not a one-time bug. The Model Context Protocol (MCP), used by Microsoft, Google, Amazon, and many other frameworks for AI agents, was developed to create a standardized way for agents to communicate with external tools and data. It is now the connective tissue of the agentic enterprise. And it ships with no authentication enabled by default.
Adversa AI reported this month that nearly 38% of the 500-plus MCP servers it scanned lack authentication.
Knostic's previous research identified 1,862 MCP servers that are accessible over the Internet with no identity governance controls in place. The industry has responded to this by treating this as a problem of protocol maturity: better specifications, more OAuth, gateway products. However, that misses the mark. MCP's security flaw is not a protocol flaw — it is an identity flaw.
The identity that disappears at the MCP boundary
In a typical MCP interaction, a human user asks an AI agent to perform some activity. To accomplish this task, the agent will connect to an MCP server to access a tool or data source. At that time, the human user's identity disappears. The MCP server recognizes a request coming from an authenticated agent using a static API key or service account. It does not recognize the human user's identity or understand what the human user authorized the agent to do or the scope of that authority.
This is the same basic pattern behind
the Google Antigravity incident in December 2025, where an agent deleted a user's entire D: drive while clearing out a cache, and
the Replit incident, where an agent deleted a production database that it determined was obsolete. In both cases, the agent technically had the authorization to take the action. What was missing was the link between the agent's actions and the human who authorized them. MCP makes this problem structural: each server interface creates a trust boundary, and the human identity is dropped.
What building this taught me
When I built multi-agent systems serving hundreds of thousands of users, our agents initially authenticated with downstream services using dedicated service accounts. While we were able to investigate why an agent was behaving unexpectedly, we could not identify which user caused the action or whether the agent's actions aligned with the user's intentions.
To solve this, we propagated the initiating user's identity throughout each agent action. Each time the agent communicated with another system or resource, it would carry the original user's claims. The user's session scope was enforced for each task. Each action taken by an agent is tied back to a specific human, session, and context. This traceability is what governance really needs. MCP, as it is currently deployed, breaks the traceability chain at each server boundary.
Three changes before your next MCP deployment
First, implement OAuth On-Behalf-Of flows for every MCP server connection. Microsoft's ISE team has
published a production-ready implementation of OAuth 2.1 and OBO flows.
MuleSoft's Agent Fabric includes identity propagation, ensuring that each hop carries the user's claims. The technology is already available. The real question is whether your team is using it.
Second, treat the discovery of MCP servers as an identity governance problem.
Noma Security's research indicates that more than 90% of organizations deploy MCP servers with default configurations that allow all tools to be used, including potentially destructive ones. If your security team cannot provide an inventory of every MCP server, the identities those servers use, and the tools they expose, then you have an unmanaged attack surface that grows every time a developer spins up a new agent.
Third, log the reasoning chain alongside the identity chain. When an attacker captures a managed identity token via SSRF, you should want to know not just which identity was compromised, but also what the agent was attempting to do at the time the token was compromised.
Gartner predicts that by 2028, 25 percent of enterprise breaches will involve AI agents. These breaches will not occur due to advanced prompt injection attacks. They will occur for the most obvious reason: an agent used credentials that nobody could trace back to a human. A gateway without identity propagation is essentially a firewall for traffic that has already lost its most important metadata: who asked for this?
