Securing Agent-to-Agent Communication: The Real Threats and How to Defend Against Them

Quick answer: Once agents call other agents or third-party tools, the threat model stops looking like a normal application and starts looking like a network of systems that trust each other’s output by default. The risks that matter most are prompt injection carried through tool results, overly broad permissions, poisoned or silently modified tool definitions, and one compromised agent’s bad output cascading into every agent downstream of it. The defenses that hold up are least privilege, treating everything an agent reads as untrusted input, sandboxed execution, and human approval gated to the actions that actually carry risk.

A single agent with a handful of tools is relatively easy to reason about. The moment agents start calling other agents, or pulling in tools from third-party servers, the attack surface changes shape. Every message an agent receives, whether from a user, a document, or another agent, is a potential instruction. Most agent frameworks were not designed with that assumption in mind, and it shows in how often the same handful of failures show up in production.

Why agent-to-agent communication is a different threat model

In a normal application, data and instructions are separate: a database record is data, and the code that processes it is instructions. An LLM agent collapses that distinction. Anything in its context window, a user message, a retrieved document, a tool’s response, or another agent’s output, can contain text the model treats as an instruction. When agent A calls agent B and uses B’s response to decide its next action, A is implicitly trusting that B’s output is safe to act on. If B was fed something malicious upstream, that trust propagates.

This is the core reason agent-to-agent systems need a different security posture than a single agent behind a chat interface. The question is no longer just “can a user trick this agent,” it’s “can anything this agent talks to, directly or transitively, end up steering it.”

The threats that actually show up in production

A few patterns account for most real incidents:

• Indirect prompt injection. Instructions hidden in a document, email, web page, or another agent’s output get read as context and followed as commands. This is now the most common entry point into agent systems, because it doesn’t require compromising the user at all, only something the agent reads.
• Tool and permission abuse. Agents given broad, standing credentials (a database connection with full read/write, an email account that can send to anyone) can be steered into misusing that access even without their own logic being flawed.
• Memory poisoning. Malicious content written into an agent’s persistent memory during one session can influence its behavior in later, unrelated sessions, especially in systems where memory isn’t scoped per user or per task.
• Cascading failures across agents. In a multi-agent setup, one agent’s corrupted output becomes another agent’s trusted input. Without validation at the handoff, a single compromised or manipulated agent can quietly steer an entire pipeline.
• Denial of wallet. An agent stuck in a retry or recursive loop, sometimes triggered deliberately, can rack up API and tool costs fast if there’s no ceiling on steps, retries, or spend per session.
• Approval manipulation. Systems that gate risky actions behind human approval are only as strong as the binding between what was approved and what actually executes. A loosely bound approval flow can be tricked into approving something other than what the human saw.

These are documented well enough at this point that OWASP’s Gen AI Security Project maintains a dedicated top-10 list for agentic applications, alongside an AI Agent Security cheat sheet that catalogs exactly these categories with specific mitigations for each.

What MCP got wrong, and what it teaches

The Model Context Protocol made it dramatically easier to connect agents to tools and to each other, and its adoption also produced a useful case study in what happens when a fast-moving standard doesn’t build in security defaults. Independent research and joint government advisories published in 2026 documented publicly reachable MCP servers with no authentication at all, and “tool poisoning” attacks where a server’s tool description carries instructions the user never sees but the agent reads as context. A related pattern, sometimes called a rug pull, is a server that behaves normally at first and then silently changes its tool definitions in a later session, after the user has already granted trust once.

None of this means MCP or agent-to-agent communication generally is unsafe to use. It means the protocol layer does not enforce security on your behalf, the same way HTTP doesn’t enforce authentication on your behalf. Whoever deploys the server is responsible for authenticating it, sandboxing what it can do, and treating its tool descriptions as untrusted content, not as safe metadata.

Defenses that hold up

The mitigations that actually work in production cluster around a few principles, not a long checklist of point fixes:

Least privilege, enforced as allowlists. Every agent and every tool gets the smallest set of permissions it needs, scoped to specific actions rather than broad API scopes. Read and write access are separate grants. No agent inherits another agent’s full permission set just because they need to exchange messages.

Treat everything external as untrusted, including other agents. A tool’s output, a document’s contents, and another agent’s message are all data, not instructions, until validated. Systems that draw a hard boundary between the instructions in the system prompt and everything read afterward are far more resistant to injection than ones that don’t.

Sandbox execution. Agents that can run code or hit arbitrary endpoints should do so in an isolated environment with default-deny network egress, not on infrastructure with broad access to production systems. If an agent is compromised, the blast radius should be the sandbox, not the network it sits on.

Sign and validate inter-agent messages. In multi-agent systems, don’t let agent B act on agent A’s output purely because A said so. Attaching provenance and validating it at the handoff limits how far a single compromised agent can propagate its damage.

Gate high-impact actions behind real approval. Not every action needs a human in the loop, but anything that spends money, sends external communication, or changes a system of record should. Bind the approval to the exact action and its parameters, not a vague category, so approving one thing can’t be used to execute another.

Set hard ceilings. Step limits, recursion limits, retry limits, and cost limits per session. These are cheap to implement and they turn a runaway loop from an incident into a non-event.

Log everything, and test like an attacker before production does. A consolidated trace across every agent in the system, plus adversarial testing (prompt injection attempts, tool abuse scenarios, permission escalation paths) run in CI before changes ship, catches most of this before it reaches a real user.

A minimal checklist before agents talk to each other

• Does every agent have an explicit, narrow allowlist of actions, not a broad credential?
• Is anything read from outside the system prompt (documents, tool output, other agents) treated as untrusted?
• Does code execution or external network access happen inside a sandbox with default-deny egress?
• Is there a hard ceiling on steps, retries, and spend per session?
• Are high-impact actions bound to a specific approval, not a category of approval?
• Is there one trace across the whole system, not separate unlinked logs per agent?

If most of these are “no” today, that’s the order to close them in. The systems that get hurt are rarely the ones with a single sophisticated flaw; they’re the ones missing two or three of these basics at once.

The takeaway

Agent-to-agent communication doesn’t fail the way traditional distributed systems fail. The risk isn’t a bug in the code path, it’s that the code path treats language as instructions by design, and every agent in the chain is a place that assumption can be exploited. Least privilege, untrusted-by-default inputs, sandboxing, and bounded execution close off the large majority of what’s actually being exploited today.

Eximo builds and hardens multi-agent systems with this threat model in mind from the start, not retrofitted after something goes wrong.