The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Malicious instructions can cross from one AI agent to another inside an ordinary-looking delegated task, then be acted on by an agent with access to sensitive tools. That makes MCP-based workflows worth securing carefully—but MCP is not itself a dedicated agent-to-agent messaging protocol, and the available reporting does not establish it as “the riskiest” protocol.
What MCP does—and where agent handoffs fit
The Model Context Protocol (MCP) is a client-server protocol that lets AI applications connect to servers exposing tools and other capabilities. A workflow in which one agent delegates work to another can use MCP, but it may also rely on a separate inter-agent protocol such as A2A. The distinction matters: a handoff between agents can cross a trust boundary, and authorization assumptions do not necessarily travel with the task.
In an October 5, 2026 report, Ars Technica describes malicious instructions passing through delegated agent workflows. One researcher calls the technique “protocol pivoting”; another characterization in the same report is indirect prompt injection. These describe the reported attack pattern, not a separate MCP feature or a universal flaw in the protocol.
How malicious instructions can cross between agents
- Untrusted content enters the workflow. An agent reads text controlled by an attacker, such as content included in a task or returned by a tool.
- The first agent passes it on. The text is relayed to another agent as part of an apparently routine delegated task. It may no longer look like externally supplied content.
- The receiving agent trusts the handoff. If that agent treats the sender or task as trusted, it may follow the malicious instruction.
- Tools turn the instruction into an action. The receiving agent may have credentials or capabilities that let it access data or perform operations beyond what the original content source could do directly.
The risk comes from the combination of untrusted content, agent behavior, delegated permissions, credentials, and the receiving service’s assumptions. It is not necessarily a defect in the language model itself. Microsoft’s April 2026 security guidance likewise warns that tool responses can carry prompt injection and that instruction-following alone is not a security boundary.
Recommended Free Tools
#1 Best Overall
Two different problems in the reported cases
The Ars Technica report describes tests across agents associated with Google, JPMorgan Chase, Weaviate, Rapid7, France’s interministerial digital directorate, and a U.S. federal agency. That list is a reported test set; it does not establish that every organization or product was vulnerable in the same way.
| Reported case | Failure described | What the example shows |
|---|---|---|
| Cross-agent instruction handoff | Malicious text could be passed onward as a normal task, with a downstream agent acting because it trusted the sender. | Content can cross an agent boundary while the receiving agent’s trust and permissions remain in effect. |
| Google MCP database toolbox | According to the report, the HTTP client did not apply a redirect policy or validate destination IP addresses. A crafted path parameter could lead it to follow a redirect to an internal endpoint and send a request on an attacker’s behalf. | This is an SSRF-style redirect and destination-validation flaw in a particular agent-integrated service, not evidence that all MCP servers share the defect. |
The report says Google’s fix used allow-lists and block lists. It also reports severity ratings of 8 for the Google issue and 2.7 out of 10 for a Rapid7 issue, and says Rapid7 fixed its issue in September 2026, the month before publication. Those are incident-specific details reported by Ars Technica, not a severity score or comparative ranking for MCP as a whole.
Rank #2
What MCP authorization can—and cannot—protect
MCP authorization is optional for implementations overall. Where HTTP authorization is used, the MCP authorization specification describes OAuth-based protections, including binding authorization to the intended resource and validating the token’s audience on the server. It also says an MCP server must not pass a client’s token through to an upstream service.
These measures help preserve authorization boundaries. They do not tell an agent whether natural-language content or a tool response is safe to obey. An authenticated agent can still be misled, and a valid token can still grant more authority than a task needs.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesThe NSA’s May 2026 release highlights risks involving serialization, trust boundaries, agent misuse, dynamic tool invocation, implicit trust relationships, and context sharing. Its accompanying information sheet says many implementations omit authentication and that permissions can be difficult to enforce or verify after initial setup. Authentication and authorization are important controls, but they do not remove the need to scrutinize inputs and constrain actions.
Controls for teams building agent workflows
Treat handoff content as untrusted
Do not assume content is safe because it arrived from an internal agent. Preserve its provenance where possible, and treat text relayed from tools, users, documents, and other agents as input—not as authority to override policy. Prompt filtering may help, but it should not be the sole defense.
Rank #4
Authorize each sensitive action
Check whether an agent is allowed to perform a sensitive operation at the point where it is requested, rather than relying only on a trusted initial setup or on the identity of the delegating agent. Apply least privilege to each agent and delegated task. Require explicit authorization for sensitive inter-agent transactions.
Validate credentials and resource boundaries
For MCP servers using HTTP authorization, validate tokens for the receiving server, bind them to the intended resource, and do not forward client tokens to upstream APIs. Keep each credential limited to the resources and operations that agent needs.
Constrain network destinations and redirects
For HTTP clients that accept user-controlled destinations or paths, validate destinations and handle redirects explicitly. Where appropriate, restrict private and internal IP ranges so an attacker cannot use the client to reach protected endpoints. The allow-list and block-list approach described in the Google case is an example of a response, not a universal configuration recipe.
Test the whole workflow, not just one connection
Review the chain from incoming content through delegation to the final tool or server action. Check what context survives each handoff, which credentials and capabilities the receiving agent has, and where authorization and destination validation occur. The NSA’s risk categories—especially trust boundaries, dynamic tool invocation, and context sharing—are useful prompts for that review.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Why “the riskiest protocol” overstates the evidence
The reporting makes a credible case that agent handoffs can carry malicious instructions across trust boundaries, and it describes a separate, concrete SSRF-style implementation flaw in a Google MCP toolbox. But the cited reporting provides no comparative benchmark ranking MCP against other protocols. The defensible conclusion is narrower: MCP-connected systems can participate in risky multi-agent workflows when teams fail to preserve trust, authorization, and network boundaries.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
