When Anthropic introduced the Model Context Protocol in late 2024, the pitch was simple: give AI models one standard way to plug into tools, files, databases, and APIs, instead of building a custom integration for every system. The comparison to USB-C stuck because it captured something real. Just as USB-C let one port charge a laptop, transfer files, and drive a monitor, MCP let a single AI agent read a codebase, query a database, and send an email through the same protocol.
Adoption followed fast. Within about eighteen months, MCP servers were showing up across the majority of cloud environments researchers scanned, and thousands of public MCP packages had racked up well over a hundred million downloads combined. But that same speed is now the problem. Security researchers, government agencies, and independent labs have spent 2026 documenting a steady stream of vulnerabilities tied not to sloppy coding in any one product, but to gaps in how the protocol itself handles trust. At the center of nearly every one of these findings is a single unresolved question: how does an AI agent prove who it is, and what it’s actually allowed to do?
What Makes MCP Different From Earlier Integration Standards
Traditional APIs are built around a request-response model: a client asks, a server answers. MCP flips part of that relationship. An MCP server can hand an AI agent a list of tools it’s permitted to call, and in some configurations, the server can also request that the client’s model generate text or take action on its behalf. That inversion opens paths that don’t exist in most conventional client-server systems, and auditors have noted that the protocol was released with a flexible, underspecified design that prioritized developer freedom over safety guardrails.
The result is a protocol that standardizes how a model discovers and calls a tool, but says very little about who is calling, which server should be trusted, or what permissions should follow once a connection is made. That gap has turned out to matter far more than early adopters expected.
The Core Security Gap: Identity Was Never Built In
MCP’s authorization specification does define an OAuth-based framework, but it explicitly leaves authorization as optional rather than mandatory. In practice, that has meant a large share of deployed servers run with weak or no authentication at all. One scan of more than 500 live MCP servers found that over a third had no authentication mechanism whatsoever, and a separate internet-wide scan turned up well over a thousand publicly reachable servers responding to unauthenticated requests.
This is where the concept of AI agent identity becomes central to the whole discussion. In a traditional enterprise system, a user logs in, gets a session, and every action they take is tied back to that verified identity. MCP was not built around an equivalent guarantee. A server has no reliable way to attest who it is to a connecting client, and a client often has no reliable way to confirm that the tool description it’s reading hasn’t been altered since it was last reviewed. Without a durable AI agent identity anchoring each connection, permissions become a matter of implicit trust rather than verified authorization, and implicit trust is exactly what attackers have learned to exploit.
How Attackers Are Exploiting the Gap
Researchers and incident responders tracking MCP-related breaches through early 2026 have converged on a handful of recurring attack patterns:
- Command injection over STDIO — several MCP SDKs pass configuration strings directly into system commands without sanitization, which has led to dozens of confirmed CVEs across Python, TypeScript, Java, and Rust implementations.
- Tool description poisoning — malicious or compromised servers alter the text a model reads when deciding which tool to call, quietly steering the agent toward unintended or harmful actions.
- Rogue server registration — weak session binding and the absence of server attestation let an attacker’s server pose as a trusted one, particularly in registries with limited vetting.
- Supply-chain drift — a package that behaves safely at install time later ships an update that silently changes its behavior, such as forwarding data to an external address, without triggering any new review.
- Sampling abuse — a feature that lets servers request completions from the client’s own model can be repurposed to drain compute, hijack a conversation, or trigger hidden tool calls the user never approved.
A cross-registry study analyzing more than 67,000 published MCP servers found widespread conditions enabling exactly this kind of hijacking and metadata manipulation, underscoring that these aren’t isolated incidents but a structural pattern across the ecosystem.
Why AI Agent Identity Is Harder Than It Sounds
Solving this isn’t as simple as bolting on a login screen. An AI agent often needs to act across multiple systems in a single task — reading a file, querying an API, and writing to a database in sequence — and each hop is a place where identity can get lost or spoofed. Unlike a human user, an agent’s “intent” is generated dynamically from a prompt and whatever context it has absorbed, which means a compromised tool description can effectively impersonate legitimate instructions without ever stealing a credential.
Security teams that have looked closely at this problem generally agree on a few requirements for meaningful AI agent identity: a verifiable identity for each server and client involved in a session, cryptographic attestation of tool descriptions so a model can detect if one has changed since it was reviewed, and scoped, revocable permissions tied to that identity rather than blanket access granted at connection time. None of these are exotic ideas — they mirror how zero-trust architecture already works for human users and services — but MCP’s early design didn’t require them, and retrofitting a fast-growing ecosystem is much harder than building the guardrails in from the start.
What Responsible Adoption Looks Like
Organizations already running MCP in production are converging on a similar playbook: treat every MCP server as an untrusted third party by default, block public internet exposure of servers that don’t need it, sandbox execution so a compromised tool can’t reach the broader system, and monitor tool invocations for behavior that deviates from an established baseline rather than relying only on static, one-time reviews. None of this replaces protocol-level fixes, but it substantially narrows the window an attacker has to work with while the standard itself matures.
What We’ve Learned
MCP solved a real integration problem, and the comparison to USB-C is fair on that count. But USB-C didn’t have to worry about the device on the other end lying about what it was — MCP does, and its early design didn’t build in a reliable way to check. The vulnerabilities disclosed throughout 2026 aren’t a sign that MCP is fundamentally broken; they’re a sign that the protocol grew faster than its trust model did. Until verified AI agent identity becomes a default part of every MCP connection rather than an optional add-on, the responsibility for closing that gap sits with the teams deploying it — and the size of the ecosystem means that responsibility isn’t going away anytime soon.
