Between late 2024 and early 2025, independent researcher Syed Anas Mohiuddin discovered vulnerabilities in AI agent deployments at Google, JP Morgan Chase, Weviate, Rapid7, France's interministerial digital directorate, and the US federal government. The common issue? All these organizations used the Model Context Protocol (MCP) for agent communication and failed to consider how trust assumptions between agents could create exploitable attack paths.
What Happened
Mohiuddin demonstrated an attack method called "protocol pivoting." An attacker embeds malicious instructions in content processed by one AI agent. This agent, often a specialized tool like a translation or data analysis service, lacks strong security measures and forwards the instructions to another agent using a different protocol. The receiving agent, trusting the sender because they operate within the same network, executes the harmful instructions without additional checks.
This technique exploits trust gaps in MCP, a standard for AI agent communication rapidly adopted across enterprise networks. The attacks resulted in server-side request forgery (SSRF) vulnerabilities, enabling unauthorized network requests, database content exfiltration, and access to sensitive information.
Timeline
The timeline highlights how quickly MCP spread without adequate security testing:
- Late 2024: Mohiuddin begins testing MCP implementations across multiple organizations.
- January 2025: Rapid7 acknowledges CVE-2026-97228 (severity rating: 2.7/10) and patches the vulnerability.
- February 2025: Google addresses a more severe vulnerability (severity rating: 8.0/10) in its googleapis/mcp-toolbox by implementing IP range allow-lists and block lists.
The rapid adoption of MCP, without thorough adversarial testing, left organizations vulnerable.
Which Controls Failed or Were Missing
Three specific failures enabled these exploits:
1. Specialized agents lacked input validation
Translation agents, data analysis agents, and other specialized tools processed external content without treating it as untrusted input. They forwarded instructions to other agents without sanitization.
2. MCP servers stored credentials without per-transaction authorization
Agents accessed stored credentials to communicate with other agents. No authorization check occurred at the point of use, only at initial setup.
3. HTTP clients failed to validate redirect targets
Google's MCP toolbox initialized its HTTP client without a CheckRedirect policy and didn't validate target IP addresses. This allowed crafted path parameters to redirect requests to internal endpoints.
Douglas McKee, director of vulnerability intelligence at Rapid7, noted, "AI agents give attackers a fresh set of connections to walk across. 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."
What the Relevant Standard Requires
No current standard directly addresses MCP security, which is part of the problem. However, existing frameworks define controls that should have prevented these exploits:
ISO/IEC 42001 (AI Management System) requires organizations to identify and assess risks throughout the AI system lifecycle (Clause 6.1). Protocol security falls under this requirement. If you're deploying agent-to-agent communication, your risk assessment must account for trust boundaries between agents.
NIST AI RMF calls for adversarial testing of AI systems (GOVERN 1.5 and MAP 3.3). The framework's emphasis on "secure and resilient" design applies to communication protocols, not just model architectures.
SR 11-7 establishes that any component affecting system outcomes requires independent validation. That includes communication protocols. Section III requires ongoing monitoring and outcome analysis, which would have caught agents making unauthorized network requests.
ISO/IEC 27001 Annex A.13.1 requires network controls that segment access based on authorization requirements. Allowing any internal agent to task any other internal agent violates this control.
Organizations treated MCP as a plumbing standard, not a security boundary. They validated the LLM's guardrails but didn't validate the protocol layer where agents hand off tasks to each other.
Lessons and Action Items for Your Team
Stop treating internal agent communication as a trusted zone
If your architecture assumes that any agent inside your network can safely task any other agent, you've built an expressway for lateral movement. Implement authorization checks at the point of each inter-agent transaction, not just at initial connection setup.
Validate all inputs to specialized agents
Your translation agent, your data analysis agent, your SQL query agent: each one must treat incoming content as untrusted input. Apply the same input validation you'd use for a public-facing API. This means sanitizing prompts, validating parameters, and checking for injection patterns before forwarding instructions.
Implement HTTP client safeguards in every MCP server
Google's fix provides the template. Configure CheckRedirect policies that validate target IP addresses against allow-lists. Reject unsafe base URLs at startup, not on first request. Block internal IP ranges unless explicitly authorized.
Map your agent trust graph
Document which agents can task which other agents, what credentials each agent holds, and what network resources each can access. If you can't draw this map, you can't secure it. Use the map to identify high-risk paths where a compromised agent could pivot to sensitive resources.
Test your agents with adversarial prompts
Don't wait for a researcher to find your vulnerabilities. Craft prompts that attempt to make Agent A instruct Agent B to access unauthorized resources. Test whether your authorization checks actually fire when one agent tasks another.
Require protocol-level authorization, not just connection-level
MCP servers that store credentials for batch operations must still validate authorization for each individual request. Connection-time authentication isn't sufficient when agents can delegate tasks to each other.
The protocol pivoting technique worked across six organizations because they all made the same architectural assumption: internal agents form a trusted collective. That assumption is now disproven. Your agent architecture needs authorization boundaries between agents, not just between your network and the outside world.
