Agent-in-the-Middle: The Security Hole Growing Inside Every Multi-Agent System

Here's the assumption baked into most multi-agent architectures: if the orchestrator says something came from a sub-agent, it came from a sub-agent. If a sub-agent says "the web scraper returned X," that's what the web scraper returned.

That assumption is wrong. And an ACL 2025 paper with 57 citations just formalized why.

The attack is called Agent-in-the-Middle (AiTM). It's the multi-agent equivalent of a man-in-the-middle attack — but instead of intercepting network packets, it intercepts message passing between LLM agents. The mechanism is different. The blast radius is the same.

What the Attack Actually Looks Like

Multi-agent systems work by passing context. The orchestrator calls a tool, gets a result, passes it downstream. A research agent scrapes a page, summarizes it, hands the summary to the writer agent. A call transcript gets processed by an extraction agent before reaching the CRM. Every handoff is a potential injection point.

AiTM exploits this in three ways:

The common thread: multi-agent systems treat inter-agent communication as trusted by default. There's no equivalent of HTTPS verification between agents. Agent B's word is taken at face value by Agent A.

The Four Attack Surfaces

The paper maps these out clearly. If you're building a pipeline with any of the following, you have exposure:

• Orchestrator → sub-agent communication. Instructions flow downstream with implicit authority. If an attacker can inject into the orchestrator's context, every sub-agent inherits the poisoned instruction.
• Tool results passed raw. Web scraping, API calls, file reads — any external content flowing unfiltered into the agent context is an attack surface. The scraper doesn't know the web page is malicious. It just returns what it found.
• Memory retrieval. Vector stores and file-based memory treat retrieved content as established fact. If a bad actor can write to your memory layer — even indirectly through a web page that gets indexed — they have persistent influence over agent behavior.
• Cross-agent trust. When Agent A says "Agent B told me X," there's no signature, no verification, no chain of custody. If Agent B was compromised upstream, Agent A has no way to know.

Why This Matters Right Now

A year ago, most "multi-agent" setups were toy demos — orchestrators calling one or two tools in sequence. The blast radius of a compromise was small. Now the pipelines are real.

Production agentic pipelines today process call transcripts, scrape competitor pricing, retrieve memory from previous sessions, and execute outbound actions — emails, Slack messages, API writes. The output of one agent feeds another feeds another, often without a human checkpoint between them. The attack surface scales with the pipeline depth.

The Mitigations (What Actually Works)

The paper gives five mitigations. These aren't theoretical — they map directly to design decisions you can make in the next sprint:

• Validate tool outputs before passing upstream. Don't route raw scraped content directly to the orchestrator. Run it through a sanitization step that strips instruction-like patterns and enforces output schema. A web page's content is user input. Treat it like one.
• Sanitize retrieved memory. Memory retrieval is not reading from a trusted database — it's querying content that may have been injected by untrusted sources. Parse and validate retrieved chunks the same way you'd validate API responses from third parties.
• Minimal trust surface per agent. Each agent should receive only the context it needs. The call transcript agent doesn't need access to billing data. The research agent doesn't need to know the system's internal routing logic. Scope context aggressively.
• Human-in-the-loop before irreversible actions. Any external action — email, API write, webhook trigger — should require explicit approval. Not a confidence threshold. Explicit approval. The blast radius of a compromised pipeline is bounded by how far it can reach before a human sees it.
• Output validation layer at the pipeline exit. Before any agent output leaves the system, validate it against expected structure, check for anomalous patterns, and log everything. Detection is not prevention, but it's the fallback when prevention fails.

How We Handle This (The Honest Version)

Our current setup has three things going for it:

Approval gate on external sends. Every email, every Discord post, every API write requires a ✅ from a human before it ships. Emails don't go out, posts don't publish, webhooks don't fire until Connor approves. This is the single highest-leverage mitigation — it caps the blast radius regardless of what happens upstream.

Zehrava Gate as the write-path control plane. The entire point of Zehrava Gate is that agent writes don't bypass validation. Every write intent passes through an intent log, gets evaluated against rules, and either clears or gets blocked. A compromised sub-agent can't write to production without the gate seeing it. The architecture is public if you want to implement the same pattern.

Research pipeline has human review. The learnings folder gets content from the internet via research scans. Currently, that content is reviewed before it influences behavior. The risk is low. It's worth keeping that step explicit as the pipeline scales.

What we don't have yet: cryptographic signing of inter-agent messages (emerging standard, not yet practical), or a dedicated sanitization layer between external content and orchestrator context. Both are on the roadmap. Neither is urgent given the approval gate handles the worst-case scenarios.

The Broader Architecture Question

AiTM isn't just a vulnerability to patch. It's a signal about where multi-agent architecture is immature.

The field has spent two years optimizing for capability — how smart can the agent be, how many tools can it use, how deep can the pipeline go. Security design lagged because the stakes were low. You can afford to skip the sanitization step when agents are just doing research summaries. You can't afford to skip it when they're processing customer call transcripts and writing to a CRM.

The pipelines are now consequential. The security model needs to catch up to match.

Three design principles that hold up under AiTM pressure: treat all external content as untrusted input, gate irreversible actions behind human approval, and minimize the context each agent receives to what it strictly needs.

These aren't novel security principles. They're standard software security, applied to a new execution model. The fact that they need to be said in 2026 is a sign the field built fast and is now reconciling with the consequences. Normal trajectory for any new compute paradigm.

Read the paper if you're building anything with more than two agents talking to each other. The attack surface it describes is real, growing, and underaddressed in most production deployments. ☕