Technical Guide

Agent2Agent (A2A) Protocol and Its Security Model

The Agent2Agent (A2A) Protocol is an open, vendor-neutral standard that lets independent AI agents discover each other, exchange messages, and delegate tasks over HTTP(S), JSON-RPC, and Server-Sent Events. It defines agent identity claims, message structure, and task lifecycle states, but explicitly leaves identity verification, authorization, and policy enforcement to the organizations that implement it.

Explore Runtime Governance Talk to an Expert

A2A at a Glance

Origin

Introduced by Google in 2025, now governed by the Linux Foundation as a vendor-neutral open standard.

Transport

HTTP(S), JSON-RPC 2.0, and Server-Sent Events for streaming task updates.

Discovery

Agents publish capabilities and supported auth schemes via an Agent Card.

Scope

Governs agent-to-agent task delegation; complements MCP’s agent-to-tool access model.

What Is the A2A Protocol?

The Agent2Agent (A2A) Protocol is an open specification for how independent AI agents, potentially built by different vendors, discover one another, exchange messages, and delegate work. Google introduced A2A in 2025, and stewardship was later transferred to the Linux Foundation, making it a vendor-neutral open-source project supported by multiple enterprise technology contributors. A2A addresses a specific gap in multi-agent architectures: as organizations deploy agents built on different frameworks, those agents need a common way to advertise capabilities and hand off tasks without custom point-to-point integrations. A2A is often discussed alongside Anthropic’s Model Context Protocol (MCP), but the two solve different problems. MCP governs how an agent accesses external tools and resources. A2A governs how one agent communicates with and delegates tasks to another agent. Enterprises adopting both protocols are managing two distinct trust boundaries, not one.

What A2A Secures, and What It Leaves to Implementers

The A2A specification is deliberately scoped as a communication and interoperability protocol. It standardizes how agents describe themselves, how tasks are structured, and how messages are formatted and transported. It does not implement authentication logic, authorization decisions, or policy enforcement. An Agent Card can declare that a given security scheme is required, but the protocol itself does not verify that a calling agent’s identity claims are legitimate. Identity in A2A is asserted through Agent Card metadata rather than cryptographically enforced by the protocol, which creates spoofing risk in environments that do not layer on independent identity infrastructure. Task delegation chains can also span multiple agents and hops. Tracking where a task originated, which agents touched it, and what was passed along at each step is an implementer responsibility, not something the specification tracks natively. Similarly, while A2A relies on HTTPS and SSE for transport, it does not mandate a specific encryption configuration or endpoint validation approach, leaving those decisions to the deploying organization.

A2A standardizes interoperability. It does not enforce identity verification, least-privilege delegation, or end-to-end audit trails. Those controls must be supplied by the runtime environment.

A2A and MCP: Two Distinct Trust Boundaries

Organizations running both A2A and MCP are managing separate but related trust boundaries. MCP controls what tools and data sources an individual agent can reach. A2A controls what tasks and information one agent can pass to another. A task delegated over A2A can trigger downstream MCP tool calls in a receiving agent, meaning a gap in one protocol’s enforcement can propagate into the other. Reconciling these boundaries requires a consistent view of agent identity, permissions, and audit data that spans both agent-to-tool and agent-to-agent interactions, rather than treating them as independent security domains.

Governance Decisions Security Teams Need to Make

  • Define which agents may be exposed externally through A2A Agent Cards, given the protocol’s discovery-by-default design.
  • Establish data classification rules for what information can appear in A2A task payloads to limit cross-agent data leakage.
  • Track A2A specification versioning under Linux Foundation governance, since the standard is young and may introduce breaking changes.
  • Confirm that A2A-based agent communications meet existing data residency and regulatory requirements, since the protocol provides no built-in compliance controls.

How A2A Structures Identity, Delegation, and Messaging

A2A organizes multi-agent interaction around a small set of protocol constructs. Understanding these building blocks is essential before adding enterprise security controls.

  1. Agent Card

    A JSON metadata document each agent publishes, describing its capabilities, skills, endpoint URL, and supported authentication schemes such as API key, OAuth2, or bearer token, similar in structure to OpenAPI security definitions.

  2. Discovery

    Agents can be located through a well-known URL convention used to publish Agent Card metadata, enabling discovery-by-default across environments.

  3. Task Lifecycle

    Interactions are modeled as Tasks that move through defined states, including submitted, working, input-required, completed, failed, and canceled.

  4. Transport Layer

    Messages move over HTTP(S) using JSON-RPC 2.0, with SSE supporting streaming updates and push notifications for long-running tasks.

Runtime Controls Needed to Secure A2A in Production

Because the protocol leaves verification and enforcement to implementers, production deployments should add the following controls outside the A2A specification itself.

  • Deploy mutual TLS or an equivalent transport security configuration, since A2A relies on HTTPS without mandating a specific implementation.
  • Validate and pin Agent Card sources during discovery to prevent malicious or spoofed agent metadata from being trusted automatically.
  • Map A2A task states to internal logging or SIEM systems to maintain an audit trail across agent-to-agent handoffs.
  • Issue per-agent scoped credentials rather than shared secrets when implementing Agent Card-declared authentication schemes.
  • Test delegation flows for unauthorized task escalation, since A2A does not natively constrain what a receiving agent may accept or forward.
  • Enforce least-privilege permissions between agents through an external policy layer rather than relying on protocol defaults.

Govern A2A Agent Communication Beyond the Protocol Spec

A2A defines how agents talk to each other. It does not enforce identity verification, least-privilege delegation, or audit visibility. Trussed AI provides runtime governance for AI agents, including agent identity, permissions, tool approval workflows, and audit logging, to help security teams close the gaps A2A leaves to implementers.

Explore Runtime Governance