An agent in the middle attack is a machine in the middle attack aimed at the channel between two agents. In a multi agent system the agents talk over an internal bus, a queue, or plain network calls. If that channel is not authenticated and integrity protected, an attacker who can sit on it can read, alter, drop, or inject messages while they travel between two real agents, and both agents keep believing they are talking straight to their teammate.
What an agent in the middle attack actually is
Think of two genuine agents in the same system. An orchestrator hands out tasks. A worker does them and reports back. Between the two runs a channel: a message queue, a socket, an HTTP call, a shared topic on a bus. In a healthy system that channel carries the orchestrator’s task to the worker unchanged, and carries the worker’s result back unchanged. The agent in the middle attack breaks that assumption. An attacker who has positioned on the channel becomes a silent relay. Every message still arrives, so nothing looks broken, but the attacker gets to edit the contents in transit.
Positioning is the part that sounds hard and often is not. It can be a compromised sidecar sharing the pod with an agent. It can be a poisoned shared queue that a third service was allowed to write to. It can be a network foothold on the segment where the agents exchange calls. Once the attacker is on the path, the two agents have no way to notice, because the channel offers no proof that a message is the one the other side sent.
A concrete example
Picture Acme Notes, a typical SaaS app with a billing assistant built from two agents. An orchestrator receives a support request and delegates the money work. A worker agent holds the refund tool. They exchange JSON over an internal queue. A support user asks to refund one order for nine dollars. The orchestrator publishes the task. On a healthy day the worker reads it and issues a nine dollar refund to the right order.
Now put an attacker on the queue through a compromised sidecar. The orchestrator’s task goes out. The attacker reads it, rewrites it, and lets the edited version continue to the worker:
orchestrator --> [attacker relays and edits] --> worker
sent by orchestrator:
{ "action": "refund", "order": 4182, "amount": 9.00 }
seen by worker (after edit in transit):
{ "action": "refund", "order": 4182, "amount": 900.00 }
The worker sees a well formed task on the channel it trusts. It has no reason to doubt it, so it pays out nine hundred dollars. The same trick works on the return trip. The worker reports “refund of 9.00 completed,” the attacker rewrites the report to hide the real amount, and the orchestrator logs a clean nine dollar refund. The receiving agent acts on data that was changed underneath it, and both sides think the conversation was private and honest.
Both agents are real. The lie is not who is speaking, it is what the channel delivered. An unprotected message in transit can be changed without either teammate ever knowing.
The controls that failed
An agent in the middle attack only works when the channel between agents is missing three things at once. Name them plainly, because each one is a control you can add back:
- No message signing. The worker cannot check that the task it received is the exact bytes the orchestrator produced. Nothing binds the message to its author.
- No mutual authentication. Neither end proves who it is to the other, so a relay in the middle can stand in for both without being challenged.
- No integrity check. There is no signature, hash, or sequence guard that a receiver verifies, so an edited message reads as valid.
When those three are absent, a message in transit can be read, changed, replayed, or dropped and nobody downstream can tell. The attacker never needs to guess a password or forge an identity. It just edits real traffic between two parties that already trust each other.
How it differs from agent impersonation
It is easy to file this next to an agent impersonation attack, but the shape is different. Impersonation is a rogue component pretending to be a trusted agent and speaking in its name. There is a fake agent producing new messages that claim to come from the orchestrator or a peer. An agent in the middle attack has no fake agent. It sits between two genuine agents and tampers with their real traffic. Impersonation forges an author. The middle attack forges the contents. One puts a stranger in the room wearing a teammate’s badge. The other lets both teammates talk while an eavesdropper quietly edits every sentence on the way across.
How signed, authenticated messages stop it
This is exactly what agent to agent authentication and signed, integrity checked messages are built to stop. When the orchestrator signs each task with a key only it holds, the worker verifies that signature before acting. A message the attacker edited in transit no longer matches its signature, so verification fails and the worker rejects it. Mutual authentication adds the second half: each end proves its identity to the other, so a relay cannot silently stand between them. A replayed or reordered message fails a sequence or nonce check for the same reason.
The point is that you stop trusting the channel and start trusting the proof carried inside each message. The attacker can still read or block traffic on an unprotected transport, but it can no longer change a task from nine dollars to nine hundred without the edit being caught. A tampered or relayed message fails verification, and a failed verification is a message the receiver throws away instead of obeying.
The assumption that breaks
One assumption does all the damage: that a message arriving on the internal channel is the same message the other agent sent. That holds only when the channel itself is authenticated and integrity protected. The moment an attacker can position on the path, the delivery guarantee is gone, and every agent that trusts raw channel contents is acting on data an outsider may have rewritten. The fix is not to hope the agents notice, it is to sign and verify so a changed message cannot pass.
This is the kind of bug you find by asking what each agent trusts about its inbound messages and why, not by replaying a list of known payloads. An autonomous security researcher that tests an application’s assumptions is built to spot a channel that trusts contents it never verified. An early, encouraging signal: a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. You can read more about the approach on our about page.
This attack is one entry in our AI Agent Security Field Guide, a map of how AI agents get attacked and how to defend each one.
Frequently asked questions
What is an agent in the middle attack?
It is a machine in the middle attack aimed at the channel between two agents in a multi agent system. An attacker who can position on that channel reads, edits, drops, or injects messages while they travel between two real agents. Both agents keep believing they are talking straight to their teammate, so the receiver acts on data that was changed in transit.
How is it different from agent impersonation?
Impersonation is a rogue component pretending to be a trusted agent and speaking in its name, so it forges an author. An agent in the middle attack sits between two genuine agents and tampers with their real traffic, so it forges the contents. One puts a stranger in the room wearing a teammate’s badge, the other edits every real message on the way across.
Which controls fail to allow this attack?
Three are missing at once: no message signing, no mutual authentication, and no integrity check on the channel between agents. Without them the receiver cannot tell that a task was rewritten in transit, and a relay in the middle is never challenged. An edited or replayed message reads as valid, so nobody downstream notices.
How do you stop an agent in the middle attack?
Stop trusting the channel and start trusting proof carried inside each message. When every agent signs its messages and the receiver verifies the signature, a tampered or relayed message fails verification and is thrown away instead of obeyed. Mutual authentication and a sequence or nonce check close the replay and relay gaps.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, a say in what it looks for, and founding pricing. If your team ships software worth pressure testing, apply to the design partner program.