Source: Where Cloud, Security and AI Converge (arnav.au) — 2026-07-16
Summary
An independent security analysis of the Agent-to-Agent (A2A) protocol argues that its biggest security risk isn't a bug — it's a deliberate design choice. A2A lets agents advertise capabilities and supported auth schemes through "agent cards," but never mandates how those cards get verified as authentic, leaving agent-card spoofing (via DNS or CDN compromise) and unauthenticated callback URLs as attack surfaces every implementer has to close on their own.
Key Takeaways
- A2A's "agent card" is essentially a public profile an agent publishes describing what it can do and how to authenticate with it — but the protocol never specifies how a client should verify that a card is genuinely from the agent it claims to represent.
- That gap creates agent-card spoofing: if an attacker compromises the DNS record or CDN serving an agent card, they can swap in a malicious card and impersonate a trusted agent to every client that fetches it.
- Credential provisioning is explicitly out of scope for A2A by design — the spec's authors chose to lean on existing enterprise identity infrastructure (OAuth, OpenAPI auth schemes) rather than invent a new identity system, which keeps the protocol lightweight but pushes the entire security burden onto whoever implements it.
- Callback URLs — the addresses an agent uses to receive asynchronous responses from another agent — are a second unauthenticated surface: without independent verification, anything that can reach that URL can inject a response.
- The recommended mitigations are concrete: scope OAuth tokens to specific agent skills (not blanket access), validate authorization at every interaction point rather than once at the start, and treat tenant boundaries as fixed unless bridged through an explicit, audited federation policy.
Reel Script
Hook (17s / 38 words) The protocol letting AI agents talk to other companies' AI agents has a hole baked into its own spec — and it's not an oversight, the authors left it there on purpose.
Core Concept (85s / 190 words) A2A — Agent-to-Agent — is a protocol that lets one AI agent discover and call another agent, possibly one built by a completely different company. To make that discovery work, each agent publishes what's called an agent card: a small public document that says "here's what I can do, and here's how you authenticate with me" — think of it like a business card, except software reads it and immediately starts trusting what it says. Here's the problem: A2A never specifies how a client is supposed to verify that a card is actually genuine. It just assumes the card you fetched is the real one. If an attacker can compromise the DNS record pointing to where that card is hosted, or compromise the CDN serving it, they can swap in a fake card — and now every agent that trusts that card is talking to an impersonator instead of the real service, following whatever "authentication instructions" the fake card told them to follow. The protocol designers left this open deliberately, choosing to lean on companies' existing identity systems rather than build a new one into the spec itself.
Hands-On (75s / 165 words) Picture the actual flow: Agent A wants to use Agent B's capabilities, so it fetches Agent B's card from a URL. That card says "call this endpoint, authenticate this way." If nothing verifies the card's authenticity beyond "it loaded from the expected URL," an attacker only needs to control that URL's DNS or CDN layer — not breach either agent directly — to sit in the middle of that trust relationship. The second gap works similarly: agents often get responses back asynchronously through callback URLs, and if those aren't independently authenticated, anything that can reach that URL can inject a fake response into the conversation. The fixes the analysis proposes are all about narrowing blast radius rather than trusting the card wholesale: scope OAuth tokens to a single skill instead of the whole agent, and re-check authorization at every single interaction, not just once at the handshake.
Takeaway (24s / 52 words) If you're wiring up A2A between agents from different vendors or teams, don't assume the protocol handles trust for you — it explicitly doesn't. Treat every agent card and callback URL as unverified until your own identity layer says otherwise.