Protocol Pivoting Is a Trust Boundary Failure

Oct 10, 2026 5 min read

The dangerous part of an MCP server is not always the model that calls it.

It can be the quiet assumption that an argument arriving from another agent is already trustworthy.

In an October report from Ars Technica, researcher Syed Anas Mohiuddin describes a class of attacks he calls protocol pivoting. The alleged path is simple: malicious text reaches one agent, that agent forwards instructions through an internal protocol, and a second agent performs an action because it trusts the first one.

The underlying bugs are familiar. Server-side request forgery, missing authorization, unsafe redirects, and injection into downstream queries. The new part is the hallway between agents, where each component trusts the previous component and nobody owns the end-to-end boundary.

The pattern is bigger than one bug

Mohiuddin’s October follow-up says that five separate organizations independently confirmed and fixed SSRF issues in MCP systems: Google, JPMorgan Chase, Weaviate, France’s interministerial digital directorate, and the Tangerang City government in Indonesia.

Those claims come from the researcher’s public account. They are not a substitute for reading every advisory, and the federal findings he mentions remain in triage. But the cross-vendor pattern is concrete enough to be useful: different teams, different codebases, and the same assumption that a value crossing an agent boundary can be used as if it came from a trusted caller.

Rapid7 provides a separate, narrower example. Its CVE-2026-97228 advisory describes an MCP tool argument reaching a GraphQL query without validation. Rapid7 rates it 2.7 out of 10 and fixes it in version 0.6.2 with a parameterized query. The advisory says the realistic exposure is a compromised or careless upstream MCP client, or indirect prompt injection forwarding an unvalidated identifier.

That is the shape of the problem. The model is only the delivery mechanism. The trust failure happens when data becomes authority at the next hop.

What protocol pivoting looks like

Consider a simplified chain:

untrusted document
        |
        v
agent A reads text and delegates a task
        |
        v
MCP server accepts a URL or identifier
        |
        v
agent B or an API client performs the request

A guardrail on agent A may reject an obvious request to access internal infrastructure. But if the malicious value is embedded in a document, transformed into a normal-looking task, and passed to a tool that performs the network request, the guardrail is no longer deciding at the point of effect.

This is why a blocklist is not enough. The server must validate the resolved destination, the redirect chain, the caller’s authority, and the purpose of the operation. A string that looks harmless can resolve to a private address. A hostname can change between validation and use. A tool that fetches documentation may be turned into a network proxy if its URL argument is not constrained.

The Google case described by Ars is a good illustration. The MCP Toolbox for Databases reportedly used an HTTP client without a redirect policy and without target IP validation. A crafted path parameter could make it follow a redirect to an internal endpoint. The issue was not that the model became malicious. It was that an agent-controlled value reached a network-capable component without a complete destination policy.

The protocol is not the security boundary

MCP gives tools a structured interface. Structure helps, but it does not establish trust.

A typed argument can still be attacker-controlled. A request from a different agent can still carry an indirect prompt injection. A server on the same internal network can still be compromised. If the receiving component treats every internal agent as an authority, the protocol has become a trust amplifier.

The common intuition is that internal delegation is safer than a user request. In an agentic system, that is backwards. A user request is usually visible at a primary boundary. Delegated work can cross several boundaries while losing the provenance of the original input at each step.

The useful security property is not “this came through MCP.” It is “this value has a recorded origin, an authorized purpose, and a policy decision that still applies at the point of effect.”

The fixes belong at the tool boundary

The public cases point to a practical checklist for MCP operators:

Treat every tool argument as untrusted input. Validate URLs, identifiers, paths, and selectors in the server, even when the caller is another internal agent.
Validate resolved destinations. Check IP ranges at connection time, disable unsafe redirects, and account for DNS rebinding rather than checking only the original hostname.
Constrain capabilities per tool. A documentation tool should have an explicit host policy, not general outbound network access.
Carry provenance across delegation. Preserve the originating user, document, agent, policy, and requested purpose as data that the next component can inspect.
Separate authentication from authorization. Knowing which agent called a tool does not prove that the agent is allowed to fetch a target or invoke a sensitive operation.
Log decisions, not secrets. Record the destination policy, authorization result, and correlation ID without copying upstream response bodies into centralized logs.
Test the chain, not just the server. Exercise prompt injection and protocol transitions together. A component can pass its local tests while the composition creates a new route to authority.

These controls are less glamorous than a new model benchmark. They are also where the risk is.

The operator consequence

Agent systems are being assembled from tools that were individually designed for narrower trust models. A database connector assumes its caller is authorized. A fetcher assumes its URL is benign. A delegation protocol assumes the sender has already made the decision. Put them together and the assumptions compose into a permission path.

The right review question is therefore not “does this model resist prompt injection?” It is:

Can untrusted content cross an agent boundary
and arrive at a network, data, or execution capability
without a fresh authorization decision?

If the answer is yes, the model is not the main boundary. The tool server is.

Protocol pivoting is a useful name for a recurring failure mode, but the engineering lesson is older: internal traffic is not trusted traffic, and a protocol is not an authorization decision.

The agent loop is only as safe as its least skeptical tool.