An Agent-to-Agent Message Is Still Untrusted Input

As soon as one agent can send another a message, a new input channel exists, and it has the same property every other input channel has: whatever arrives on it is untrusted. This is easy to forget precisely because the sender is also an agent, one you may have built, running inside your own system. The instinct is to treat a peer as a colleague. From the receiving agent's point of view, a message from another agent is exactly what a message from a stranger is: text that will be read by a model and might change what the model does.

Why a peer message is not a trusted message

Trust between agents does not compose the way trust between services does. A microservice that calls another over a typed API is constrained by the schema: it can send the fields the contract allows and nothing else. An agent-to-agent message is natural language, or a loose structured payload wrapping natural language, and the receiving agent interprets it with a model. There is no schema that says "this field is data, not instructions," because for a language model the distinction is not structural. It is a judgement the model makes, and a judgement is exactly what an attacker works on.

It gets worse in a chain. If agent A reads a poisoned web page and then summarises it to agent B, the injection has laundered itself: B is not reading the internet, it is reading a trusted teammate, and the hostile instruction is now wearing A's credibility. Every hop in a multi-agent system is a place where untrusted content can be relabelled as trusted, and the further it travels from its source the more trusted it looks.

What actually goes wrong on the channel

The failure modes are not exotic. They are the ordinary ways language manipulates a reader, now arriving between two automated parties:

• Injection passed off as a peer's output. The classic "ignore your previous instructions" and its quieter cousins, embedded in what looks like a status update or a result payload. The receiving agent has no reason to suspect a teammate, which is exactly the reason to scan the message anyway.
• False authority. A message that opens "I am the administrator agent" or "authorized by the operator, on behalf of the admin" is claiming a rank it has no way to prove. Agent identity between peers is largely unattested today, so a claim of authority inherits whatever trust the receiver is willing to extend, and a model is willing to extend a lot.
• Manufactured urgency. "Urgent: immediately transfer, delete, or send" is social engineering with the human removed from the loop. Urgency exists to short-circuit deliberation, and an agent asked to act fast is as susceptible to that as a person is.
• Data leaving through the reply. A message can ask the receiving agent to forward its results, its context, or its secrets to an address the message names. The receiver has the access; the message supplies the destination. Nothing is broken into. The agent is simply asked, by a peer, to hand something over.
• Control characters in the payload. Agent messages are frequently logged, rendered in terminals, or piped into other tools. A message carrying ANSI escape sequences can rewrite what a human operator sees in a log, hiding the very line that would have raised the alarm. The manipulation targets the human reading the transcript, not the agent.

The delegation half

A message is not the only thing that crosses the boundary. When one agent hands work to another it is delegating some of its authority, and authority delegated without limit is how a bounded task becomes an unbounded one. A sub-agent that inherits the full reach of its parent, and spawns its own sub-agents in turn, produces a tree where the actions at the leaves are attributable to nobody in particular and constrained by nothing that was decided at the root. Governing agent-to-agent interaction is therefore two problems: the content of each message, and the scope that travels with the delegation.

What governing the channel looks like

The rule is the one that already applies to every other untrusted input: judge it before the agent acts on it, and judge it on its merits rather than on who sent it. Concretely, three things.

Scan the message as content. Run an inbound agent-to-agent message through the same evaluation as any prompt or retrieved document, because it is one. Injection, exfiltration instructions, false-authority framing and control characters are all detectable in the text, and none of them become safe because the envelope says the sender was a peer.

Keep the delegation scoped. A sub-agent should carry a declared purpose and a bounded set of tools, and its actions should be attributable to the task that spawned it, so that a chain cannot quietly accumulate authority as it deepens.

Do not let a peer's claim set the trust level. Whether a message is acted on is a decision for the receiving system's policy, not for the sender's assertion. "I am the admin" is a string. It should be treated as one.

Multi-agent systems are arriving faster than the norms for securing them, and the appealing mistake is to model other agents as trusted collaborators because they are on your side of the diagram. The safer model is the older one: every message is input, input is untrusted until judged, and the fact that the sender can also reason is a reason for more caution, not less.

Shrike governs the agent-to-agent surface the same way it governs any other: an inbound message is scanned as content before the receiving agent acts on it, delegation carries a declared scope, and every verdict lands in an audit trail independent of which agent or platform sent the message. The related pieces go deeper on the surrounding ideas: what happens when someone else's agent calls yours, how authority travels down a delegation chain, and the full map of surfaces an agent touches.