AI Agent ‘Protocol Pivots’ Create New Attack Paths Across MCP and A2A Systems

AI agents can create hidden attack paths when they pass instructions and delegated tasks between different protocols, security researchers warn. Attackers may be able to exploit the trust between agents even when each individual system appears to protect its own interface.

How AI Agent Protocol Pivots Work

“AI agents give attackers a new set of connections to walk across,” Douglas McKee, director of vulnerability intelligence at Rapid7, told Ars. “Someone embeds text in content, an agent reads it, and passes it to another agent as a normal delegated task. The second agent will do it because it trusts the person who handed it off.

“Every part in that chain is doing exactly what it was designed to do, which is why it’s so hard to capture. Each protocol is built to exist on its own, so each one checks its own front door while no one else watches the hallways between them.”

Mohiuddin calls this class of attacks “protocol pivots.” The exploit works when an application or server uses the Model Context Protocol (MCP) to assign tasks to agents, and an agent forwards malicious instructions to another agent through a different communication method.

Examples include Google’s Agent-to-Agent Delegation (A2A) protocol, which is used for delegation between agents, and emerging standards such as Agent Network Protocol. According to Mohiuddin, trust and approval can be effectively lost in translation between protocols.

He described a protocol pivot as “a multi-stage attack in which an attacker gains initial access through one protocol, exploits trust assumptions between protocols, and escalates to functionality that can only be accessed through another protocol.”

Rapid7 Vulnerability Received a Low Severity Rating

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

Google MCP Toolbox Vulnerability Rated 8 Out of 10

The vulnerability affecting Google was more severe, with a rating of 8. It was caused by the MCP Toolbox for Databases (googleapis/mcp-toolbox) initializing its HTTP client without using the CheckRedirect policy.

The policy is a set of settings that controls how the server handles URLs that return an error or redirect to another URL. Google’s HTTP client also failed to verify the target IP address.

“A crafted path parameter could allow the toolbox to follow a redirect to an internal endpoint and send requests on behalf of the attacker,” Mohiuddin said and explained.

Google’s fix included applying IP range allowlists and blocklists. “Reject insecure base URLs at startup rather than on the first request. This is what SSRF Guard looks like in practice. It’s also more work than what most MCP servers have been doing.”