Can a malicious instruction travel from one AI agent to another?

What the researchers tested

The preprint An Exploration of Attacks on AI Agent Systems investigates attempts to redirect agents through direct inputs and agent-to-agent communication. Its experiments include single-agent systems and selected multi-agent frameworks, with attention to information leakage, behavioural redirection and agent selection. The authors say their tests mainly expose single-agent vulnerabilities while extending the investigation to multi-agent settings. Their paper does not supply a representative survey of deployed services. Its findings are experimental evidence about particular configurations, not proof that all agents or every communication protocol are compromised.[1]

Our analysis: a colleague's output can still need checking

Imagine a workflow in which one assistant gathers documents, another summarises them and a third prepares an action for approval. Adding more agents can distribute useful work, but it also creates more places where a claim can acquire apparent authority. A sentence may arrive labelled as an agent's summary even though it originated in an untrusted document. Reviewers should ask whether each handoff preserves the distinction between evidence, interpretation and an instruction to act. That distinction matters even when all the agents share a business goal.

An operational design should make that distinction visible to the receiving system and to the human reviewer. A proposed action needs a reason and an authority, rather than merely a persuasive explanation supplied upstream. For a consequential workflow, a review screen could show the proposed change, the evidence behind it and the permission that would allow it. This is an editorial implication of the problem, not a claim that the paper tested that interface or proved a particular mitigation effective.

Shared memory and common tools deserve their own boundary test. If a research agent can write text that a second agent treats as an instruction, the handoff channel has combined evidence with control. A safer evaluation would label provenance, prevent one agent's free-form output from granting permission, and require the acting agent to validate consequential commands against a separate policy. Reviewers should then seed an untrusted document with a plausible instruction and observe whether it stays data. The preprint motivates that question; it does not validate this proposed control.

What controlled research can and cannot tell buyers

A successful laboratory attack shows that an unwanted behaviour is possible under the tested conditions. To judge purchasing risk, a buyer also needs to know whether those conditions resemble its deployment. Model version, tools, data sources and permission design all deserve attention. A headline success rate can be misleading when it omits how many tasks were tried, which attempts were counted and whether the attacker knew the system in advance. Different experimental questions can produce different numbers without either study being dishonest.

The reverse mistake is to dismiss an experiment because it uses a simplified environment. A small test can expose a trust assumption that deserves scrutiny before a system is connected to real records. The appropriate response is a bounded follow-up evaluation, not a promise that every theoretical risk will occur. Suppliers should explain what changed between a published test and their product, then provide evidence that those changes matter. Buyers need enough detail to distinguish a technical answer from a broad claim of safety.

Human impact: responsibility should survive a handoff

For an employee, a chain of assistants should not become a chain of uncertainty about who approved an action. A useful deployment makes it possible to trace a consequential result back to the original request and the person or policy authorising it. If a task stops because evidence is contradictory, staff need a manageable escalation path. Otherwise the labour saved in drafting can reappear as detective work after an error, with the least powerful employee left explaining a system they did not configure.

Future evidence would be more useful if independent teams reproduced the experiments on updated systems and published both successful and unsuccessful attempts. Tests should include ordinary tasks that must continue working, because a defence that rejects everything can look secure while being unusable. The present paper helps frame questions about trust between agents. It does not settle which commercial product is safest, demonstrate a live epidemic or justify allowing an assistant to perform sensitive actions merely because another assistant recommended them.