Agent-to-Agent (A2A) Security: Trust Boundaries in Multi-Agent Systems

For most of the last two years, agentic security meant securing a single agent and the tools it reached. That framing is already out of date. Production systems are increasingly built as fleets of specialized agents that call and delegate to one another: a planner agent hands subtasks to a research agent, which asks a retrieval agent for documents, which invokes a summarization agent, and so on. The moment one agent starts trusting another, a new trust boundary appears - the boundary between agents - and it is the least-defended surface in most agentic architectures.

This guide is about that boundary. It explains what changes when agents talk to each other, why open interoperability standards like Google's Agent2Agent (A2A) protocol make the trust question urgent rather than academic, the specific ways multi-agent systems fail, and the controls that keep a single compromised agent from cascading through the whole fleet. If you have already read our work on indirect prompt injection and least privilege for AI agents, this is the multi-agent extension of both.

What A2A is, and why it raises the stakes

Agent2Agent (A2A) is an open protocol, introduced by Google, for interoperability between independent AI agents built by different teams on different frameworks. Its core idea is discovery and delegation. Each agent publishes an Agent Card, a machine-readable description that advertises the agent's capabilities and how to reach it. Other agents read that card, decide the agent is a good fit for a subtask, and delegate work to it. A2A standardizes the handshake so agents that were never designed together can still collaborate.

That is genuinely useful, and it is exactly why security has to move up a level. When any agent can discover and delegate to any other, the question is no longer "is this one agent safe?" but "can I trust what this peer agent tells me, and should I act on it?" Interoperability multiplies the number of trust relationships, and each one is a place where a wrong assumption becomes an exploit. The protocol makes connecting agents easy; it does not make trusting them safe. That part is on you.

The core mistake: treating peer output as trusted input

The single most common design error in multi-agent systems is treating a message from another agent as if it were trusted internal data. It is not. A peer agent may have been manipulated by untrusted content it read, may be compromised outright, or may simply be wrong. Its output is untrusted input, in exactly the same sense that a web page or an email is untrusted input to a single agent. Once you internalize that, most A2A controls follow naturally: authenticate the sender, scope what its request can trigger, and validate everything it sends before acting.

How multi-agent systems fail

The failure modes below are not exotic. They are the predictable result of connecting agents without treating the connections as trust boundaries. Each maps cleanly to a control.

Transitive prompt injection

This is the defining multi-agent risk. Malicious instructions reach one agent - typically through untrusted content it reads mid-task - and that agent then delegates to a peer, carrying the injected instruction along in the delegated task. The receiving agent treats the peer's message as legitimate and executes the instruction with its own privileges. The injection has propagated across a trust boundary it was never checked at. A chain of five cooperating agents is only as trustworthy as the least-defended input any one of them reads, because a payload injected at the edge can ride the delegations inward. We walk through a concrete multi-agent injection chain in comment-and-control multi-agent prompt injection and credential theft.

The confused deputy

A confused deputy is a privileged program tricked into misusing its authority for a less-privileged caller. In a multi-agent system, a low-privilege agent asks a higher-privilege peer to perform an action the caller could not perform itself - reading a restricted datastore, calling an admin API - and the peer complies because it over-trusts the request. Privilege effectively gets inherited across the delegation chain, which is precisely what least privilege exists to prevent. The remedy is to scope delegated authority narrowly and per call, so a peer never acts with more privilege than the specific delegation warrants.

Weak authentication and authorization between agents

Many multi-agent deployments authenticate the human user at the front door and then let internal agents talk to each other with no mutual authentication at all. That means any process that can reach the internal network can impersonate an agent, inject tasks, or harvest results. Every agent identity should be authenticated on every inter-agent call, and every call should be authorized against a policy - not waved through because it originated "inside" the system. This is the non-human identity problem applied to agents talking to agents; see non-human identity governance.

Untrusted Agent Cards and capability metadata

The Agent Card is the discovery mechanism, and it is supplied by the party being discovered, which makes it untrusted input. A malicious or compromised card can carry prompt injection in its free-text description fields, overstate its capabilities to attract delegations it should not receive, or advertise an endpoint that routes to an attacker. An agent that reads a card and acts on it without validation has trusted a stranger's self-description. Capability metadata must be validated, and the identity behind the card authenticated, before any of it is believed.

Cascading compromise

Put the previous failures together and you get the systemic risk: one compromised agent can cascade through a chain. Because peers over-trust each other, an attacker who subverts a single agent can use transitive injection and confused-deputy tricks to reach agents and resources far beyond the initial foothold. The blast radius of one compromise is the entire set of agents reachable through delegation, unless trust boundaries and least privilege contain it.

Multi-agent risk to control, at a glance

Each failure mode is a trust-boundary assumption that turned out to be false, and each has a direct control.

The controls that hold

There is no single setting that secures a multi-agent system. It is a small stack of disciplines applied at every boundary between agents.

1. Authenticate every agent identity. No agent should accept a task from, or send a result to, a peer whose identity it has not verified. Give each agent its own dedicated non-human identity rather than a shared credential.
2. Scope delegated authority narrowly. A delegation should carry only the authority needed for that specific subtask, for that call, and no more. Privilege must not accumulate as tasks pass down the chain.
3. Treat all inter-agent messages and Agent Cards as untrusted input. Validate structure and content, strip or neutralize instruction-like text where possible, and never let a peer's message or advertised capability directly trigger a high-impact action.
4. Apply least privilege per agent. Each agent's identity should reach only what its own job requires, so a compromised or confused peer cannot borrow reach it never had. This is the least privilege for AI agents principle applied across the fleet.
5. Audit every cross-agent call. Record who delegated what to whom, with what authority, and what happened. Without this, you cannot reconstruct a transitive-injection chain after the fact or prove containment.
6. Isolate agents to contain blast radius. Run agents with bounded scopes and boundaries between them so one compromise cannot silently become fleet-wide.

A2A and MCP are two halves of the same boundary discipline

It helps to see A2A security and MCP security as complementary. MCP governs the agent-to-tool boundary: how an agent talks to servers and tools, and why those must be authenticated and scoped. A2A governs the agent-to-agent boundary: how agents talk to each other. Both rest on the same principle - the thing on the other side of the boundary is untrusted until proven otherwise, its authority must be scoped, and everything it sends must be validated. If you have hardened your MCP surface using the MCP server security guide, you already know the moves; A2A just applies them to peers instead of tools. Browser and computer-use agents add a third surface, covered in securing computer-use and browser agents.

Where visibility fits

Every control above assumes you know which agents exist and how they connect. In practice, that is the missing piece. Multi-agent systems are assembled bottom-up by developers wiring agents together, and the delegation graph - which agent can call which, with what authority - is rarely written down anywhere security can see it. You cannot authenticate a boundary you do not know exists, or scope a delegation you never mapped.

This is where Anomity sits. A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint and discovers and inventories every AI agent and MCP server across the fleet, sending metadata only over HTTPS - never source code, never prompts. That inventory is what turns an invisible delegation graph into something you can govern. On agents that expose a hook, Anomity allows, denies, or logs each tool call before it runs, so a delegated or transitively injected action is evaluated against policy before it executes rather than after it has done damage. Continuous policy evaluation routes violations to your SIEM, Slack, email, and Jira, and every added, removed, or modified artifact lands in a queryable 90-day audit trail - the record you need to reconstruct a delegation chain after an incident. As the principle goes: you can't govern what you can't see. For the wider context, start with AI agents are the new shadow IT.

The bottom line

Multi-agent systems do not introduce a fundamentally new attack; they introduce a new place to apply the ones we already understand. The boundary between agents is a trust boundary, and every message crossing it is untrusted input. Transitive prompt injection, confused deputies, weak inter-agent auth, malicious Agent Cards, and cascading compromise all reduce to the same root: an agent trusted a peer it should have verified, scoped, and validated. Authenticate every agent identity, scope delegated authority per call, treat peer output and capability metadata as untrusted, enforce least privilege, and audit every cross-agent call. And before any of that, see the agents and how they connect, because you cannot govern a trust boundary you cannot see.