MCP for agent-to-agent comms may be the riskiest protocol you’ve never heard of





LOST IN TRANSLATION

MCP for agent-to-agent comms may be the riskiest protocol you’ve never heard of

Trust gaps in the new protocol spread malicious prompts from one agent to another.


Dan Goodin

–


|

9



AI Chatbot Assistants on Glass Blocks, Artificial Intelligence Technology Concept. Digitally generated image. 3d render.


Credit:

Getty Images


Credit:

Getty Images




Story text








The adoption of AI agents in millions of organizations is creating new opportunities for attackers to make them take malicious actions, such as exfiltrating database contents and sensitive business and personal information.

In the past five months, Google and four other organizations—with little in common except for their use of AI agents—have acknowledged vulnerabilities that exploit one agent inside a targeted network to spread harmful instructions to other internal agents. The technique is a special form of prompt injection that targets not the LLM but a particular agent, such as one for translation or data analysis. Guardrails inside such agents, if they exist at all, are often lax and will send the instructions to other agents down the chain. Because the latter agent explicitly trusts the first one, it follows the directions.

Unexpected and hard to mitigate

Independent researcher Syed Anas Mohiuddin tested agents from organizations including Google, JP Morgan Chase, Weviate, Rapid7, the French government’s interministerial digital directorate, and the US federal government. His proof-of-concept attacks exploit trust gaps in MCP, short for Model Context Protocol. The standard is one way AI apps and agents communicate with each other inside an internal network. The illustration below shows a simplified MCP in action.

Many special-purpose agents lack the guardrails that might normally mitigate the most harmful consequences of a prompt injection. And since MCP servers store credentials for each agent—and agents are built to trust every other internal agent—an exploit that would have been rejected by the LLM succeeds. In many cases, well-crafted prompts targeting the right agent will lead to a server-side request forgery, a vulnerability that causes a web server to make unauthorized network requests.

“AI agents give attackers a fresh set of connections to walk across,” Douglas McKee, director of vulnerability intelligence at Rapid7, told Ars. “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. Every piece in that chain did exactly what it was designed to do, which is what makes this so tricky to catch. 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.”

CVE-2026-97228, the vulnerability Mohiuddin found in Rapid7’s network, carried a severity rating of only 2.7 out of 10. Rapid7 fixed it last month.

The vulnerability affecting Google was more severe, with a rating of 8. It stemmed from an MCP toolbox for databases (googleapis/mcp-toolbox) initializing its HTTP client with no use of a CheckRedirect policy, a series of settings that control how a server is to handle cases of a URL either returning an error or redirecting to a different URL. Google’s HTTP client also failed to validate target IP addresses.

“A crafted path parameter could make the toolbox follow a redirect to an internal endpoint and send requests on the attacker’s behalf,” Mohiuddin explained. Google’s fix involved applying an allow-list of IP ranges and block lists. “It rejects an unsafe base URL at startup instead of on first request. That is what a real SSRF guard looks like. It is also more work than most MCP servers have done.”

Mohiuddin is calling the class of attack “protocol pivoting” because the exploits work when an app or server uses MCP to assign a task to an agent and the agent then forwards malicious instructions to another agent using a different communication method such as Google’s Agent-to-Agent (A2A) protocol, used for inter-agent delegation, or emerging standards such as the Agent Network Protocol. Often, he says, trust or authorization gets effectively lost in translation. He described protocol pivoting as “a multi-step attack in which an adversary gains initial access through one protocol, exploits trust assumptions between protocols, and escalates to capabilities only accessible via a different protocol.”

Markus Vervier, a researcher at X41 D-Sec who has also devised AI attacks that exploit MCP, said the better term remains “prompt injection” and that Mohiuddin’s technique is a simple subclass of that.

“For me this is indirect prompt injection,” he told Ars. “The fact that the malicious prompt can come from a different protocol (e.g., A2A) and manifests when used over another protocol is not strictly required for such attacks to work. It is, of course, unexpected and hard to mitigate in general.”

The fact that the pivoting technique worked across five organizations with nothing in common other than the use of MCP is notable. MCP is new and is already everywhere before it has been sufficiently tested and hardened. In organizations’ rush to build sprawling agentic architectures, they have abandoned a core security principle known as zero trust. Under that model, networks are built with the assumption that one or more nodes may be infected. To mitigate the effects, engineers must design nodes to require authorization before conducting sensitive transactions with other ones.

“The lesson I’d want people to take away is that anything passed from an LLM to your tool should be treated like input from a stranger on the internet, because in a prompt injection scenario that’s exactly what it is,” McKee said. The bugs underneath are old friends like injection and SSRF, and the fixes haven’t changed in 20 years. Credit to the researcher for putting a name on it, because a name is what gets defenders and standards bodies to actually design for it.”

Photo of Dan Goodin


Dan Goodin

Senior Security Editor
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82.


9 Comments

Leer artículo original en Ars Technica