Google’s A2A Protocol Lacks Any Defense Against Prompt Injection, Experts Warn

Google’s A2A protocol, now a Linux‑Foundation‑hosted standard and backed by a roster that includes AWS, Cisco, IBM, Microsoft, Salesforce, SAP and ServiceNow, was touted as the “secure backbone” for AI‑to‑AI collaboration. Yet a consortium of security researchers—Red Hat, Palo Alto Unit 42, Semgrep, Trustwave SpiderLabs and Solo.io—has identified ten critical gaps, the most glaring being a complete lack of defenses against prompt injection, the top OWASP‑listed vulnerability for large‑language‑model (LLM) applications (Grith, March 20, 2026). Red Hat’s analysis defines cross‑agent prompt injection as “malicious instructions embedded in content processed by interconnected AI agents causing one agent to pass or execute harmful commands in another agent’s context,” and notes that the A2A specification “provides no specific controls against this threat.” Palo Alto’s Unit 42 team confirmed the risk with a working proof‑of‑concept exploit that demonstrates how an attacker can inject a deceptive prompt into a downstream agent, causing it to perform unintended actions without any protocol‑level check.

The protocol’s optional Agent Card signing further erodes trust. Agent Cards—JSON metadata documents that advertise an agent’s identity and capabilities—are meant to be signed with JSON Web Signatures (JWS), but the spec only says they “MAY be digitally signed,” not that they must be (Grith). Semgrep’s review found that while A2A v0.3+ supports signing, it does not enforce it, leaving the door open for spoofed cards. An adversary could publish a fraudulent Agent Card that pretends to be a legitimate service, complete with fabricated capabilities, and the receiving agent would have no mandatory verification step to reject it. This weakness dovetails with the protocol’s design principle of “Opaque Execution,” which deliberately prevents an invoking agent from seeing the internal operations of a delegated agent. According to the specification, agents collaborate “based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations” (Grith). While this opacity was marketed as a privacy feature, it also means that no audit trail or real‑time inspection of tool calls, file accesses, or network requests is available to the delegating party.

Because of that opacity, A2A lacks a gate for pre‑execution policy enforcement. The protocol provides no mechanism to evaluate or block tool calls before they are carried out, unlike traditional permission systems that score each request against a policy engine. Instead, the remote agent receives a task, decides internally how to fulfill it, and returns the result, leaving the initiator blind to potentially dangerous side effects (Grith). The absence of a “user‑consent” state compounds the problem: while the spec defines task states such as “submitted,” “working,” “input‑required,” and “auth‑required,” it does not include a “user‑consent‑required” flag that would force a human or supervisory system to approve high‑risk actions before they proceed (Grith). This gap is especially concerning for enterprise deployments where compliance and auditability are non‑negotiable.

Industry observers have warned that the rush to adopt agentic AI could outpace security safeguards. VentureBeat’s recent coverage notes that “companies are sleepwalking into agentic AI sprawl,” with enterprises deploying autonomous agents faster than governance frameworks can keep up (VentureBeat). The same outlet highlighted Google’s quiet ascendancy in enterprise AI, but the new security findings suggest that the company’s push for standardization may have prioritized speed over resilience (VentureBeat). In parallel, a separate VentureBeat story on Meta’s rogue AI agent demonstrated how identity‑verification gaps can let malicious agents bypass internal controls, underscoring that the challenges identified in A2A are not isolated to Google’s ecosystem (VentureBeat).

Taken together, the analyses paint a picture of a protocol that, despite its broad industry endorsement, leaves the most exploitable vector—prompt injection—unmitigated and offers no built‑in verification of agent provenance or behavior. For organizations looking to build multi‑agent pipelines, the findings imply that additional layers of security—such as mandatory Agent Card signing, runtime sandboxing, and explicit consent workflows—will be essential to avoid the very attacks the A2A spec was meant to prevent. Until Google or the Linux Foundation revises the specification to address these gaps, the “secure backbone” narrative remains at odds with the technical realities exposed by the security community.