Protocol pivoting: when MCP trust leaks into another agent protocol

Most MCP security advice looks at one hop: an AI tool calls an MCP server, and the server should not trust what it is given. A line of research published this year argues that the bigger risk sits between protocols. When an agent that uses MCP hands work to another agent over a different protocol, the second agent often trusts the first completely, and an instruction planted in ordinary content can travel the whole chain. The researcher behind the work calls this "protocol pivoting". Whether or not the name sticks, it describes a gap that teams building multi-agent systems should map now.

Where the term comes from

The idea is set out in two documents by the same author, Syed Anas Mohiuddin.

The first is a preprint on Zenodo, published on 24 May 2026. It observes that agent deployments now run several protocols side by side: MCP for tool access, Google's Agent-to-Agent (A2A) protocol for delegation between agents, and newer proposals such as the Agent Network Protocol. Each, it argues, was designed with a security model "that assumes it operates alone". It defines protocol pivoting as an attack that gains access through one protocol, exploits trust assumptions between protocols, and escalates to capabilities only reachable through another. It describes three scenarios: escalation from MCP into A2A through implicit trust delegation, capability injection from A2A into MCP by impersonating an agent, and prompt injection chains where context from one protocol changes behaviour in another.

The second is an individual IETF Internet-Draft, published in June 2026 and expiring on 3 December 2026. It is informational and, like every draft, a work in progress rather than a standard. Most of it covers known MCP server weaknesses: server-side request forgery (SSRF), over-broad file access, prompt injection through tool results, tools answering before the initialisation handshake, verbose errors and missing authentication. Its section on protocol pivoting lays out a four-step chain:

1. An injected instruction enters content that an MCP-using agent processes.
2. The instruction makes the agent call an MCP tool against an internal service.
3. The agent delegates a task to a downstream agent, which inherits the originating agent's trust.
4. The downstream agent negotiates with an external service under the originating agent's identity.

The draft's conclusion is short: mitigations that consider each protocol in isolation do not address movement across protocol boundaries, and it flags this as an area for further analysis rather than offering a full answer.

The bugs underneath are familiar

Protocol pivoting does not need new kinds of vulnerability. It chains old ones. Two recent advisories show the building blocks, and why severity scores alone can mislead.

Google MCP Toolbox for Databases. The GitHub advisory GHSA-3x3x-8ffg-ghcv, published on 31 July 2026 as CVE-2026-14540, describes SSRF in the generic HTTP source and tool of mcp-toolbox versions 0.3.0 through 1.4.0. The HTTP client had no restrictive redirect policy and no validation of target IP addresses, so "a malicious data-driven prompt" could make the toolbox follow a redirect to internal or arbitrary endpoints. The advisory rates it high. Note that the scores differ by version of the scoring system: CVSS 4.0 gives 8.0 (high), while CVSS 3.1 gives 6.1 (medium), according to OpenCVE. The fix itself is covered in MCP servers keep trusting the wrong URLs.

Rapid7 Bulk Export MCP. The Rapid7 entry for CVE-2026-97228, published on 25 September 2026, describes GraphQL query injection in versions 0.2.5 through 0.6.1, fixed in 0.6.2. An unvalidated export_id argument was pasted into a query string. It scores CVSS 3.1 2.7, low, because every injected query runs within the operator's own authenticated scope and cannot cross a tenant boundary. Rapid7 is candid about the realistic exposure: "a compromised or careless upstream MCP client, or indirect prompt injection forwarding an unvalidated identifier".

That last phrase is the pattern in miniature. The MCP server itself was not the entry point. Something upstream forwarded a value it should not have trusted, and the server trusted it in turn.

Analysis: what is new and what is not

It is a form of indirect prompt injection. A fair objection to the new name is that the attack starts, like most agent attacks, with instructions hidden in content the model reads. That is true, and the defences against injection still apply. What the protocol pivoting framing adds is attention to where authority comes from at each step. A downstream agent that accepts a delegated task usually does not ask who originally asked for it, or why. It sees a trusted peer.

Per-protocol security is necessary but not enough. MCP has an authorisation model; A2A has its own; each can be configured well. The gap is that the identity and intent of the original request are rarely carried across the boundary and checked again. The second agent's credentials, not the first user's permissions, decide what happens next.

Low scores can hide chain risk. A CVSS 2.7 bug that only lets a caller do what it could already do looks harmless in isolation. In a chain where the "caller" is an agent acting on injected instructions, the question changes from "can an attacker gain access?" to "can an attacker borrow access the agent already has?". Severity scoring is not designed to answer the second question.

The research is early. The paper is a preprint and the draft is an individual submission. Neither is peer-reviewed guidance or an adopted standard. They are best read as a clear statement of a design problem, not as a finished control set.

What it means for engineering and security leaders

If your teams are building agents that call tools and also delegate to other agents, whether over A2A, a message queue or a custom API, the trust boundaries are probably not drawn anywhere. Each component team secures its own interface. Nobody owns the path between them.

Three questions help:

• Whose authority does each hop use? If a delegated agent acts with its own broad service account, an injected instruction in the first agent can use that account.
• Does the original purpose travel with the request? If the downstream agent cannot see why it was asked, it cannot refuse a request that does not fit.
• Is every boundary crossing recorded? Investigating a chain needs a record at each hop, linked by something more than timestamps.

Practical takeaways

• Draw the agent graph: every agent, every protocol it speaks, and every credential it holds. Mark where one agent can cause another to act.
• Treat messages from peer agents as untrusted input, the same as web content or tool results.
• Give each agent its own narrowly scoped identity, and avoid shared service accounts across agents.
• Pass the original caller and purpose along with delegated tasks, and re-check authorisation at each hop rather than inheriting it.
• Apply the draft's server advice to your own MCP servers: validate resolved IP addresses at connection time, do not follow redirects by default, and refuse tool calls before initialisation completes.
• Do not drop low-severity agent bugs from the backlog without asking how they behave in a chain.

Where SpanDock fits

For the MCP part of the chain, the SpanDock MCP gateway, on the Premium and Enterprise plans, gives every computer's AI tools one MCP server and has your server check who is calling, apply permissions, rules and guardrails, and only then call the connector. Every connector starts read-only for everyone, and every call is recorded with the person, computer, tool and outcome. It covers MCP calls, not delegation between agents over other protocols, which still needs its own controls. For wider context, see what NIST is saying about AI agent security and the MCP 2026-07-28 specification changes.