What Is Agent-to-Agent (A2A)? The New AI Attack Surface — and How to Govern It

For two years the story of enterprise AI has been an agent calling a model, and — more recently — an agent calling a tool. There's a third call now, and most teams can't see it: an agent calling another agent. That hop has a name — agent-to-agent (A2A) — and it is the least-governed surface in the entire AI stack.

This post is a practical definition of A2A: what the protocol actually is, why the delegation hop between two agents is a blind spot your existing controls don't cover, and what it takes to govern it.

What is agent-to-agent (A2A)?

Agent-to-agent (A2A) is a protocol for one AI agent to delegate work to another. Instead of a single monolithic agent that does everything, you get specialists: a scheduling agent, a billing agent, a research agent, a customer-record agent. When the scheduling agent needs a customer's billing status, it doesn't reimplement billing — it asks the billing agent. That request, and the reply, is an A2A hop.

The emerging A2A protocol standardizes what that looks like on the wire. A few concepts matter for the rest of this post:

• Agent Cards. Each agent publishes a machine-readable description of itself at a well-known discovery endpoint (/.well-known/agent-card.json) — its identity, endpoint, and the skills it offers. Other agents read the card to decide who can do what.
• Messages and tasks. A caller sends a message (message/send), optionally streams the response (message/stream), and can manage long-running work through a task lifecycle (tasks/get, list, cancel, resubscribe).
• Push notifications. For work that outlives a single request, a caller can register a webhook so the peer can call it back when a task completes.
• Delegated authority. A hop often carries an on-behalf-of credential — the calling agent is acting for an end user, and that user's authority rides along with the request.

None of this is exotic. It's a normal RPC pattern. What makes it dangerous is where it sits.

Why the A2A hop is a new attack surface

Your LLM gateway governs the call from your app to the model. If you've adopted an MCP proxy, you also govern the call from your agent to its tools. The A2A hop is the one in between those two that nobody instruments — and it is arguably the highest-risk of the three, because a hop to another agent is a hop to something that will itself go make more calls.

Left ungoverned, the delegation hop is invisible in five specific ways:

1. No caller identity. When Agent A calls Agent B directly, B often has no reliable idea which tenant, which user, which application is really behind the request. Authority gets muddled the moment it's delegated.
2. No policy on what may be delegated. There's no control point that says "the scheduling agent may ask the billing agent for status, but never for card numbers." Any agent can ask any peer for any skill it advertises.
3. No scan of the data that crosses. A message from one agent to another can carry PII, secrets, or a whole customer record in its payload — and it leaves your perimeter for the peer with nobody looking at it.
4. No record that it happened. When an auditor asks "show me every time an agent acted on this customer's behalf," there is no trail. The hop simply isn't logged anywhere that survives.
5. No brake on runaway delegation. Agent A asks B, which asks C, which asks A again. Without loop detection across the delegation chain, a multi-agent system can spiral — burning budget and hammering downstream systems — with no kill switch.

On top of those, the protocol's own features add sharp edges. Push-notification webhooks are a classic SSRF vector — a tenant-supplied callback URL pointed at 169.254.169.254 or an internal service is a data-exfiltration or metadata-theft primitive if the proxy forwards it blindly. And Agent Cards over-advertise by default: an agent that lists every skill it can do, to every caller, is a discovery-time information leak.

This is the same lesson the industry already learned with tools and MCP — an agent will send an SSN to a tool that didn't need it, because models aren't trained to think about data minimization — except now the "tool" is another autonomous agent that will take that data and act on it.

What it means to govern agent-to-agent calls

Governing A2A means putting a control point on the delegation hop — the same move that an LLM gateway makes for model calls and an MCP proxy makes for tool calls. Every hop passes through one place that can authenticate it, decide it, scan it, and record it, before the message reaches the peer.

Concretely, agent-to-agent governance is a set of controls on that hop:

• Caller identity on every hop. Resolve the calling agent to a real tenant (and, via the delegated on-behalf-of credential, a real end user) before anything else runs. Delegation without identity is the root cause of most of the risks above.
• A peer-agent registry with per-tenant scope. Register each peer agent once — its endpoint, auth scheme, and credentials — then scope which agents and which skills each tenant is allowed to reach. Default-deny, not default-reach.
• Policy on every hop. Allow or deny a hop by caller, target agent, or requested skill, expressed as policy-as-code with dry-run, versioning, and rollback — so "who may delegate what to whom" is a reviewable, testable artifact, not a hard-coded assumption inside an agent.
• PII scanning on the message. Inspect the outbound message — and streamed events — for PII, then block or redact before it crosses to the peer. Data minimization enforced at the boundary, not hoped for.
• Human approval gates. For sensitive hops — a particular skill, a particular target agent — pause and require a human to approve before execution, resolvable from a console or portal.
• Delegation-loop detection. Watch the chain of hops and kill a session that starts to spiral before it runs away.
• Governed discovery. Serve each peer's Agent Card through the control point with a per-tenant skills allow-list, so agents advertise only the skills you intend — closing the over-advertisement leak.
• Centralized credentials. Hold peer-agent credentials centrally — stored, or forwarded on-behalf-of — so calling agents never see raw secrets.
• A tamper-evident audit trail. Sign and hash-chain every hop into an append-only record, so "which agent acted on whose behalf, and what data crossed" is answerable — and provably un-altered.

That last one is the point where A2A governance meets compliance. A delegation you can't prove happened is a delegation you can't defend in an audit; a tamper-evident AI audit log of every hop is what turns "our agents talk to each other" into "here is exactly what they did."

How DVARA governs A2A: a separate, independent plane

DVARA treats A2A as a first-class plane — a peer to the LLM plane and the MCP plane, not a bolt-on. It runs as its own proxy (on :8075) with its own governance engines, so you turn it on precisely when your agents start delegating, and your model and tool traffic are unaffected.

The hop flow is deliberately simple: DVARA governs exactly one hop, returns the peer's reply unchanged, and makes no onward call of its own.

1. Agent issues a hop. Your agent sends its A2A message to a peer through the DVARA A2A Proxy instead of calling the peer directly.
2. Identity & registry. The proxy authenticates the caller — API key to tenant — and resolves the target agent from that tenant's registry.
3. Policy, PII & approval. The hop is checked against A2A policy, the message is scanned for PII, sensitive hops pause for human approval, and loop detection guards the delegation chain.
4. Forward & audit. The message reaches the peer, the reply is returned unchanged, and every step is signed into the A2A audit chain and metered per hop.

Coverage spans the whole protocol — message/send, streaming message/stream, the task lifecycle, and push-notification config — with the tenant-supplied webhook URLs SSRF-validated before they're ever forwarded. The A2A audit chain is its own append-only, HMAC-signed, hash-chained trail, separate from the LLM/MCP chain but unioned into the same SIEM exports and compliance reports.

Where A2A fits: the three planes of AI governance

The shape here is not new — it's the third instance of the same pattern. Governance belongs at the boundary every request already crosses:

• The LLM plane governs your app-to-model calls — routing, policy-as-code, PII, cost, and audit on every completion.
• The MCP plane governs your agent-to-tool calls — MCP tool-call governance with per-tool policy, PII scanning, approval gates, and audit.
• The A2A plane governs your agent-to-agent calls — agent-to-agent governance with identity, per-hop policy, PII, approval, loop detection, and its own audit chain.

Model, tool, agent. Three call types, one governance model, one tamper-evident audit story across all three. If your agents already call models and tools through a governed boundary, extending that boundary to the hops they make to each other is the natural next step — and it's the one that most teams haven't taken yet.

Frequently asked questions

What does A2A stand for? Agent-to-agent — a protocol for one AI agent to delegate work to another, so specialist agents can call each other instead of one monolithic agent doing everything.

How is A2A different from MCP? MCP (Model Context Protocol) governs an agent calling a tool — a database, an API, a file store. A2A governs an agent calling another agent. They're complementary: an agent might use MCP to read a database and A2A to ask a billing agent for a customer's status. The risk profile differs too — a tool executes and returns, but a peer agent may itself make more calls, so A2A carries delegation-chain risk that tools don't.

Why is agent-to-agent a security risk? The hop between two agents is usually invisible: no reliable caller identity, no policy on what may be delegated, no scan of the data crossing to the peer, and no record it happened. Add runaway delegation loops, SSRF-prone push webhooks, and over-advertised Agent Cards, and the delegation hop becomes the least-instrumented, highest-blast-radius surface in the stack.

What does it take to govern A2A? A control point on the hop that authenticates the caller, resolves the peer from a scoped registry, evaluates the hop against policy, scans the message for PII, optionally requires human approval, detects delegation loops, and signs every hop into a tamper-evident audit trail — before the message reaches the peer.

Do I need A2A governance if I already govern LLM and MCP calls? If your agents delegate to one another, yes — it's the third of the same three call types (model, tool, agent) and the one most teams haven't instrumented yet. The controls are cheapest to add before the delegation graph gets complex.

Getting started

A2A is early, which is exactly why it's worth governing now: the controls are cheapest to put in before the delegation graph gets complicated, not after. If your agents are starting to delegate to one another, the fastest path is to read how the A2A governance plane works, or go straight to the A2A Governance Plane documentation for the concrete registry, policy, and audit model.

The delegation hop between two agents is invisible today. It doesn't have to stay that way.