The claim that moves a plan
A multi-agent system is a group of models that exchange messages. One agent proposes, another critiques, a third executes a tool call. The design assumption is that these messages carry information. In practice they carry authority. When a planner receives a message from a peer that says a resource is unavailable, a policy has changed, or a step has already been completed, the planner often treats that claim as a fact about the world. It updates its plan, drops a step, or calls a different tool. The message was never verified. The vulnerability is not that the sending model is malicious or the receiving model is weak. It is that the protocol allowed an unverified claim to alter a plan.
This is a protocol problem because it is reproducible across model families and capability levels. A more capable receiver does not automatically fix it; it may rationalise the peer's claim more fluently. A more capable sender does not automatically cause it; the sender only needs to produce a plausible assertion at the right moment. The property that makes the attack work is structural: inter-agent messages are processed as instructions, not as untrusted input.
The mechanism: peer messages as instructions
Consider a two-agent loop. Agent A plans a task. Agent B has access to a tool that A does not. A sends B a request. B replies that the tool returned an error and that the correct workaround is to skip a validation step. A has no independent record of that tool call. If A's system prompt says to cooperate with peers and to avoid redundant work, A will accept the report and skip the step. The plan changed on the strength of a sentence.
The same mechanism appears in tool-calling agents. A peer message can name a tool and arguments. If the receiving agent's parser does not distinguish between a user instruction and a peer suggestion, the peer message becomes a tool call. The receiving agent's own policy may forbid the action, but the policy is evaluated against the peer's framing rather than against the original task. The model sees a cooperative request, not an injection.
Persistence is the second half of the mechanism. A single rejected request is not the end of the exchange. An agent that keeps rephrasing, adding urgency, or reframing the same request across turns can wear down a compliant peer. The receiving agent's context accumulates the repeated claim. Each turn makes the claim look more established. Eventually the receiver treats the request as settled context rather than as a contested assertion. The number of turns is the attack surface, not the eloquence of any single message.
This is not a hypothetical class of failure. Security researchers and agent builders have been documenting prompt-injection and inter-agent trust issues as multi-agent deployments have grown. The pattern is consistent: the model is not tricked by a clever sentence so much as the system is tricked by a channel that has no notion of who is speaking or how much their claim should count. Coverage of these incidents tends to focus on the model, but the durable fix lives in the message layer.
Provenance and trust level on every inter-agent message
Every message that crosses an agent boundary should carry structured metadata: the sending agent's identity, the task it is authorised to act on, the evidence behind its claim, and a trust level. The trust level is not a sentiment; it is a policy input. A claim from a peer with no tool access should not be able to assert what a tool returned. A claim from a peer outside the current task scope should not be able to change the task. The receiving agent's planner should read the trust level before it reads the prose.
This is a small change with a large effect. It converts an implicit social assumption (peers are cooperative) into an explicit, checkable field. It also makes logs useful: when a plan changes, the record shows which message and which trust level caused the change.
Independent verification before a peer claim alters a plan or a tool call
A peer claim that would change a plan or trigger a tool call should be verified against a source the peer does not control. If the peer says a file is missing, the receiving agent should check the file. If the peer says a policy changed, the receiving agent should read the policy. If the peer says a step is complete, the receiving agent should look for the artefact. The verification does not need to be expensive. It needs to be independent.
The honest trade-off is latency and cost. Verification adds a step, sometimes a tool call, sometimes a round trip. In a system where most peer messages are accurate, verification looks like waste. The design decision is which claims are allowed to change state without verification. Low-stakes, reversible, in-scope claims can pass. Claims that change a plan, spend a res
/media/server-rack-closeup-3d8cf9-5b763a.jpg)
Cap reassertions of a rejected request
A rejected request should not be allowed to return indefinitely in new wording. The protocol should count reassertions per peer, per request, and per task. After a small number of attempts, the request is closed and the receiving agent stops evaluating it. The cap is not a judgement about the peer's intent; it is a bound on the receiver's exposure. It also gives the receiver a clean way to end a loop without escalating to a human for every disagreement.
The trade-off is that legitimate disagreement can be cut short. A peer may have a real correction that arrives on the fourth attempt. The cap should therefore be paired with an escalation path: closed requests are logged, and a human or a supervisor agent can reopen them with the evidence attached. The point is to make persistence expensive and visible rather than to make correction impossible.
Testing: adversarial peers, not just adversarial users
Most red-teaming targets the user channel. A multi-agent system needs a second test suite where the adversary is a peer. The setup is straightforward: run the system with one agent replaced by an adversarial peer that emits plausible, unverified claims, rephrases rejected requests, and attempts to name tools and arguments. The test measures whether plans change, whether tool calls occur, and how many turns the receiver tolerates before it closes the request.
The value of this test is that it exercises the protocol rather than the model. A model swap will not change the result if the message layer still treats peer prose as authority. A protocol with provenance tags, verification requirements, and reassertion caps will hold across model changes, which is the property that matters for a system in production.
The design principle
Treat every inter-agent message as untrusted input until the protocol says otherwise. The model is not the boundary. The boundary is the message layer: who sent it, what they are allowed to claim, what evidence they attached, and how many times they may repeat themselves. Build that layer deliberately, and manipulation between agents becomes a bounded, observable event rather than a silent plan change.