# Your agent's identity is a JSON file the protocol only optionally lets you sign.

A team is wiring an agent into an A2A network so other agents can find it and route work to it. Discovery in the Agent2Agent protocol runs through an Agent Card: a JSON document the agent publishes at a well-known URL, describing its identity, its capabilities, its skills, its service endpoint, and the authentication it requires. Another agent fetches that card, reads which capabilities are on offer, and decides whether to send a task. The team fills in the card carefully — accurate skills, the right endpoint, an honest capability list — and ships it. The mechanism is exactly the one the specification documents, and the team has done discovery correctly.

The trouble is what the card is _not_ required to carry. The Agent Card is the document everything downstream trusts — task routing reads it, capability negotiation reads it, the deciding agent acts on it — and the A2A specification makes the one field that would prove the card is genuine optional. Signing the card is, in the spec's own normative language, something a server **MAY** do. Not **MUST**. The default Agent Card, the one a conformant server publishes and a conformant client will act on, is unsigned. An agent's entire advertised identity is a JSON file, and the protocol only optionally lets you sign it.

This post is about that one word and its blast radius: what "MAY sign" means at the level of RFC-2119, why an unsigned capability advertisement is exactly the artifact attackers forge to hijack routing, why three separate research groups flag the A2A card as unsigned-by-default, why a third party has had to bolt cryptographic trust onto the card from outside the protocol, and what the claim does — and does not — say.

## "MAY" is a normative word, and it is the load-bearing one

Read the spec literally, because the whole argument turns on one keyword. The A2A specification has a section on Agent Card signing that defines a complete JWS-based scheme. The question is not whether A2A _can_ express a signed card; it plainly can. The question is whether the protocol _requires_ one, and the answer is in the keyword the spec chose.

The [_Agent2Agent (A2A) Protocol Specification_](https://a2a-protocol.org/latest/specification/) says: "Agent Cards **MAY** be digitally signed using JSON Web Signature (JWS) as defined in RFC 7515 to ensure authenticity and integrity. Signatures allow clients to verify that an Agent Card has not been tampered with and originates from the claimed provider." In RFC-2119 terms, **MAY** is the weakest word in the vocabulary — it marks something truly optional, which a conformant implementation may omit entirely. The spec did not write **MUST**, or even **SHOULD**. The thing that proves a card "has not been tampered with and originates from the claimed provider" is optional by the protocol's own grammar.

The schema says it again. The AgentCard field table types its authenticity field, `signatures`, as an array of `AgentCardSignature`, described only as "JSON Web Signatures computed for this AgentCard" — and marks its Required column **No**. The protocol's only authenticity primitive is non-required in the very schema that defines the card. There is no reading under which a signed card is the default — the default card carries an absent `signatures` field and is fully conformant.

You might hope client-side verification closes what the producer side left open. It does not, on two counts. The verification text is itself only a **SHOULD**: "Clients **SHOULD** verify at least one signature before trusting an Agent Card." **SHOULD** is advisory, and it is moot for the default card anyway — an unsigned card has no signature to verify, so a client that "verifies signatures when present" verifies nothing and trusts the card. And trusts it for routing: the spec tells clients only that they "**SHOULD** validate capability support by examining the Agent Card before attempting operations that require optional capabilities." Examine the card, read the capabilities, act — no signature is required anywhere in that loop. The unsigned-by-default document is precisely what task routing consults, and nothing in the normative path makes its authenticity a precondition for acting on it.

## An unsigned capability advertisement is the thing attackers forge

A protocol gap matters only if it has a blast radius, so look at what the security literature does with an unsigned card — it treats it as the prime attack surface for discovery.

[_Security Analysis of Agentic AI Communication Protocols: A Comparative Evaluation_](https://arxiv.org/abs/2511.03841) (arXiv 2511.03841), an empirical comparative analysis across a 14-point vulnerability taxonomy, names the A2A mechanism without hedging: "In A2A, this vulnerability is particularly evident through tampering with Agent Cards, which are JSON-based metadata documents broadcast across peer-to-peer networks without mandatory end-to-end signing. This omission enables adversaries to forge capabilities, inject false endpoints, or impersonate trusted agents during dynamic discovery." Read the causal chain: _without mandatory end-to-end signing_ → _forge capabilities, inject false endpoints, impersonate trusted agents_. The missing mandate is the cause; capability forgery and impersonation are the effect — the thesis, from an analysis that owes it nothing.

And it is measured. The same paper reports "up to 70% success rates in peer-to-peer discovery spoofing scenarios" — the success rate of lying in an unsigned document nobody is required to verify, not of an exotic cryptographic break. The paper draws the routing consequence too: without cryptographic signing, these mechanisms "become prime targets for deception, enabling malicious agents to insert themselves into workflows and redirect communications toward attacker-controlled infrastructure." Inserting a malicious agent into a workflow and redirecting traffic _is_ hijacking task routing — the unsigned card is the lever.

The paper generalizes to a sibling protocol: "ACP's architectural flexibility, most notably its optional JWS enforcement, translates into high-impact integrity and confidentiality flaws." Optional JWS enforcement is exactly what A2A's "MAY sign" is. None of this is the A2A-versus-MCP role split that [the two protocols' division of labor](/blog/a2a-vs-mcp/) turns on; it is one sentence of the A2A spec and where it leads.

## Three research groups, independently, call the card unsigned-by-default

One paper is a finding; three independent groups converging is a property of the protocol. Separate threat-modeling efforts, on different frameworks, land on the same sentence.

[_Building A Secure Agentic AI Application Leveraging Google's A2A Protocol_](https://arxiv.org/abs/2504.16902) (arXiv 2504.16902) models A2A with the MAESTRO framework and names Agent Card threats directly. The first is Agent Card Spoofing: an attacker "publishes a forged /.well-known/agent.json (Agent Card) at a malicious or typosquatting domain," a discovering client "may trust this fake card and send sensitive A2A Tasks to a rogue A2A Server," and the result is "task hijacking, data exfiltration, and agent impersonation." The paper rates a compromised card hijacking task execution as "Likelihood: High (open Agent Card discovery, multi-vendor federation)" — that parenthetical is the ecosystem-scale condition that turns an optional signature into a likely compromise.

The paper makes the point this post most needs: its recommended _fix_ is the thing the spec made optional — "Digital Signatures on Agent Cards: Use digital signatures via a trusted Certificate Authority (CA) to ensure authenticity and integrity." When the analysis of a protocol recommends, as its remedy, the mechanism the protocol declined to require, that is the gap named from the other side.

A third group reaches the same place through another framework. [_Security Threat Modeling for Emerging AI-Agent Protocols: A Comparative Analysis of MCP, A2A, Agora, and ANP_](https://arxiv.org/abs/2602.11327) (arXiv 2602.11327) applies a NIST-SP-800-30 framework and rates each control as mandatory, optional, or non-existent — the exact axis this post turns on. Its Creation/Configuration table states it plainly: "The A2A agent card and negotiation parameters are not cryptographically signed ... in weak configurations, tampering becomes more likely." And it ties the unsigned, self-declared card straight to misrouting: "Agent identity is self-declared using the Agent Card with no global uniqueness enforcement," so "a wrong agent card could misroute tasks" — routing hijack traced to the card.

The same paper names the missing control precisely: "OAuth2/JWT authenticates transport, but agent-card/task claims lack mandatory issuer-bound provenance," so "unverified claims can misroute tasks." Mark the word _mandatory_. The transport is authenticated; the _card's claims_ are not. Authenticating the pipe is not authenticating the claim that flows through it. That is why the unsigned card sits upstream of the whole [identifier-plus-credential-plus-authorization identity stack](/blog/agent-identity-stack/): if the discovery artifact that bootstraps that stack is unsigned, every layer above inherits a claim no one checked.

## A third party had to bolt the trust on from outside

The clearest evidence that the protocol left a gap is that someone outside it has built a layer to fill it. If "MAY sign" were sufficient in practice, no one would retrofit signing — someone did.

[sigstore/sigstore-a2a](https://github.com/sigstore/sigstore-a2a) is an official Sigstore-org library and CLI whose own description states its purpose: "A Python library and CLI tool for keyless signing of A2A (Agent-to-Agent) AgentCards using Sigstore and SLSA provenance attestations." It signs the exact artifact A2A left optional, importing supply-chain trust to do it — keyless signing through a CA, SLSA provenance linking a card to the source repository that produced it, and a public transparency log so that "this creates a permanent, tamper-evident record of your Agent Card's provenance." That is the provenance the analyses said was missing — added by a third party, not the protocol. The project's framing is the tell: it calls "Agent Card verification ... a critical component of the A2A security model." A third-party tool calls card verification _critical_; the protocol rates the mechanism that enables it "MAY." The trust the spec declined to require is supplied from outside it.

## What the claim does — and does not — say

Several qualifications, because the version that overstates loses the reader who knows the protocol.

The retrofit is not production-ready, and pointing at it is not a solution. The sigstore-a2a README is blunt: it is "Prototype code - not for production use. Code is not reviewed and has not undergone a security audit." That cuts both ways — an unaudited prototype is what "still improvising the authenticity layer the spec didn't mandate" looks like, but a team cannot read this as "adopt sigstore-a2a and you're done." The gap is real and the fix is still forming.

The transport is genuinely authenticated, and the claim is narrow. A2A is not an open door in general — endpoint-to-endpoint communication uses standard, mandatory mechanisms. The claim is specifically about the card's _claims_ — advertised identity and capabilities — not whether the connection is encrypted.

The gap is fixable inside the spec, not an unfixable flaw. The mechanism exists; the spec simply makes using it optional, so closing it requires no new standard — only a stronger keyword and the discipline to sign and verify. [_Improving Google A2A Protocol: Protecting Sensitive Data and Mitigating Unintended Harms in Multi-Agent Systems_](https://arxiv.org/abs/2505.12490) (arXiv 2505.12490) frames the whole class as one of enforcement level rather than missing capability: "unlike existing security recommendations that remain optional or are implemented at the application layer," it presents how to enforce these mechanisms "at the protocol level ... tailored for decentralized multi-agent environments." The defect is the optional posture, not an absence — and that posture is not free, since "relaxing such controls can open avenues for data exfiltration and privilege escalation." The AgentCard is "at the core of this protocol," so leaving its authenticity optional is the load-bearing gap, not a peripheral one.

## What to demand of an A2A deployment

You cannot inherit the spec's default and call the result trustworthy, because that default is an unsigned identity. Promote signing to "MUST" in your own deployment, and refuse to route on unverified cards.

**Treat an unsigned Agent Card as untrusted, and turn "MAY sign" into "MUST sign."** The spec lets a client trust an unsigned card; your client must not. Sign every card you publish and verify every card you consume, making a verified signature a precondition for reading capabilities off a card and routing a task to its endpoint. Across a federation you do not control, reject unsigned cards rather than fall through to trusting them — the conformant client's default failure mode.

**Authenticate the card's claims, not just the transport.** OAuth and TLS authenticate the pipe, not whether the advertised identity and capabilities are genuine. Demand issuer-bound provenance for the card itself, so a forged or typosquatted card over a valid TLS connection still fails — the threat model's "lack of mandatory issuer-bound provenance" is the hole to plug.

**Red-team the forged card explicitly.** The test is not "is the connection encrypted" but "can an attacker publish a card that inflates capabilities or impersonates a trusted agent, and will my router send it a task." Run that attack against your own discovery, and require that signature verification is what refuses.

**Pin trust at marketplace scale, because open discovery is the danger condition.** The papers rate card compromise High under "open Agent Card discovery, multi-vendor federation." At that scale, an allowlist of trusted issuers, a transparency log, or source-bound provenance is the substitute for the mandate the protocol declined to make — an on-chain registry like [ERC-8004's identity registry](/blog/erc-8004-agent-identity/) is one way to give that pinned trust a censorship-resistant home.

**Track the retrofit honestly.** Signing layers like sigstore-a2a show the shape of the fix — keyless signing, SLSA provenance, a public transparency record — but they are prototypes. Adopt the shape and build it at the deployment layer; do not present an unaudited tool as a finished control.

## The checklist

Before you call an A2A deployment's agent identity trustworthy:

- [ ] Unsigned Agent Cards are treated as untrusted and not routed to, rather than trusted by default as the spec permits.
- [ ] Every card you publish is signed, and every card you consume carries a verified signature before any capability is read off it.
- [ ] The card's _claims_ — advertised identity and capabilities — are authenticated with issuer-bound provenance, not just the transport channel.
- [ ] A forged or capability-inflated card is an explicit red-team case, refused by signature verification rather than model judgment.
- [ ] Trust at federation scale is pinned — trusted issuers, a transparency log, or source-bound provenance — because open multi-vendor discovery is the High-likelihood condition.
- [ ] Any external signing retrofit in use is treated as the still-forming layer it is, not an audited, finished control.

## Reading list

- [_Agent2Agent (A2A) Protocol Specification_](https://a2a-protocol.org/latest/specification/) — the load-bearing fact: card signing is RFC-2119 "MAY", client verification only "SHOULD", and `signatures` is Required: No, so the default Agent Card ships unsigned.
- [_Security Analysis of Agentic AI Communication Protocols: A Comparative Evaluation_](https://arxiv.org/abs/2511.03841) (arXiv 2511.03841) — attributes A2A discovery spoofing to cards broadcast "without mandatory end-to-end signing" and reports up to 70% success in peer-to-peer discovery spoofing.
- [_Building A Secure Agentic AI Application Leveraging Google's A2A Protocol_](https://arxiv.org/abs/2504.16902) (arXiv 2504.16902) — a MAESTRO threat model naming Agent Card Spoofing, rating card-driven task hijacking High under open multi-vendor discovery, and recommending the digital signatures the spec leaves optional.
- [_Security Threat Modeling for Emerging AI-Agent Protocols: A Comparative Analysis of MCP, A2A, Agora, and ANP_](https://arxiv.org/abs/2602.11327) (arXiv 2602.11327) — a third group, rating controls mandatory/optional/non-existent, finds the A2A card not cryptographically signed and lacking mandatory issuer-bound provenance.
- [_Improving Google A2A Protocol: Protecting Sensitive Data and Mitigating Unintended Harms in Multi-Agent Systems_](https://arxiv.org/abs/2505.12490) (arXiv 2505.12490) — frames A2A's protections as optional or application-layer and proposes enforcing them at the protocol level, locating the defect in the optional posture.
- [sigstore/sigstore-a2a — Sigstore A2A Agent Signing](https://github.com/sigstore/sigstore-a2a) — an official Sigstore prototype bolting keyless signing and SLSA provenance onto Agent Cards from outside the protocol, calling card verification "a critical component of the A2A security model."

The team filled in its Agent Card exactly as the specification says and shipped a fully conformant document. What conformant did not mean is _signed_, because the spec's word for signing is "MAY" and the default card carries an empty `signatures` field. The Agent Card is the document task routing trusts: another agent fetches it, reads the capabilities, and sends work to the endpoint. Leave it unsigned and you have published your agent's identity and capability advertisement as a JSON file anyone can forge — which the security literature does, with up to a 70% spoofing success rate, to inflate capabilities, impersonate trusted agents, and redirect routing to attacker-controlled infrastructure. Three research groups call the card unsigned-by-default; a fourth party has had to bolt signing onto it from outside. The protocol can express a signed card perfectly well; it just declined to require one. Optional authenticity, at the scale an agent marketplace assumes, is no authenticity. Make signing mandatory in your own deployment, verify every card before you route to it, and stop trusting an identity nobody had to prove.