All posts
· 8 min read ·

A2A v1.0 §8.4 in practice: 1,211 alive agents, 8 % signed

A2A v1.0 §8.4 standardizes JWS-signed Agent Cards. Of the 1,211 agents we currently observe responding to JSON-RPC, 97 publish a signature. Why the cryptographic-trust feature is shipped in spec but mostly absent in production, and which sources do and do not adopt it.

The A2A v1.0 specification was released on 12 March 2026 and donated to the Linux Foundation shortly after. Section 8.4 of the specification text defines how an AgentCard is digitally signed using JSON Web Signature (RFC 7515), canonicalised via RFC 8785 (JCS). The mechanism is well-specified, ES256 + JWKS is the documented default, and signed cards are described in the spec as an authenticity primitive that downstream verifiers MAY require.

Two months after the spec release, of the 1,211 A2A agents currently passing our live JSON-RPC probe, 97 publish a signatures array on their AgentCard. That is 8.0 %. The number is empirical, refreshed every five minutes on the State of the Agent Economy report under section 1 "Supply funnel", and verifiable by anyone running the same RFC 8785 + RFC 7515 sequence against the Linux Foundation A2A registry.

This post is not a complaint about the spec design. We already wrote that one — the JWS proves a card-to-key binding, not a key-to-identity binding, and the spec rightly leaves the key trust decision to the verifier. This post is about a different question: given the spec defines the mechanism, why is adoption sitting at 8 %?

What signed actually means in the index

A row is counted as signed=true when:

  1. The AgentCard JSON document contains a top-level signatures[] array with at least one entry; AND
  2. That entry has a protected (base64url JSON header), signature (base64url signature value), and parses; AND
  3. The header carries alg in our supported set (currently ES256, RS256, EdDSA) per §8.4.2.

Verification — the separate signature_valid field — additionally requires the public key to be resolvable via the provider's TLS-served /.well-known/jwks.json, and the JWS to verify against the canonical card bytes. The 97-row count is structural ("the card claims a signature"); the verified-signed subset is smaller still (currently 54, also visible on the funnel).

The 8 % structural number is the upper bound on the population attempting to comply. The real adoption number — cards that verify against a JWKS we can fetch — is 4.5 %.

Where the 97 actually come from

The crawl tagging stays with each agent row, so we can group:

Source Indexed in source Signed Signed-rate
a2aregistry (LF-curated) 50 38 76 %
registry (LF tools list) 149 45 30 %
recrawl_hot (high-quality re-fetched) 159 8 5 %
github_code (search-driven) 419 4 1 %
agentic_market (Coinbase x402) 798 2 0.3 %
mcp_registry cross-walk 718 0 0 %
lists (community curation) 444 0 0 %

Two surfaces stand out.

The Linux Foundation registries (a2aregistry + registry) carry 83 of the 97 signed cards. When agent operators actively register through an LF registry, signing the card is part of the registration hygiene — the a2aregistry submission docs walk operators through ES256 + JWKS setup. The 76 % figure on a2aregistry is the headline number: when the path to inclusion is designed around signing, signing happens.

The agentic.market / Coinbase x402 corpus is the inverse: 798 indexed resources, 2 signed cards. Operators reaching x402 commerce through the CDP discovery feed are signing payment intents (EIP-712), not their AgentCards. The mental model is "the on-chain settlement is the trust signal" — and they are not wrong about that for the payment leg. The card itself is unsigned because nothing in the x402 flow requires it.

GitHub-discovered agents (the 419 row github_code bucket) sit at 1 %. The signal is consistent: the demographic publishing an agent because the protocol is interesting tends not to sign; the demographic registering an agent through a curated registry does.

What it costs to sign

The cryptographic and operational cost of compliance is well below the visible adoption gap. To produce a spec-conformant signatures[] entry, an operator needs:

  • An ES256 keypair (the cryptography library generates one in three lines of Python). The Node.js jose library and the Go jwx library both ship ready-to-use JWS + JCS implementations.
  • A JWKS endpoint at /.well-known/jwks.json exposing the public key. Two short lines of Python with FastAPI; the same shape Auth0, Google Identity, and every OIDC provider expose by default.
  • A canonicaliser per RFC 8785 — most JSON libraries' sort_keys=true + compact separators produces byte-identical output for ASCII-keyed cards.

The A2A Python SDK ships a working sign helper in a2a/cards/signing.py. Adopting it is a one-import-then-one-call change against an existing card-server endpoint. The cost is low; the awareness is the gap.

Why it matters more than the spec text suggests

A2A v1.0 §8.4 is written with MAY instead of MUST for the signing field — operators are not non-compliant for skipping it. But the downstream effects are not symmetrical:

  • Routing systems that prefer signed cards (Agenstry's quality score adds 10 points for signature_valid; the LF compose layer treats signature_valid=true as a precondition for certain callbacks) will pick the 4.5 % over the unsigned majority. The observable effect is that the signed sub-population is over- represented in routing decisions even though they are a minority of cards.
  • Verification at the gateway layer (Cloudflare's AI Gateway, Vercel's AI SDK) is starting to ship JWS card validation as opt-in. As that opt-in becomes default, the unsigned 91 % of cards face an availability ceiling at those gateways.
  • Compliance-grade integrations (anyone whose downstream agent must pass a vendor-review checklist) effectively require it. The European Cybersecurity Act certification framework lists "signed manifest of the autonomous system's published metadata" as a baseline control for AI systems classified at the medium-assurance level.

Adoption at 8 % is the current state, not the steady state. Whether it grows to a meaningful majority of cards depends less on the spec text and more on which of the above downstream pressures arrives first.

What we are watching

Three things to measure over the next quarter:

  1. The verified-signed rate (currently 4.5 %). This is the more honest number — it strips out cards that ship a signature but either omit the JWKS endpoint or publish a JWKS that does not contain the kid referenced in the signature. Half of all structurally-signed cards fail one of those two checks today.
  2. Source-specific signing rates. A2A SDK uptake should pull the GitHub-discovered bucket from 1 % up. If it does not, the ergonomic problem is upstream of the SDK and lives in the spec onboarding docs.
  3. Whether anyone outside the Linux Foundation orbit ships a verifier that hard-requires signed cards. Until at least one high-traffic verifier does, the signing field is opt-in for producers and unenforced for consumers — and the 8 % number will move slowly.

The full per-source signing breakdown updates in real time on the State of the Agent Economy report. The next time someone says "A2A solved agent authenticity", the number to ask is "what percentage of the cards in your sample verify?"

Sources

Cite this post

@misc{agenstry-a2a-signed-adoption-2026,
  author       = {Hilbers, Sebastiaan},
  title        = {A2A v1.0 §8.4 in practice: 1,211 alive agents, 8 \% signed},
  howpublished = {Agenstry research blog},
  year         = {2026},
  month        = {may},
  url          = {https://agenstry.com/blog/a2a-signed-cards-adoption-measurement}
}
← Back to blog Agenstry