Understanding A2A: Google’s New Agent-to-Agent Protocol and Its Security Considerations
Discover how Google's A2A protocol standardizes secure agent-to-agent communication and the critical security considerations organizations must address.
Google’s A2A Tries to Make Agent Chatter Less Ad Hoc Than Email
When CVE-2024-3094 in XZ Utils showed up, the ugly lesson was not “open source is broken,” but that a tiny trust shortcut in a dependency chain can sit in production until one person notices SSH got 500ms slower. Google’s Agent-to-Agent protocol, or A2A, is trying to do for AI agents what OAuth did for web apps: replace bespoke, one-off handshakes with something standardized enough that security teams can actually reason about it.
A2A is not a model protocol and it is not a sandbox. It is a communication layer for agents that need to discover capabilities, exchange tasks, and hand off work across vendors and runtimes. Google has positioned it alongside Anthropic’s Model Context Protocol, which handles tool and resource access for a single agent, while A2A is aimed at agent-to-agent coordination. That distinction matters because the security failure mode is different: MCP bugs tend to expose local tools and data; A2A bugs can turn one compromised agent into a relay point for others.
Why Standardization Helps, and Where It Does Not
The obvious win is that a standard schema beats the current zoo of custom JSON over HTTP, webhook glue, and “trust me, this internal service is fine” engineering. In practice, that means fewer homegrown auth flows and fewer brittle parsing layers for teams to audit. It also means defenders can finally write policy once for a protocol instead of reverse-engineering ten vendors’ agent APIs.
But standardization does not equal safety. OAuth 2.0 standardized delegated access, and the industry still spent years tripping over redirect URI abuse, token leakage, and confused-deputy problems. A2A can reduce ambiguity around message formats and capabilities, yet it cannot stop an agent from being tricked into sending a high-value task to the wrong peer if identity, authorization, and task scoping are weak. If your design assumes “the protocol will enforce trust,” you are already in trouble.
A2A’s value is mostly in making trust boundaries visible. That is useful because agent systems are otherwise a mess of invisible privilege escalation: one agent has access to Jira, another to Slack, another to a code repo, and all of them can be induced to talk to each other. If you have ever watched a SOC reverse-engineer a chain from a ticketing bot to a CI/CD bot to a secrets manager, you know why explicit handoff rules matter.
The Security Questions A2A Forces You to Answer
The first question is identity. If one agent calls another, what exactly is being authenticated: the workload, the user behind it, the tenant, or the vendor? mTLS can prove a client holds a certificate, but it does not tell you whether that certificate represents a benign workflow or a compromised automation account. Without strong workload identity, A2A just gives you a cleaner way to move bad requests around.
The second question is authorization granularity. “This agent can talk to that agent” is too blunt for real deployments. You need task-level scoping, because the difference between “summarize this incident” and “open a pull request that changes IAM policy” is not academic. If the protocol does not force explicit task intent, attackers will abuse whatever implicit delegation you leave lying around. That is the same mess that made overprivileged service accounts such a gift to Volt Typhoon.
The third question is message integrity and provenance. A2A messages should be signed, logged, and bound to a specific session or task ID, otherwise replay and substitution attacks become boringly practical. This is not theoretical hand-wringing: in distributed systems, stale messages and confused state are how you get unauthorized actions that look perfectly legitimate in logs until someone notices the timestamp drift.
The Attack Surface Is the Agent, Not Just the Wire
Security teams love to obsess over transport encryption because it is measurable and familiar. Fine. TLS 1.3 on the wire is table stakes. The real problem is what the agent does after decryption. If an attacker can poison prompts, manipulate tool outputs, or inject malicious task data, A2A will faithfully carry the payload from one agent to another like an obedient intern.
That is why prompt injection remains the most boringly dangerous issue in this space. An agent that consumes untrusted content from email, tickets, documents, or web pages can be coerced into exfiltrating data or triggering downstream actions. A2A does not remove that risk; it can amplify it. If one agent is compromised, the attacker may not need direct access to the crown jewels. They just need the compromised agent to ask another agent nicely.
There is also a supply-chain angle that vendors keep glossing over. If A2A becomes the default interoperability layer, then malicious or buggy agents can masquerade as legitimate peers unless you have strong allowlisting, attestation, and provenance checks. We have already seen how quickly trust collapses when a signed artifact is not enough, whether that was SolarWinds’ Orion updates or the XZ backdoor. Agent ecosystems will not be magically cleaner than software supply chains. They will just be faster.
Controls That Actually Fit A2A Deployments
Start with workload identity that is bound to environment and tenant, not just a static API key stuffed into a config file. Use short-lived credentials, mTLS, and per-agent certificates where possible, and rotate them like you mean it. If your A2A deployment still relies on shared secrets copied into half a dozen services, you have recreated the worst parts of 2014 with better branding.
Then enforce explicit capability negotiation. An agent should declare what it can do, and the receiving side should verify that declaration against policy before accepting a task. That means denying by default when an agent asks for a capability outside its registered scope. Yes, this is annoying. So is incident response.
Logging needs to capture the full chain: sender identity, task intent, payload hash, downstream recipients, and final action taken. If you only log “agent X called agent Y,” you will have a very expensive mystery later. Feed those logs into detection rules that look for unusual fan-out, repeated retries across agents, and requests that cross tenant or environment boundaries. CrowdStrike, Wiz, and similar platforms already spend a lot of time correlating cloud identity with workload behavior; A2A adds another layer that needs the same treatment.
The Contrarian Part: Don’t Let A2A Become Your New Trust Shortcut
The standard advice will be to adopt A2A because it standardizes interoperability. That is only half right. Standardization helps defenders, but it also helps attackers automate abuse across vendors once the ecosystem converges on the same assumptions. A common protocol is not a security control; it is a common failure mode if you deploy it without strict policy, attestation, and segmentation.
The more useful posture is to treat A2A like any other high-risk internal API: minimize who can speak it, minimize what each agent can ask for, and assume any agent that can reach a sensitive peer will eventually be probed by an attacker. If that sounds pessimistic, good. Security architecture is supposed to be.
The Bottom Line
Pilot A2A only where you can bind workload identity to short-lived credentials, enforce capability allowlists, and log every task handoff with sender, recipient, and payload hash. Block any agent that can request actions outside its registered scope, and make “human approval required” the default for cross-system changes, not the exception.
If you are already running MCP or other agent tooling, map every downstream tool and data source before you connect A2A to it. The first thing to watch for is agent fan-out into privileged systems like GitHub, Jira, Slack, and cloud IAM; that is where a “helpful” assistant turns into an incident report.