On April 9, 2025 Google announced the Agent2Agent (A2A) protocol at Cloud Next, with launch support from more than 50 technology partners including Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, and Workday. On June 23, 2025 Google contributed A2A to the Linux Foundation, which announced the Agent2Agent Protocol Project as a vendor-neutral home for the spec. By April 2026 more than 150 organisations were participating. A2A's positioning is deliberately complementary to MCP — where MCP defines how a single agent talks to its tools, A2A defines how agents from different vendors talk to each other. The security model treats every agent as an opaque box that exchanges signed, audience-bound messages with peers, which is a meaningfully different threat model from MCP's tool-invocation model. For defenders, A2A is worth understanding because cross-vendor agent interactions are arriving in production faster than the security frameworks for evaluating them.
What is A2A's core security premise?
That agents from different organisations should be able to coordinate without revealing their internal state. A2A treats each participating agent as opaque: when agent A asks agent B to do work, B's reasoning, memory, prompts, and tool calls are not exposed to A. The only thing A sees is the result B chose to return. Google's launch post and IBM's explainer both emphasise this opacity as a security feature — it means a proprietary support agent can call a partner's logistics agent without exposing either side's logic — but it is also a security challenge, because A cannot audit what B did with the data A sent. The protocol leans on enterprise-grade authentication, signed messages, and observability hooks to compensate; whether that compensation is sufficient is a question for individual deployments.
How does authentication work between agents?
A2A's authentication model has parity with OpenAPI authentication schemes, which means the spec supports bearer tokens, OAuth 2.0 flows, mutual TLS, API keys, and other standard primitives. Each agent advertises an Agent Card — a JSON document at a well-known URL describing the agent's capabilities, supported authentication schemes, and the security contact for the operator. When agent A initiates a session with agent B, A reads B's Agent Card, negotiates an authentication scheme both support, and establishes a session with credentials minted for that pairing. The pairing-specific credentials matter because they let an organisation revoke a single agent-to-agent relationship without revoking every other A2A connection — the same property that makes per-resource OAuth tokens better than account-wide tokens.
What does an Agent Card look like in practice?
Agent Cards are small JSON documents that act as the discovery and trust anchor for A2A. The shape below is drawn from the public spec and the A2A SDK examples, illustrating how a defender should expect to evaluate any agent before allowing it as a peer.
# agent-card.yaml — exposed at /.well-known/agent.json
schema_version: "0.2"
name: "Acme Logistics Agent"
description: "Schedules shipments and provides quotes for B2B customers."
provider:
organization: "Acme Logistics"
url: "https://acme.example.com"
security_contact: "security@acme.example.com"
capabilities:
skills:
- id: "quote_shipment"
description: "Returns a price quote for a shipment between two addresses."
input_schema_uri: "https://acme.example.com/schemas/quote_shipment.json"
output_schema_uri: "https://acme.example.com/schemas/quote_response.json"
- id: "schedule_pickup"
description: "Books a pickup for an already-quoted shipment."
requires_authentication: ["oauth2", "mtls"]
streaming: true
push_notifications: true
authentication:
schemes:
- type: "oauth2"
authorization_url: "https://login.acme.example.com/oauth2/auth"
token_url: "https://login.acme.example.com/oauth2/token"
scopes: ["shipping.read", "shipping.write"]
resource_indicator_required: true
- type: "mtls"
ca_bundle_uri: "https://acme.example.com/.well-known/a2a-ca.pem"
observability:
audit_log_endpoint: "https://acme.example.com/a2a/audit"
signed_response_attestation: true
What are the failure modes defenders should worry about?
Three. First, opacity makes audit harder: when agent B does the wrong thing on behalf of agent A, A's operator cannot inspect B's reasoning, and B's operator may not see the full chain of why A asked. A2A addresses this with the observability.audit_log_endpoint hook, but consuming the audit log is an organisational practice, not a protocol guarantee. Second, transitive trust: if agent A trusts agent B, and B in turn calls agent C, the trust path from A to C is not always explicit, and C may not know which downstream principal originated the request. The spec's "task delegation" semantics are still maturing on this front, and defenders should require explicit principal propagation rather than implicit chaining. Third, prompt-injection propagation: if agent A's input contains injected instructions and A forwards parts of that input to B, the injection moves across the trust boundary even though both agents individually validated their own inputs. The A2A community has acknowledged this and is iterating on structural markers, but as of late 2025 the responsibility falls on each agent's input handling.
How does A2A compose with MCP?
Cleanly, by design. MCP is the bus an agent uses to reach its own tools; A2A is the bus an agent uses to reach other agents. A logistics agent at Acme might use MCP to access an internal pricing database and A2A to take work from a partner's procurement agent. The two protocols share none of the same wire format but share the same identity primitives — both expect tokens minted by an enterprise IdP with audience-bound claims, both expect TLS, both expect audit logs. The June 2025 MCP spec revision and the A2A launch happened within ten weeks of each other, and the Linux Foundation contribution of A2A in late June was widely read as positioning the two protocols for complementary standardisation. Enterprises planning agent architectures in 2026 should expect to deploy both, with shared identity infrastructure underneath.
What should a defender require before allowing an A2A peer?
Five things. First, a valid Agent Card at a well-known URL with a current security contact and a non-trivial scope of capabilities. Second, authentication schemes that match the corporate IdP's supported flows — OAuth 2.0 with resource indicators or mTLS with a published CA, not API keys in headers. Third, a published audit-log endpoint and a documented retention period, so that incidents can be reconstructed. Four, signed response attestations on every A2A response, so that a tampered or fabricated response is detectable. Five, an explicit principal-propagation policy: when the peer agent calls onward agents, the original requesting principal must remain visible in the chain. None of these are A2A-specific in concept, but A2A is the first protocol that makes them an interoperable bar for agent-to-agent communication.
How Safeguard Helps
Safeguard's A2A inventory tracks every Agent Card connected to your agents and your tenants' agents, validates each card's authentication scheme against the corporate IdP baseline, and flags peers that lack signed attestations or audit-log endpoints. Griffin AI ingests A2A audit logs into the security data lake so that cross-organisation agent transactions are reconstructible, and policy gates block A2A connections to peers that fail the five-criteria bar described above. Where principal propagation is missing — peer agents that drop the original requesting identity — Safeguard surfaces the gap as a finding rather than letting transitive trust silently exfiltrate accountability. A2A is going to be how cross-vendor agent work happens; Safeguard makes its security posture measurable rather than aspirational.