As AI agents increasingly delegate tasks to each other instead of just to humans, a new question matters more than it used to: when one agent tells another "I'm the trusted one, do this," how does the receiving agent actually know that's true? A real test shows what happens when the answer is "it just believes the message."
Most AI security discussion still assumes a human is on one end of every conversation. That assumption is breaking down fast. Google's Agent2Agent (A2A) protocol — announced in April 2025 and donated to the Linux Foundation two months later — reached version 1.0 in April 2026, and now has support from over 150 organizations, including AWS, Microsoft, Cisco, Salesforce, SAP, and ServiceNow. Microsoft is integrating it into Azure AI Foundry and Copilot Studio; AWS into the Bedrock AgentCore Runtime.
The premise is straightforward: agents built on completely different frameworks — LangGraph, CrewAI, custom stacks — need a shared way to hand work to each other. A shipping agent asking an inventory agent a question. A support agent handing a case to a returns agent mid-conversation. That's the real, current shift A2A is built to support, and it's happening at production scale, not just in research papers.
Which raises a question that gets far less attention than the interoperability story: when Agent A hands a task to Agent B, and the message claims to come from a trusted, high-privilege peer, how does Agent B actually verify that's true?
A structured agent-to-agent handoff typically includes a field naming which agent sent it — something like from_agent. That field is just data. It's whatever the sender wrote into the message. The question that determines whether a system is secure is simple to state and easy to get wrong in practice:
Does the receiving agent trust the claimed sender field, or does it verify the actual, authenticated caller — and does it prefer the second over the first when they disagree?
This is exactly the "identity claim" attack shape distinct from ordinary content injection: no malicious instruction needs to be hidden anywhere. The entire attack is one forged field in an otherwise completely well-formed, legitimate-looking request.
A real, controlled test against an agent-to-agent handoff system made this concrete. The setup: a low-privilege peer agent, with no special access of its own, sending a handoff request that claimed to originate from a trusted, high-privilege agent authorized to export sensitive data.
The gap between those two outcomes wasn't a difference in what the low-privilege agent tried to do — the attack attempt was identical. It was entirely a difference in whether the receiving system checked who was actually talking before deciding what to do about what they said.
This is worth stating plainly, because it changes where the responsibility actually sits: the A2A specification itself isn't naive about this. It specifies OAuth 2.0 for mutual agent authentication and JSON Web Tokens for signing requests — exactly the kind of mechanism that stops the attack demonstrated above, when it's actually enforced.
The real risk isn't a gap in the standard. It's the same gap that shows up in almost every security standard: a system can support signature verification as a feature while not actually requiring it, or requiring it but failing to correctly reject requests that don't pass. A deployment with signature verification available but not enforced is exposed exactly as if the mechanism didn't exist — the protocol having a fix and a specific implementation actually using it correctly are two different claims, and only the second one protects anything.
A practical implication: "we use A2A" or "our agents support signed handoffs" isn't itself a security claim worth trusting without verification. The meaningful question is narrower: does your specific deployment actually reject an unsigned or incorrectly-signed handoff request, tested directly, not assumed from the protocol's own documentation.
Agent identity forgery isn't an isolated concern — it's a specific instance of a pattern showing up across autonomous AI systems generally. It shares its core logic with zero-click attacks: no human is ever positioned to notice the forged identity, because the entire exchange happens agent-to-agent, with no interactive session for a person to review. And it shares the same underlying principle that makes confirmation gates work elsewhere: trust the authenticated channel, never a claimed field inside the content itself, regardless of how legitimate that field's contents look.
Identity-claim attacks and zero-click attacks share the same blind spot — no human ever in a position to catch what went wrong.