Protocol pivoting is the next agent trust boundary
The dangerous part is not the first tool call. It is the handoff.
Agent platforms are starting to bridge MCP, agent-to-agent protocols, workflow engines, browsers, and internal APIs. A recent protocol-pivoting disclosure shows why security teams should treat every translation layer as an authorization boundary.
Security teams already know how a vulnerable MCP server can expose files, tools, and credentials. The newer problem is subtler: what happens when one agent protocol hands work to another.
This week, researchers described a "protocol pivoting" issue that received CVE-2026-97228, where a malicious MCP server could use a connected client as a bridge into a downstream agent-to-agent workflow. The public reporting framed the issue as a new class of AI agent attack because the attacker does not need to directly compromise the downstream agent. They only need to control an upstream tool response that the bridge re-packages as legitimate delegated work.
That is the security lesson. Agent systems are no longer isolated chat sessions with tools. They are protocol meshes.
Why protocol pivoting matters
In a simple agent setup, the trust boundary is easy to draw:
- A user asks for work.
- The model decides whether to call a tool.
- The tool returns data.
- The agent presents or acts on the result.
In a modern enterprise setup, that sequence is already too small. A single workflow can involve an MCP tool server, an internal orchestrator, a browser automation agent, a ticketing agent, a code agent, and one or more service APIs.
Every hop changes the shape of the request. A tool result becomes a task. A task becomes a message. A message becomes a workflow step. A workflow step becomes an API call.
If the security model only asks "is this protocol message well formed?", it misses the important questions:
- Who authorized this specific downstream action?
- Which content is data, and which content is instruction?
- Which agent is allowed to delegate to which other agent?
- Did the downstream agent receive the original task context or a sanitized summary?
- Can policy distinguish user intent from attacker-controlled tool output?
Those are not model-quality questions. They are control-plane questions.
The failure is provenance loss
Protocol pivoting is easy to underestimate because each component can look reasonable in isolation.
The MCP server returns a response. The bridge maps that response into the downstream agent's format. The downstream agent receives a valid task. The target API sees a properly authenticated request.
But the chain has lost the part that matters most: the authority of each instruction.
In human terms, the downstream agent needs to know the difference between these two statements:
- "The user asked me to summarize the document."
- "A document told me to ask another agent to email the summary outside the company."
To a protocol bridge, both can become strings. To a security policy, they are completely different acts.
That is why this belongs in the same family as indirect prompt injection, insecure inter-agent communication, and rogue agents. The attack does not require breaking cryptography or bypassing a login screen. It exploits the gap between syntactic validity and delegated authority.
Map it to OWASP Agentic Top 10
The OWASP Agentic Top 10 is useful here because protocol pivoting is not one isolated bug class. It is a chain across several agentic risks.
| OWASP area | How protocol pivoting shows up | Control implication |
|---|---|---|
| ASI01 goal hijack | A downstream task is shaped by attacker-controlled upstream content instead of the user's original goal. | Separate user intent from tool output before delegation. |
| ASI02 tool misuse | A downstream agent invokes tools that the upstream tool response should never be able to influence. | Evaluate tool calls against the full chain of authority. |
| ASI03 identity and privilege abuse | The action executes under a legitimate agent identity, masking the untrusted origin. | Bind agent identity to purpose, source, and allowed delegation paths. |
| ASI07 inter-agent communication | A bridge turns content from one trust domain into instructions in another. | Require provenance-preserving envelopes between agents. |
| ASI10 rogue agents | An apparently legitimate agent acts outside its intended task because the control plane accepted a bad delegation. | Monitor deviations from task scope, not just authentication success. |
What security teams should build now
The defensive answer is not "ban protocol bridges." They are becoming normal infrastructure. The answer is to make translation layers policy-enforced and evidence-producing.
1. Preserve instruction authority
Every message passed between agents should carry labels for user instruction, system instruction, tool output, retrieved content, and generated summary. Do not flatten these into one prompt blob before delegation.
2. Bind delegation to a task record
A downstream agent should know who requested the task, why this agent was selected, what tools are in scope, and which sources are allowed to influence decisions.
3. Deny authority upgrades at bridges
A bridge should not be able to convert untrusted content into a higher-authority instruction. If a tool result asks for a new action, treat it as data unless an independent policy approves it.
4. Log the chain, not just the endpoint
Incident response needs to reconstruct which upstream content influenced a downstream action. Endpoint logs that only show the final API call are not enough.
The CISO question
Ask every team building agent workflows one direct question:
If an upstream tool response tells a downstream agent to do something outside the user's original task, where is that blocked, logged, and explainable?
If the answer is "the model should know better," the control is missing. If the answer is "the downstream API has authentication," the control is still missing. Authentication proves which agent acted. It does not prove that the action was authorized by the right instruction.
The next phase of agent security is about preserving intent across movement. MCP, agent-to-agent protocols, browsers, workflow engines, and internal APIs will keep converging. The organizations that stay ahead will treat every bridge as a place where provenance can be lost, privileges can be laundered, and policy needs to make a fresh decision.