Single-agent security is hard enough; multi-agent security is where the industry is heading and where the gaps are widest. Interoperability protocols like A2A exist so that an agent from one vendor can find, trust, and hand work to an agent from another. That is powerful and it is also a trust decision made by software, at machine speed, across an organizational boundary. McKinsey's framing of agent risk names the shape of the problem: uncontrolled autonomy, fragmented access to systems, a lack of observability and traceability, an expanding attack surface, and agent sprawl. Every one of those gets worse when agents start delegating to agents.
The agent card is an unverified introduction
A2A uses agent cards to advertise what an agent can do and which authentication schemes it supports — but the protocol delegates credential management entirely to implementers and does not mandate how a card's authenticity is checked. That is the load-bearing gap. If a card can be forged or tampered with, an adversary can advertise a fake agent, register an unauthorized one, or take over a delegated task. Analyses this year separate the risks into supply-chain manipulations — malicious artifacts, poisoned tools, impersonated peers — and protocol-logic weaknesses, such as recursive delegation that deadlocks a system or spins it into an unbounded loop.
Each hop — user to planner to worker to tools — is a place authority can be dropped or forged. With agent-card verification left to implementers, an unverified card turns the delegation chain into the attack path.
Why 'the other agent said so' is not authorization
The failure mode that worries us most is transitive trust. Agent A is allowed to do something; it asks Agent B to do part of it; B asks C. If authorization is checked only at the first hop, the authority the user granted has silently widened by the third. Governance-gap research on interoperability protocols makes the point directly: MCP, A2A, and ACP can express how agents connect, but not the policy constraints an enterprise actually needs — who may delegate what, to whom, with which scope. The protocols move the messages; they do not enforce the intent.
Containing the blast radius
You cannot fix a protocol gap by hoping every implementer verifies cards correctly. You contain it by mediating the interactions and re-checking authority at each boundary, the same discipline that applies to a single agent's tool calls — extended to agent-to-agent calls.
- Verify identity at every hop: treat an incoming agent card or peer claim as unverified until proven, and refuse delegated tasks from unauthenticated peers.
- Re-authorize at each boundary: check the delegated action against policy where it executes — resource, arguments, and the original user's authority — rather than trusting that an upstream agent already checked.
- Bound the recursion: cap delegation depth and rate to defeat recursive DoS and runaway loops.
- Make it observable: emit an evidence event for each cross-agent action so the delegation chain is traceable after the fact, not a black box.
The same three checkpoints that guard one agent's traffic apply to agent-to-agent calls: classify what crosses the boundary, authorize the action there, and control what leaves — each denying on uncertainty.