AI Agents: Your MCP Vulnerability Explained

The MCP vulnerability is here, and if you're deploying AI agents, you need to pay attention. Millions of organizations are rushing to integrate AI agents, creating a brand-new playground for attackers. We're talking about malicious instructions spreading like wildfire between agents inside your network, potentially exfiltrating database contents and sensitive business or personal information. This isn't theoretical. In just the past five months, Google and four other major organizations have acknowledged this exact exploit.

Here's the deal: this isn't your garden-variety prompt injection targeting a large language model. This is a special form that zeroes in on a specific agent, like one for translation or data analysis. And the real kicker? Those agents often lack proper guardrails. They'll just pass those harmful instructions down the chain to other internal agents. And because that second agent explicitly trusts the first, it dutifully executes the malicious command. Every piece in that chain did exactly what it was designed to do.

Your Agents Are Talking, But Are They Secure?

Let's be clear: the communication standard driving this issue is called Model Context Protocol, or MCP. It's how your AI apps and agents chat with each other within your internal network. Independent researcher Syed Anas Mohiuddin got under the hood, testing agents from major players including Google, JP Morgan Chase, Weviate, Rapid7, the French government’s interministerial digital directorate, and the US federal government. His proof-of-concept attacks exploited critical trust gaps in MCP.

Here's what happens. Many specialized agents lack guardrails. That's a problem. Since MCP servers store credentials for each agent, and agents are built to trust every other internal agent, an exploit that a standalone LLM might reject sails right through anyway. Often, a well-crafted prompt aimed at the right agent leads to a server-side request forgery (SSRF), which is a nasty vulnerability that forces a web server to make unauthorized network requests on behalf of the attacker. And we've seen how bad that gets.

AI agents give attackers a fresh set of connections to walk across. That's how Douglas McKee, director of vulnerability intelligence at Rapid7, explained it. Someone plants text in content, an agent will read it then pass it along to another agent as a normal delegated task, and that second agent runs it because it trusts whoever handed it the work. Each protocol was built assuming it lived on its own. So each one checks its own front door while nobody watches the hallway in between.

The Mechanics of "Protocol Pivoting"

Syed Anas Mohiuddin coined the term "protocol pivoting" for this class of attack. It’s a multi-step process where an adversary gains initial access through one protocol, then exploits the trust assumptions between protocols. This allows them to escalate to capabilities that are normally only accessible via a different communication method. Imagine an app using MCP to assign a task, and that agent then forwards malicious instructions to another agent using something like Google’s Agent-to-Agent (A2A) protocol. Authorization gets lost in translation.

Markus Vervier, a researcher at X41 D-Sec who has also developed AI attacks exploiting MCP, describes it as a subclass of prompt injection. He calls it "indirect prompt injection." The core issue remains the malicious prompt, regardless of whether it originates from a different protocol. The key is its unexpected and difficult-to-mitigate nature.

Who's Been Hit and How They're Fixing It

This isn't theoretical. It's happening now. The fact that this pivoting technique worked across five organizations with little in common beyond using MCP is a glaring red flag. MCP is new, it's everywhere, and it hasn't been hardened enough.

• Rapid7: Syed found CVE-2026-97228 in Rapid7's network. It had a severity rating of 2.7 out of 10. Rapid7 patched it last month.
• Google: Their vulnerability was more severe, clocking in at an 8 out of 10. It stemmed from a specific MCP toolbox for databases (googleapis/mcp-toolbox). This toolbox initialized its HTTP client without a CheckRedirect policy and failed to validate target IP addresses. This meant a manipulated path parameter could trick the toolbox into following a redirect to an internal endpoint, sending requests on an attacker’s behalf.

Google fixed its own MCP vulnerability. How? With an allow-list of IP ranges and block lists. And they made sure their system rejects an unsafe base URL at startup, rather than waiting until the first request arrives, which is a small detail but one that changes how the whole defense holds up under pressure. This is what a strong SSRF guard looks like. It's a level of diligence many other MCP servers haven't yet adopted.

“A crafted path parameter could make the toolbox follow a redirect to an internal endpoint and send requests on the attacker’s behalf,” Syed explained, detailing the Google exploit.

Your Core Security Principle Is Under Attack

So, what does this mean for your daily workflow? If you're wondering whether this matters, it does. Here's why. In the rush to build sprawling agentic architectures, many organizations have inadvertently abandoned a core security principle, zero trust, which assumes that at least one node in your network is already compromised and requires engineers to design nodes that demand explicit authorization before conducting sensitive transactions with any other node. But with MCP's implicit trust, that model collapses. It's gone.

This isn't about inventing new, exotic security threats. The underlying bugs are old friends like injection and SSRF. The fixes for these types of vulnerabilities haven't changed in twenty years. The context has, though. Now these familiar flaws are showing up in the new, interconnected network of AI agents.

Treat anything an LLM passes to your tool like input from a stranger on the Internet. That's McKee's point. In a prompt injection scenario, that's exactly what it is. And credit goes to the researcher for putting a name on it, because, as McKee emphasized, a name is what gets defenders and standards bodies to actually design for it, which is why the lesson he'd want people to take away matters so much.

Let me be blunt. You need to treat input from your "trusted" internal AI agents with the same skepticism you'd apply to data coming from an unknown external source, because that's exactly the kind of scrutiny it deserves. The Model Context Protocol is powerful. But its implicit trust model is a gaping hole. Until you implement rigorous authentication and validation at every agent-to-agent interaction, your internal networks remain wide open to sophisticated, hard-to-detect attacks.