Agent Card Poisoning: A2A Protocol Discovery and Identity Spoofing Defenses

Agent card poisoning targets the A2A (Agent2Agent) protocol's Agent Card: a JSON manifest a remote agent publishes, typically at /.well-known/agent-card.json, describing its identity, capabilities, skills, endpoint, and required authentication before any task delegation or message exchange begins. Attackers can weaponize this manifest two ways: by embedding adversarial instructions inside fields a host agent's LLM later reads as trusted metadata, or by forging, tampering with, or spoofing the card itself so a client agent trusts, authenticates to, and sends data to the wrong party entirely. Both paths fail at discovery time, before a single A2A message has been exchanged, which is what separates this entry from attacks on an already-established agent-to-agent session.

What it is

The defining object is the Agent Card: a structured metadata document a client agent fetches to decide which remote agent to trust, what it can do, and how to authenticate to it. The defining cause splits into two failure modes the industry has documented separately. The first is metadata injection: a malicious remote agent's card carries adversarial instructions in ordinary-looking fields, a skill description or a capability note, and a host agent that concatenates that metadata directly into its LLM's reasoning context, with no boundary between "data describing this agent" and "instructions this agent should follow", can be steered into unauthorized tool calls. The second is card-level spoofing and tampering: because the A2A specification does not mandate how every deployment verifies a card's authenticity, an attacker can publish a forged card at a look-alike domain, compromise DNS or a CDN to serve a modified card from a legitimate domain, or exploit a gap in the spec's own signature-verification design so a forged card passes as authentic. The defining consequence in both cases is the same: a decision the client's own governance model assumed was already validated, whether this is the agent it meant to talk to, and whether what it says about itself can be trusted, turns out to rest on unverified content.

What it is not

Agent session smuggling, where a compromised or malicious remote agent injects covert instructions into an already-established, ongoing A2A session between legitimate requests and responses. This entry targets the discovery step that happens before any session exists; that entry targets the message stream inside one.
MCP tool poisoning, where a hidden instruction rides in an MCP server's tool description or tool-call result. The mechanism (untrusted metadata read as trusted instruction) is structurally similar, but the protocol, the object (an Agent Card versus a tool definition), and the standards bodies tracking each are distinct.
A general critique of A2A's design or a claim that agent-to-agent protocols are inherently unsafe. The protocol defines an optional card-signing mechanism; the gap covered here is in how narrowly that mechanism was originally specified, not in the existence of a signing feature.
Reproducible exploit code or a step-by-step forgery recipe for a specific deployment's card-signing configuration.

In scope

Adversarial content embedded in Agent Card fields (skills, descriptions, capability metadata) that a host LLM ingests as context rather than as inert data.
Forged Agent Cards published at attacker-controlled or look-alike domains, and cards tampered with via DNS or CDN compromise.
Gaps in card signature verification that let an attacker's own key material pass as a trusted signer.
Client agents that cache a card at initialization and never re-fetch or re-verify it before a high-value task delegation.
Defensive controls for card signing, trust-root management, registry-based discovery, and behavioral monitoring of agents discovered through this path.

Target state and trust boundaries

The target state is the Agent Card itself and, downstream, whatever the host agent's LLM does with the metadata it contains. The trust boundary that fails is the assumption that a card fetched from a /.well-known/ path, or returned by a discovery registry, was authored by the agent it claims to represent and contains only descriptive data. A2A's own specification defines securitySchemes and security fields so a card can declare how a client should authenticate to it, and defines an optional Agent Card Signing mechanism (Section 8.4 of the specification, a JWS structure per RFC 7515 computed over a JCS-canonicalized form of the card per RFC 8785) so a client can verify who signed the card's content. Signing establishes card integrity and signer provenance; it does not by itself establish that the signer is safe, reliable, or approved for a given client's use case, which is a separate authorization decision every deployment still has to make.

Persistence

An Agent Card is fetched once and typically cached, so a poisoned or spoofed card does not need repeat delivery: every session a client agent initializes, and every task it later delegates to that cached identity, inherits whatever the card said at fetch time. This makes the persistence class broader than a single session and closer to shared-system scope, since the same card can be served to, and cached by, every distinct client organization that discovers that agent, not just repeat sessions from one deployment.

What the research establishes

Keysight ATI researcher Kumar Aditya documented Agent Card Poisoning as a metadata-injection vulnerability, published 2026-04-02, describing a five-step chain: a host agent syncs and caches a remote agent's card at initialization; a legitimate user request (in the proof of concept, a booking request carrying payment details) triggers the workflow; the host LLM constructs its reasoning prompt by incorporating the user request alongside the cached card content and available tools; because the card was injected into that context with no boundary enforcement between metadata and instruction, the LLM produces an execution plan prioritizing an unauthorized HTTP POST to an attacker-controlled endpoint; the host then executes that plan, exfiltrating the sensitive data (Semiconductor Engineering, Agent Card Poisoning: A Metadata Injection Vulnerability In The Systems Using Google A2A Protocol, 2026-04-02).

The Cloud Security Alliance's MAESTRO threat model, published 2025-04-30 by Ken Huang and Idan Habler, catalogs the spoofing half of this pattern as two distinct threats. T3.1, Unauthorized Agent Impersonation, describes attackers exploiting weak authentication and "easily spoofed Agent Cards" to create fraudulent cards or compromise a legitimate agent's credentials, rated high risk on medium likelihood and high impact. T3.4, Malicious A2A Server Impersonation, describes attackers standing up deceptive A2A servers disguised as legitimate organizations, exploiting the fact that Agent Cards "can be spoofed or manipulated" and that many deployments lack robust server-side authentication, rated high risk on medium likelihood and very high impact. CSA's recommended mitigations include decentralized identifiers with periodic re-validation, mutual TLS, Certificate Transparency logging for Agent Cards, DNSSEC on server domains, trusted agent registries, and multi-signature endorsement schemes (Cloud Security Alliance, Threat Modeling Google's A2A Protocol with the MAESTRO Framework, 2025-04-30).

The specification's own card-signing design has an open, documented weakness in exactly the trust-establishment step CSA's mitigations depend on. As originally written, Section 8.4.3 instructed a verifier to retrieve a card's signing key using the jku header supplied inside the signature itself, letting the signer nominate its own trust root. An open pull request against the official a2aproject/A2A specification repository, filed under CWE-863 (Incorrect Authorization), notes that this design lets an attacker sign a forged card with a self-generated key while pointing jku at a URL the attacker also controls, so verification succeeds against a root the attacker chose, not one the client actually trusts. The proposed fix constrains key discovery to a verifier-side policy, reclassifies jku as informational rather than a retrieval instruction, and adds a general trust-anchor-selection rule to the specification. As of this writing the pull request remains open, unmerged (GitHub, a2aproject/A2A pull request #2099, docs(spec): require verifier-side trust root for Agent Card signature verification).

Governance context matters for how fast a fix like this can propagate. Google announced A2A at Cloud Next in April 2025 and donated it to the Linux Foundation on 2025-06-23 as a vendor-neutral project with founding members including AWS, Cisco, Microsoft, and Salesforce (Linux Foundation, Linux Foundation Launches the Agent2Agent Protocol Project). The Agent Card's well-known path moved from agent.json to agent-card.json, and a signatures field was added, in specification version 0.3.0 on 2025-07-30; version 1.0.0 followed on 2026-03-12, registering the well-known suffix with IANA. By its one-year anniversary on 2026-04-16, the project reported over 100 technology companies supporting it (Google Open Source Blog, A year of open collaboration: Celebrating the anniversary of A2A). A specification-level trust gap at that adoption scale does not get fixed by one deployment patching its own code; the fix has to land upstream and propagate to every implementation.

Detection: observable signs

An Agent Card's securitySchemes, skills, or description fields contain imperative language, tool names, or destination URLs that do not describe the agent's own function.
A client agent's LLM reasoning trace shows tool-selection influenced by content sourced from a cached Agent Card rather than from the user's own request.
A card served from a given domain changes its declared authentication requirements, endpoint, or signing key between fetches, with no corresponding, out-of-band change announcement.
A card's signature verifies successfully, but the trust-root key was retrieved from a URL embedded in the card's own signature header rather than from a client-controlled key store or registry.
A client agent delegates a high-value task to a remote agent using a card fetched once at initialization, with no re-fetch or re-verification since.

Useful telemetry includes a diff log comparing every fetched Agent Card against the last version confirmed clean for that identity, a record of which key source (client-configured versus signer-supplied) resolved each signature verification, and a mapping from every downstream tool call back to which fields of which cached card contributed to the LLM's reasoning context.

Defenses, containment, and recovery

The table below is SSA editorial guidance for defenders. It is neither a standard requirement nor a measured effectiveness ranking.

Control	Transition it interrupts	Applicability	Residual risk and verification
Strict boundary enforcement between card metadata and LLM instruction context	Adversarial content in a card field being reinterpreted as an executable instruction	Any host agent that ingests remote Agent Cards into its reasoning prompt	Requires the framework to treat card fields as data to be displayed or matched, not concatenated as free text; verify by testing a card with imperative-language fields and confirming no tool call results.
Verifier-side trust-root policy for signature verification	An attacker-supplied `jku` or key URL being accepted as the trust root	Any deployment relying on A2A's Section 8.4 card-signing mechanism	Closes the specific CWE-863 gap once a deployment adopts a client-configured keystore; does not help until the specification fix in PR #2099 lands and implementations upgrade.
Mutual TLS and DNSSEC on the serving domain	A forged or tampered card being served from a spoofed or compromised domain	Any A2A server exposed to discovery by external client agents	Protects the transport and domain integrity but not a legitimate domain's own compromised card content; pair with signature verification.
Trusted agent registries with reputation and behavioral monitoring	A previously unknown, spoofed, or newly registered agent being trusted on first discovery	Multi-agent deployments that discover agents dynamically rather than through a fixed allow list	Registries reduce first-contact risk but still depend on the registry's own onboarding checks; verify what vetting a registry actually performs before trusting its listings.
Periodic re-fetch and re-verification before high-value delegation	A card cached at initialization no longer matching what the server currently serves	Any client agent that caches Agent Cards across more than one task or session	Adds latency and a network round-trip per re-check; scope re-verification to task value rather than every call if that cost is prohibitive.

Prevention should treat every Agent Card field as untrusted input to the LLM context, the same posture MCP tool-description defenses already apply to tool metadata, and should configure signature verification against a client-controlled trust root rather than one a card can nominate for itself. Detection should diff cards against the last confirmed-clean version and flag any that carry imperative or destination content, or that change their declared authentication scheme unexpectedly. Containment should suspend delegation to the affected identity, invalidate cached copies of its card across every client that fetched it, and treat any action already taken on that identity's instructions as unverified pending review. Recovery should re-establish trust only from a freshly fetched, freshly verified card against a known-good trust root, and re-check any external effect a poisoned card's instructions may have already triggered.

Boundaries with similar concepts

This differs from agent session smuggling and shared state poisoning in timing and object. That entry path targets the message stream inside an already-established, ongoing A2A session; a victim agent has already decided to trust its counterpart and the attack manipulates what passes between them mid-conversation. This entry targets the decision to trust that counterpart in the first place, before any session exists, by manipulating the discovery document the decision is based on. A poisoned card can be the precondition that makes a later session-smuggling attack easier, but the two fail at different points and call for different controls: signing and trust-root policy for discovery, message authentication and intent-grounding for an ongoing session.

This also differs from MCP tool poisoning mainly in protocol and object, not mechanism. Both rely on a host LLM reading operator-supplied metadata (a tool description, an Agent Card field) as trusted context with no boundary against it being read as instruction. Agent Card poisoning additionally carries a distinct spoofing dimension MCP tool poisoning does not center on: an entire counterparty identity, not just a tool's stated behavior, can be forged.

Mapping to standards and research

Source	Source-owned term or item	Relationship to this article
Keysight / Semiconductor Engineering (2026-04-02)	Agent Card Poisoning	Direct, documented proof-of-concept naming and describing the metadata-injection variant of this pattern.
Cloud Security Alliance, MAESTRO (2025-04-30)	T3.1 Unauthorized Agent Impersonation; T3.4 Malicious A2A Server Impersonation	Direct threat-modeling evidence for the card-spoofing and server-impersonation variant, with likelihood and impact ratings.
a2aproject/A2A specification and GitHub PR #2099	Section 8.4 Agent Card Signing; CWE-863 trust-root gap	Primary-source evidence that the protocol's own signing design has an open, specification-level authorization weakness.
MITRE, CWE	`CWE-863 Incorrect Authorization`; `CWE-347 Improper Verification of Cryptographic Signature`	General software-weakness classifications underlying, respectively, the trust-root gap and the broader class of signature-bypass flaws this pattern can fall into.
OWASP GenAI Security Project	Securing Agentic Applications Guide 1.0	Independent guidance recommending HTTP Message Signatures and mutual TLS for agent identity verification, applicable to hardening Agent Card-based discovery.
OWASP Top 10 for Agentic Applications 2026	`ASI06:2026 Memory & Context Poisoning`; `ASI07:2026 Insecure Inter-Agent Communication`	The two broader risk categories this pattern spans, depending on whether the failure is metadata read as instruction or a spoofed counterparty identity.
Agent State Attack	Agent card poisoning	SSA descriptive phrase bundling the two variants under one entry, not attributed to the sources above.

Related terms

Agent state attack: the umbrella definition, including shared and multi-agent state among the listed target states.
Shared state poisoning in multi-agent systems: the adjacent surface targeting an already-established session's message stream rather than the pre-session discovery document.
MCP tool poisoning: the adjacent surface using a structurally similar metadata-as-instruction mechanism against a different protocol's tool definitions.
OWASP and MITRE ATLAS crosswalk: the broader framework mapping this entry's standards table draws from.

FAQ

Does Agent Card poisoning require a vulnerability in the A2A specification itself?

No, not for the metadata-injection variant. Keysight's documented proof of concept works against a host agent that concatenates card content into its LLM's reasoning context with no boundary enforcement, which is an implementation choice, not a required behavior. The spoofing variant is different: CVE-tracked or not, the open CWE-863 gap in Section 8.4.3's original trust-root design is a specification-level weakness that any implementation following that section literally would inherit.

Does signing an Agent Card make it safe to trust?

Signing establishes that the card's content has not been altered since signing and identifies who signed it, provided the verifier's key-discovery path is not itself attacker-influenced. It does not establish that the signer is a safe, approved, or authorized counterparty for a given client's use case; that remains a separate authorization decision, and the open PR #2099 shows the "who verifies against what key" step still needs deployment-side correction in some configurations.

Is this the same risk as MCP tool poisoning?

The underlying mechanism (untrusted metadata reinterpreted as trusted instruction) is closely related, but the protocols, the objects, and the standards trackers differ. Controls built for one do not automatically cover the other; a deployment running both MCP-connected tools and A2A-discovered agents needs boundary enforcement and provenance checks on both metadata paths independently.

Can this be mitigated without disabling dynamic agent discovery?

Yes. None of the defenses listed above require abandoning dynamic discovery. Boundary enforcement between card data and LLM instruction context, verifier-side trust-root configuration, and periodic re-verification before high-value delegation all preserve the ability to discover and delegate to new agents dynamically, while narrowing what an unverified or malicious card can actually cause.

Sources

Verification and change history

Standards and versions referenced: A2A Protocol Specification, version 1.0.x (current as of 2026-09-22); OWASP Top 10 for Agentic Applications, Version 2026 (December 2025); CWE-863; CWE-347.

Last verified: 2026-09-22. The Keysight attack description, the CSA MAESTRO threat ratings, the A2A specification's card-signing section, the GitHub pull request's description of the CWE-863 gap and its open status, the Linux Foundation and Google Open Source Blog governance and version-history details, and the OWASP guide's existence were read from the sources' own pages on this date.

Change history: 2026-09-22, first version.

Working-term label: Mixed provenance. "Agent Card Poisoning" is a Keysight industry/research term for the metadata-injection variant. T3.1 and T3.4 are Cloud Security Alliance MAESTRO threat-model terms for the spoofing and impersonation variant. CWE-863 and CWE-347 are Standard Terms owned by MITRE. ASI06:2026 and ASI07:2026 are Standard Terms owned by OWASP. This article's bundling of both variants under one entry, and its framing of the open specification pull request as a documented trust-root gap, are SSA editorial synthesis, not attributed to the sources above.