Trust and Impersonation: The New Spam Problem Nobody’s Talking About
As soon as agents start talking to agents, someone has to answer an old question in a new context: how do I know this is really Agent X?
TL;DR
- As agents start delegating tasks to each other directly, a new question shows up fast: how does a client agent know a remote agent’s card is genuine, and not a forged copy standing in for a trusted vendor?
- A2A closed a real gap here with signed Agent Cards, shipped in the protocol’s v1.0 release in March 2026 — a cryptographic signature, using JSON Web Signatures, that lets a receiving agent verify a card was actually issued by the domain it claims to represent.
- Without signing, an attacker can stand up a fake Agent Card and redirect other agents into what the protocol’s own community calls a card forgery attack — the agent-era relative of a phishing email.
- Signed identity is not the same as authorization. A verified card proves who published it; it says nothing about what a client agent should let that remote agent actually do.
- The A2A ecosystem passed 150 supporting organizations and 22,000+ GitHub stars within its first year — scale that turns an unresolved trust gap into a real operational risk, not a research footnote.
The question every new protocol eventually has to answer
Email had to answer it in the 1990s. Websites had to answer it with HTTPS. Now it’s the turn of AI agents that talk to each other without a human in the loop for every exchange: when a client agent receives an Agent Card claiming to belong to a known vendor, how does it know that’s true?
People have started informally calling the failure mode bot2bot phishing — one agent impersonating another to get tasks, data, or payment authority routed to it instead of the real thing. It’s not an official industry term yet, but the underlying risk is exactly the one email spent two decades building infrastructure to solve: a message (or in this case, a card) that looks legitimate but isn’t. The difference is speed. A phishing email needs a human to click something. A spoofed Agent Card just needs another agent to trust it.
How A2A got here: a short timeline
The protocol’s own version history tracks this problem getting steadily more serious attention.
v0.3.0
Introduced streaming-first transport and enhanced Agent Cards with capability negotiation — agents could describe more about themselves, but identity was still self-asserted.
v1.0 — production-ready
The protocol’s first fully stable release. Headline change: signed Agent Cards using JSON Web Signatures, so a receiving agent can cryptographically verify who actually published a card, alongside multi-tenancy, multi-protocol bindings, and backward-compatible version negotiation.
v1.0.1
Added an extension mechanism for new data, requirements, RPC methods, and state machines — the scaffolding for future trust and governance extensions, even if none of the official examples tackle governance directly yet.
One-year mark
150+ organizations supporting the standard, the core repository past 22,000 GitHub stars, and production deployments live inside Azure AI Foundry and Amazon Bedrock AgentCore.
What a card forgery attack actually looks like
An Agent Card is fetched from a predictable, well-known path and read automatically — no human eyeballing a URL first. Before signing existed, nothing structurally stopped someone from publishing a card that claimed a well-known vendor’s identity, listed convincing-sounding skills, and pointed authentication and task delegation at an endpoint they controlled instead.
A client agent that delegates a task to a forged card isn’t just wasting a request — depending on what the task involves, it can hand over customer data, credentials, or payment authority to whoever stood up the fake card. That’s the “bot2bot phishing” risk in one sentence: identity theft at machine speed, with no human reading the sender’s address before hitting reply.
This is a structural risk of decentralized discovery itself, not a flaw specific to any one implementation — which is exactly why the fix had to live in the protocol rather than in each individual agent’s judgment.
How signed Agent Cards close the gap
Signed Agent Cards work the way domain verification works for email. The domain owner attaches a cryptographic signature to the card; a receiving agent checks that signature against the claimed domain before it trusts anything the card says about the remote agent’s skills, inputs, or endpoints. If the signature doesn’t check out, the card is treated as unverified — the equivalent of an email that fails DKIM.
This single change is what makes decentralized discovery viable at scale in the first place. Without it, every client agent would need some other way to manually vet each new remote agent it encountered, which defeats the entire point of agents finding and delegating to each other automatically. With it, verification becomes a cheap, automatic step that happens before any task, data, or negotiation is exchanged.
What signing still doesn’t solve
A signed card answers one question — is this really who it says it is? — and leaves a bigger one untouched: should this agent be allowed to do what it’s about to ask for? Research on governance gaps in agent interoperability protocols makes this distinction explicit: A2A is delegation-centric, built to answer which agent can handle a task, not whether it should be trusted with the specific authority a task requires.
The protocol’s extension mechanism, added in v1.0.1, gives the ecosystem a place to build governance controls in the future. But the four official example extensions released so far — Secure Passport, Timestamp, Traceability, and Agent Gateway Protocol — stop short of that. A verified, legitimately-signed remote agent can still be asked to do something it shouldn’t be trusted with, and nothing in the protocol itself will stop that conversation from happening.
What this means operationally
Treat a signed Agent Card the way you’d treat a domain-verified sending address: necessary, but not sufficient. Publish your own card at a predictable, crawlable path so legitimate discovery works. Rotate signing keys deliberately, as a domain-level credential, not an afterthought. And scope what a verified remote agent is authorized to negotiate before the first task ever reaches it — because by the time a card passes signature verification, the identity question is answered. The authorization question is still yours to own.
Frequently asked questions
What is bot2bot phishing?
An informal term for one AI agent impersonating another — publishing a fake Agent Card that claims to belong to a trusted vendor, in order to get other agents to delegate tasks, data, or payments to it instead.
What are signed Agent Cards?
Agent Cards with a cryptographic signature, using JSON Web Signatures, that let a receiving agent verify the card was actually issued by the domain it claims to represent before trusting its declared capabilities.
When did A2A add cryptographic identity verification?
Signed Agent Cards shipped as part of A2A’s v1.0 release in March 2026, the version that marked the protocol’s move from experimental to production-ready.
Does a signed Agent Card mean an agent is trustworthy?
It means the card is authentic — issued by the domain it claims. It doesn’t mean the agent should be authorized to do everything it asks to do; that governance layer still sits outside the protocol.
How is this similar to email spoofing protection?
Signed Agent Cards play a role similar to DKIM and domain verification for email: they let a recipient confirm a card genuinely came from the domain it claims, rather than an impersonator.
Closing thought
Every communication layer eventually has to solve for impersonation — it’s just a question of how early the fix arrives relative to how much damage the gap causes first. Agent-to-agent messaging got its answer inside its first year, which is faster than email managed. What it hasn’t gotten yet is the governance layer on top: proof of identity is only half the trust problem in bo2bot messaging, and the more interesting half — what a verified agent should be allowed to do — is still being written.
Sources
- A2A Protocol — A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent Communication
- Google Open Source Blog — A Year of Open Collaboration: Celebrating the Anniversary of A2A
- Stellagent — A2A Protocol Explained: How Google’s Agent-to-Agent Standard Grew to 150+ Organizations in One Year
- HarnessRouter — What Is the A2A Protocol? Agent2Agent Explained
- arXiv — Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express
