Understanding A2A: Google’s New Agent-to-Agent Protocol and Its Security Considerations

Storm-0558 was the kind of breach that should have ended a few careers and a few assumptions. In mid-2023, Microsoft disclosed that a China-nexus actor had stolen a consumer signing key and used it to forge Azure AD tokens for Exchange Online. That let them read email from U.S. government accounts, including senior officials. The ugly detail wasn’t just the access; it was that a single trust failure in identity infrastructure scaled into a cross-agency compromise. That’s the part worth remembering when you look at Google’s A2A protocol: once agents start making decisions and exchanging credentials on your behalf, the blast radius stops being theoretical.

A2A Is Not “Just Another API”

Google’s Agent-to-Agent protocol, or A2A, is an attempt to standardize how autonomous agents discover each other, negotiate capabilities, and exchange tasks across vendor boundaries. That sounds tidy until you remember that “standardize” is usually what people say right before they create a new trust layer. A2A is meant to let one agent ask another agent to do work without every vendor inventing its own brittle JSON dialect and calling it interoperability.

The interesting part is not the message format. It’s the trust model. If your agent can delegate to another agent, then you’ve created a machine-to-machine identity problem, a policy problem, and a logging problem all at once. That’s not novel in the abstract. It is novel when the “user” is a model that can be prompt-injected, tricked into over-sharing, or induced to call a tool it should never have seen. LLMs don’t just expand your attack surface; they make your existing trust decisions executable.

Why A2A Changes the Failure Mode

Traditional integrations are dumb in a comforting way. A service account has a scope, an API has a schema, and if the call is bad, it fails. Agent-to-agent systems are less obedient. They negotiate. They adapt. They can be persuaded. That means the failure mode is no longer only “unauthorized request.” It becomes “authorized request made for the wrong reason.”

If you’ve spent time on incident response, you know the difference matters. In a breach, the attacker rarely breaks the first control. They exploit the control you assumed was already settled. A2A creates more of those assumptions: who is allowed to discover which agent, what tasks are safe to delegate, what data can be returned, and whether the receiving agent is allowed to chain the request onward. If you don’t pin those down, you’re not building an agent mesh. You’re building a polite relay for bad decisions.

Google’s proposal also lands in a market already full of moving parts: Anthropic’s Model Context Protocol (MCP) is pushing tool integration, OpenAI-style function calling is now normal, and enterprise platforms like Microsoft Copilot and Salesforce are already wiring models into business data. A2A is trying to solve the inter-agent layer, but the security question is the same one that burned people with OAuth: what exactly did you authorize, and for how long?

The Security Problems You Actually Need to Model

The first issue is identity. If an agent can act on behalf of a user, you need to know whether it is using delegated authority, service authority, or some ugly hybrid of both. Those distinctions matter because an attacker who compromises an agent process may inherit access that was never meant to be portable. Storm-0558 was a reminder that trust in identity tokens is only as good as the key management behind them. Agents will make that problem more frequent, not less.

The second issue is prompt injection through the side door. A2A doesn’t eliminate malicious content; it moves it into task payloads, tool descriptions, and agent responses. If one agent ingests untrusted content and another agent acts on it, you’ve just built a cross-agent injection path. That’s not hypothetical. We’ve already seen indirect prompt injection in systems that read email, web pages, and documents. The only surprise is how many teams still treat the model as the trusted party and the data as the risk. That’s backwards.

The third issue is data minimization, which everyone claims to love and then ignores the second a product demo starts. If your agent sends a full task context to another agent because it’s “easier,” you’ve probably violated the principle of least privilege in a new and exciting way. A2A should force you to define task-scoped credentials, bounded context, and explicit return policies. If it doesn’t, your “agentic workflow” is just a data exfiltration pipeline with better branding.

What Good Controls Look Like in Practice

Start with explicit agent identity. Every agent should have a verifiable identity, a narrowly scoped authorization boundary, and a short-lived credential. Static, reusable tokens are a bad idea here for the same reason they’re a bad idea anywhere else: once they leak, they keep leaking. If you’re still handing around long-lived API keys in 2026, I have a bridge to sell you.

Then enforce policy at the broker, not inside the model. The model can suggest a delegation; it should not be the final authority on whether that delegation is allowed. Put allowlists around which agents can talk, what task classes they can exchange, and which data classes can cross the boundary. Log the decision, the payload hash, the caller identity, and the downstream action. If you can’t reconstruct the chain later, you won’t be doing incident response; you’ll be doing archaeology.

You also need content validation on both sides of the exchange. That means schema enforcement, output constraints, and refusal handling that doesn’t rely on the model’s mood that day. A2A should not accept “free-form” as a security posture. Free-form is what people call it when they haven’t finished the parser.

The Part Nobody Likes: Interop Expands Your Trust Boundary

Here’s the contrarian bit: standardization is not inherently safer. It often makes compromise more scalable. A common protocol can reduce bespoke bugs, but it can also create a uniform path for abuse across vendors, tenants, and workflows. That’s good for integration. It’s wonderful for attackers. Ask anyone who has had to clean up after a widely deployed auth or file-handling flaw.

So don’t buy the comforting line that A2A is secure because it is standardized. Standardized merely means you can now apply consistent controls. If you don’t, you’ve just made the failure mode repeatable. That’s not a feature.

The Bottom Line

Treat A2A as a new trust boundary, not a convenience layer. Require short-lived, task-scoped credentials, brokered authorization, and full audit trails for every delegation and return path.
Test for cross-agent prompt injection and over-delegation the same way you test for SSRF or token abuse: with hostile inputs, chained workflows, and assumed compromise.
If you can’t explain what one agent is allowed to know, do, and forward, it should not be allowed to talk to another agent.

References

• Google A2A protocol: https://google.github.io/A2A/
• Microsoft Storm-0558 analysis: https://www.microsoft.com/en-us/security/blog/2023/09/07/an-analysis-of-storm-0558-techniques/
• Barracuda ESG CVE-2023-2868 advisory: https://www.barracuda.com/company/legal/esg-vulnerability
• Anthropic Model Context Protocol: https://modelcontextprotocol.io/
• NIST SP 800-207 Zero Trust Architecture: https://csrc.nist.gov/publications/detail/sp/800-207/final