MCP Security: Protocol Pivoting and the Agent Trust Gap

Text planted on an internal wiki page waited until a translation agent read it as work. Call it what it is: an mcp security failure, not a model failure. The translation agent then delegated the request to a data-analysis agent over the Model Context Protocol, because that is how internal agents hand off work. The data-analysis agent executed it with its own stored credentials, because it trusts every agent on the network. Each hop behaved exactly as designed, and the chain ended with an internal database answering a request from an attacker. Call it what it is: an mcp security failure, not a model failure.

That is the shape of the vulnerability class Ars Technica reported on 6 October, after five organizations acknowledged, across five months, vulnerabilities that let one compromised internal agent spread malicious instructions to the others. The shared substrate was MCP, the protocol many enterprises now use for agent-to-agent communication. The shared mistake was older: agents built to trust each other by default.

Five organizations, one trust gap

Independent researcher Syed Anas Mohiuddin built proof-of-concept attacks against agents at Google, JP Morgan Chase, Weviate, Rapid7, the French government's interministerial digital directorate and US federal agencies. His injections did not target the LLM. They targeted the specialist agent, the translation or data-analysis worker whose guardrails are thinner than the model's, and whose delegated instructions the next agent accepts without question.

• CVE-2026-97228 (Rapid7, CVSS 2.7). A low-severity server-side request forgery that became a cross-agent instruction path once the agent chain was in play. Rapid7 patched it in September 2026.
• The Google case (severity 8). The googleapis/mcp-toolbox database server initialized its HTTP client without a redirect policy and without validating target IP addresses, so a crafted path parameter could make the server follow a redirect to an internal endpoint and issue requests on the attacker's behalf.
• The fix worth copying. Google now applies an IP-range allowlist and rejects unsafe base URLs at startup rather than on first request. In the researcher's words, that is what a real SSRF guard looks like, and it is more work than most MCP servers have done.
• The naming dispute. X41 D-Sec researcher Markus Vervier reads the technique as indirect prompt injection rather than a new class. The label matters less than the mechanics: either way the payload travels on inter-agent trust.

What protocol pivoting actually is

Syed named the class protocol pivoting: a multi-step attack in which the adversary gains initial access through one protocol, exploits trust assumptions between protocols, and escalates to capabilities only reachable through a second one. An MCP task becomes an A2A delegation or an Agent Network Protocol call, and authorization gets lost in translation between the two.

Three implementation details make it work at scale. MCP servers store credentials for each connected agent, so the second agent in a chain acts with its own authority rather than the first agent's. Special-purpose agents carry few of the guardrails that sit in front of the LLM. And enterprise agent fleets assume internal traffic is trustworthy, which is the zero-trust principle quietly dropped when agentic architectures sprawled.

Douglas McKee, Rapid7's director of vulnerability intelligence, put the failure in one sentence: every protocol checks its own front door while nobody watches the hallway between them. The bugs underneath are injection and SSRF, and the fixes have not changed in twenty years.

How large the hallway has become

Google's Threat Intelligence Group tracked 2,076 vulnerabilities in AI-related software between January 2025 and August 2026, more than 1,500 of them disclosed this year. Half of 2026's disclosures affect agent orchestration frameworks, where attackers reach code-execution nodes through prompt injection or crafted workflow definitions. The serving layer, vLLM, Ollama and LiteLLM, logged 212 disclosures in 2026, and nearly a quarter of those came from unauthenticated endpoints or SSRF. Every one of those endpoints is a door an agent chain can be pointed at.

None of this is hypothetical for teams already running agents. The seam taxonomy in our AI agent sandbox escape report puts the same failure one layer down: containment breaks where one component trusts another component's output. Protocol pivoting is that seam with a delegation protocol attached.

Closing the hallway: seven changes

• Treat agent output as stranger input. Anything an LLM hands your tools is untrusted by definition, because in an injection scenario that is exactly what it is. Validate it at the tool boundary, not the model boundary.
• Give every server-side HTTP client a redirect policy and an IP allowlist, checked at startup. The Google mcp-toolbox fix is the reference implementation: reject unsafe base URLs before the first request, not during it.
• Scope credentials to the task, not the agent. If the analysis agent holds a database token that only the reporting job needs, the pivot arrives pre-authorized.
• Require authorization on agent-to-agent calls. Zero trust assumes any node may be compromised, so a delegation that skips re-authorization is a hallway with no door.
• Inventory egress before you inventory agents. SSRF and exfiltration both need somewhere to go. A per-run outbound allowlist turns most pivots into dead ends, which is the argument for keeping agent runs off the public internet.
• Segment agents like tenants. One microVM per run means a pivoted agent inherits that machine's credentials and nothing else; running AI coding agents safely in isolated environments is the runbook for it.
• Log delegations, not just actions. The attack is a chain, so an audit trail that records only terminal actions cannot show which agent handed work to which.

Krova's contribution is the floor under those rules: each agent run gets a Firecracker microVM with its own kernel and no public IP, so the credential blast radius of a pivoted agent is one disposable machine. The protocol work still has to be done above it; our MCP connection guide covers the tooling side, including October's MCP Python SDK credential flaw.

Two documents are worth reading before your next architecture review: the NSA's MCP security guidance and Syed's own protocol pivoting write-up.

FAQ

Is protocol pivoting a new vulnerability class? The mechanics are old: indirect prompt injection carried over delegation channels, ending in SSRF or credential use. The new part is scale. MCP gives the injection a credential store and a trust graph to travel on.

Does dropping MCP remove the risk? No. The same pivots appeared over A2A and custom delegation paths. The trust assumption is the flaw, not the protocol; MCP is simply where most enterprises parked their agent credentials.

What is the highest-value fix this week? Startup validation of base URLs and target IPs on every server-side HTTP client an agent can influence, plus an egress allowlist per run. Both are cheap and neither requires re-architecting the fleet.