A2A’s Signed Agent Cards Prove Integrity, Not Identity

A2A v1.0 shipped with a feature called Signed Agent Cards, and the pitch going around is that it stops fake agents by cryptographically verifying a card was issued by its claimed domain owner. That's not what the signature does, and the gap between the pitch and the mechanism matters if you're deciding whether to let an agent act on a card you just discovered.

In this article:

• What's actually inside a Signed Agent Card
• How the JWS and canonicalization signing flow works
• What the signature proves, and the identity gap it leaves open
• The open GitHub proposal showing real identity verification still isn't solved
• Multi-tenancy, the new protocol bindings, and what to decide before you trust a card

What a Signed Agent Card Actually Contains

An Agent Card is the JSON manifest an A2A agent publishes at /.well-known/agent-card.json, and it's how a calling agent discovers what another agent can do before sending it a task [1]. The card lists required fields such as name, version, supportedInterfaces, and skills, plus optional ones like a provider block, security schemes, and an icon [2]. None of that is new in v1.0. What's new is a signatures array that can carry one or more JSON Web Signature values over the card's contents [1].

That array exists because the card is passed around more than you'd expect. It gets cached, mirrored into registries, and handed across organizational boundaries before an agent ever sees it, and at each hop something could rewrite the interface URL or swap a security scheme [3]. The same discovery problem shows up on the MCP side, where I've written about agents calling the wrong tool because the tool's description didn't match what it actually did. A signed card is A2A's answer to a related but sharper version of that problem: not "did the agent misread this," but "did someone else rewrite it."

The Signing Mechanism: JWS Over a Canonicalized Payload

The actual signing stack is two IETF specs stacked on top of each other. The card's contents, including capability flags like extendedAgentCard and pushNotifications, get run through RFC 8785's JSON Canonicalization Scheme first, which produces one deterministic serialization regardless of key ordering or whitespace in the original [4]. That canonical form, with the signatures field itself excluded, is what actually gets signed under RFC 7515's JWS [1][5].

In practice this looks like calling something such as create_agent_card_signer with a private JWK and a protected header that names an algorithm (commonly ES256), a key ID (kid), and often a jku pointing at a JWKS URL [6]. Verification mirrors that: a verifier takes a key provider and an algorithm allow-list, fetches the right public key by kid, and either confirms the signature or raises an error. A card with zero signatures gets rejected outright once a verifier is configured [6].

What the Signature Proves, and the Identity Gap It Leaves Open

Here's the part that gets flattened in a lot of the coverage: a valid signature tells you the card hasn't been altered since it was signed, and that whoever holds the private key produced it. It does not tell you that the key belongs to the domain the card claims, that the agent behind it is safe, or that it's approved for your tenant [3]. One card-signing implementation puts it almost exactly that way: the signature "binds the card's contents to a key the client already trusts," which quietly pushes the actual trust decision onto you, the verifier, not onto the protocol [6].

That's a meaningfully smaller guarantee than "verified domain owner." The jku field is just a URL the card itself supplies, so a verifier that blindly fetches whatever jku a card hands it has learned nothing about identity, only that the card matches a key found at an address the card also controls [3]. A real trust decision requires a separate, pre-established policy: which issuers you accept, how you obtained their keys out of band, and what you do when a key needs to be revoked [3]. None of that is new protocol machinery. It's the same kind of guardrail work I covered when prompt injection stopped being theoretical: the attack surface moves to wherever the system assumes trust it hasn't actually earned.

The Open Proposal That Shows Real Identity Verification Still Isn't Solved

If signed cards already closed the identity gap, there wouldn't be an open GitHub issue proposing to close it. In March 2026, a developer filed issue #1672 against the A2A spec repository arguing that "identity verification is currently left to external mechanisms," and that transport-layer trust like TLS and OAuth secures the connection, not the claim about who's on the other end of it [7]. The proposal suggests an optional verifiedIdentity field carrying an agent ID, a certificate, an issuer, and a verification endpoint, separate from the card-signing mechanism entirely, with a reference implementation built on ECDSA P-256 certificates and a verification API [7].

As of this writing the issue is open, with no maintainer response, no linked pull request, and no milestone attached [7]. That status is itself the useful signal: the people closest to the spec haven't agreed on how an agent should prove its identity, only on how a card can prove it wasn't tampered with in transit. If your production system is making authorization decisions based on an agent card, that's the exact failure mode worth logging and alerting on, the same category of gap I walked through in what to log before your agent fails in production: not just whether a call succeeded, but whether the thing you trusted to make the call was ever actually who it said it was.

Multi-Tenancy, the New Protocol Bindings, and What to Decide Before You Trust a Card

Signed cards weren't the only addition in v1.0. The spec added a tenant field to request messages and to AgentInterface, letting one endpoint serve multiple agents and route by tenant instead of by URL path alone [1][3]. gRPC gained native tenant scoping, and a2a.proto became the normative source of truth across all three bindings (JSON-RPC, gRPC, and JSON+HTTP) instead of being a gRPC-only artifact [1][8]. None of that is a security feature by itself. The same API7.ai writeup that covers tenant routing is explicit that an echoed tenant value is "opaque," decided entirely by the server, and creates an insecure direct-object-reference risk if it isn't bound to the authenticated caller rather than just trusted at face value [3].

Put together, v1.0's security story is less "fake agents are now impossible" and more "here are two new pieces of untrusted input (a signed card, a tenant claim) that your system still has to validate against a policy you write yourself." That's roughly the same lesson behind the missing approval gate in the OpenAI Medicare Australia incident: a protocol feature that looks like a safety control isn't one until something downstream actually checks it against a real policy, with real consequences for failing that check. If you're building on A2A today, the actionable move isn't "turn on signature verification and move on." It's deciding up front which issuers you'll accept, how you'll obtain their keys outside of whatever the card itself offers you, and what happens the moment a key needs to be revoked, before an unsigned or wrongly-signed card ever reaches a decision point in your system.

Sources

1. What's New in v1.0 (A2A Protocol)
2. A2A Agent Cards (specification.website)
3. A2A Protocol 1.0 at the Gateway: Identity, Tenant Routing, and Signed Agent Cards (API7.ai)
4. RFC 8785: JSON Canonicalization Scheme (JCS) (IETF)
5. RFC 7515: JSON Web Signature (JWS) (IETF)
6. Card Signing (AG2 Documentation)
7. Proposal: Agent Identity Verification for Agent Cards, Issue #1672, a2aproject/A2A (GitHub)
8. A2A Protocol Ships v1.0: Production-Ready Standard for Agent-to-Agent Communication (A2A Protocol)

If you enjoyed the article and wish to show your support, make sure to:

• 👏 Give a round of applause (50 claps) to help get featured
• 👥 Follow me on Medium to stay updated with my latest content
• 📰 Explore more articles on my Medium Profile
• 🔔 Connect with me on LinkedIn, Twitter, and Instagram