Securing the Agent-to-Agent (A2A) Protocol

Agents have started calling each other. MCP standardized how an agent calls a tool. The Agent2Agent (A2A) protocol standardizes how an agent calls another agent, including agents built by other teams and other organizations. That unlocks real capability. It also creates a surface you probably cannot see yet: agents you did not build, exposed as endpoints, reachable by agents you did not authorize.

This is the shadow-agent problem one layer up. When agents advertise and consume each other's capabilities across boundaries, the question shifts from "what agents are running?" to "which agents are talking to which, and who approved that?" You cannot govern A2A traffic you cannot see. This post covers how the A2A protocol works, why it is a distinct Agent Security & Governance (ASG) surface, and how to discover and govern it.

A related concern, trust between agents already inside one system, is covered in our post on agent-to-agent trust and delegation chains. This post picks up where that one stops: at the protocol boundary, where authority and context cross between systems and organizations.

How the A2A protocol works

A2A defines a common way for a client agent to find a remote agent, understand what it can do, and send it work. Three concepts anchor it.

Agent cards are the machine-readable manifest an agent publishes to advertise its identity, capabilities, and endpoints. A card is how a remote agent tells the world "here is what I am, here is what I can do, here is where to reach me."

Discovery is how a client agent locates a remote agent's card and decides to call it. An agent finds a card, reads the advertised skills, and routes a request to the matching endpoint.

Tasks and messages are the request/response unit exchanged between a client agent and a remote agent. A client sends a task, the remote agent works it, and messages carry the exchange back and forth until the task completes.

The contrast with MCP is the useful frame. MCP connects an agent to tools. A2A connects an agent to other agents. Both are protocol-level signals that ASG discovery can detect, and both expand what an agent can reach beyond the code you wrote.

Why A2A is a new security and governance surface

A2A moves authority and context across a boundary. Each of the following is a risk that a boundary crossing introduces.

Unadvertised or rogue agent cards. An agent can publish a card exposing capabilities no one reviewed. If a team stands up an A2A endpoint without going through governance, you now have a callable agent that no inventory knows about.

Cross-organizational trust. Calling a remote agent means trusting another party's model, data handling, and controls. You are not just trusting code, you are trusting how the other side prompts its model, where it sends data, and what guardrails it runs.

Capability creep. An agent's advertised skills can change without a governance review. A card that described a read-only lookup last month might advertise a write action today, and nothing forced that change through review.

Data egress. An A2A call can send sensitive context to an external agent. This is the same risk that pre-LLM guardrails address when data leaves your environment for a model provider, except the recipient is another agent whose handling you do not control.

These are the same categories of authority and context risk that the delegation-chains post treats inside a single system. The difference is that A2A pushes them across an organizational line, which is exactly why discovery and ownership matter more here, not less.

Discovering A2A agents

Arthur's discovery approach uses multiple layers because no single technique catches every agent. A2A adds a signal that plugs into that same multilayered inventory alongside MCP servers and framework agents.

Agent card and endpoint monitoring. Detect published agent cards and A2A endpoints the same way MCP monitoring detects new MCP servers coming online. A newly published card is a new agent to catalog and a new capability set to review.

Network-layer analysis. Identify A2A protocol traffic signatures in network requests, including calls going to external agents. This catches A2A usage that was never instrumented through telemetry.

Telemetry (OTEL). Instrument A2A client and server spans so cross-agent calls appear in traces. When an agent calls a remote agent, that hop should show up as a span you can follow, not disappear at the boundary.

API-driven discovery. Cloud agent registries are beginning to advertise A2A-capable agents through API endpoints, useful coverage for agents built on managed cloud services.

A2A discovery is effectively a fifth signal feeding the same ASG inventory. An A2A endpoint that emits no telemetry and shows up in no network analysis is invisible to the organization, which is the whole reason to run detection across layers.

Governing A2A once discovered

Discovery tells you an A2A endpoint exists. Governance turns that from unknown risk into managed operations.

Assign an accountable owner to every agent that exposes an A2A endpoint. An A2A agent without an owner is an agent without accountability, and that is a red flag in any review.

Classify risk by what the agent can do and who it can talk to. An agent that only accepts calls from other internal agents carries different risk than one reachable across organizational boundaries, and the classification should reflect that.

Apply guardrails on the A2A boundary. Screen inbound tasks for prompt injection before they reach your agent, and redact PII or sensitive data before it egresses to an external agent. These are the same pre-LLM and post-LLM guardrail patterns applied at the point where work enters and leaves through A2A.

Set policy on who can call whom. Allowlist which agents may be called and which capabilities may be advertised externally. A default-open A2A surface is a default-open attack surface.

Monitor call patterns for anomalies: new external callers, capabilities that change on a known card, sudden volume spikes. A shift in A2A behavior is a signal worth investigating before it becomes an incident.

Where this connects to the rest of ASG

A2A does not stand alone. It slots into the ASG framework already in place.

Discovery inventory catalogs A2A endpoints next to MCP servers and framework agents, so cross-agent capability is part of the same single source of truth. Once an A2A call lands inside the receiving system, the internal trust model takes over, which is the territory the delegation-chains post covers: re-verify at each hop, tighten scope, screen context. And A2A spans in your traces make a cross-system call debuggable end to end, so when something breaks across a boundary you can follow it rather than guess.

TLDR

• A2A standardizes agent-to-agent calls across systems and organizations, creating a new ASG surface built from agent cards, discovery endpoints, cross-org trust, and data egress.
• It is distinct from intra-system delegation. A2A is about the protocol boundary; delegation chains are about trust once a call is already inside your system.
• Discover A2A the same way you discover MCP and framework agents: agent card and endpoint monitoring, network-layer analysis, OTEL telemetry, and cloud APIs.
• Govern it with clear ownership, risk classification by reach, boundary guardrails for injection and data egress, allowlist policy, and continuous monitoring.

Want to bring A2A traffic under one governance framework? Talk to an AI expert about discovering and governing every agent in your environment.

‍