--- title: "A2A v1.0 §8.4 in practice: 1,211 alive agents, 8 % signed" date: 2026-05-18 summary: "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." slug: a2a-signed-cards-adoption-measurement author: "Sebastiaan Hilbers" hero_glyph: funnel kind: research --- The A2A v1.0 specification was released on [12 March 2026](https://github.com/a2aproject/A2A/releases/tag/v1.0.0) and donated to the [Linux Foundation](https://lfaidata.foundation/) shortly after. Section 8.4 of the [specification text](https://a2a-protocol.org/latest/specification/#84-agent-card-signing) defines how an AgentCard is digitally signed using [JSON Web Signature (RFC 7515)](https://tools.ietf.org/html/rfc7515), canonicalised via [RFC 8785 (JCS)](https://tools.ietf.org/html/rfc8785). 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](https://agenstry.com/reports/state-of-agent-economy) under section 1 "Supply funnel", and verifiable by anyone running the same RFC 8785 + RFC 7515 sequence against the [Linux Foundation A2A registry](https://github.com/Linux-Foundation/a2aregistry). This post is not a complaint about the spec design. We [already wrote that one](https://agenstry.com/blog/a2a-signed-cards-key-not-identity) — 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](https://github.com/Linux-Foundation/a2aregistry/blob/main/docs/submitting.md) 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](https://docs.cdp.coinbase.com/x402/docs/discovery) 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`](https://cryptography.io/) library generates one in three lines of Python). The [Node.js jose library](https://github.com/panva/jose) and the [Go jwx library](https://github.com/lestrrat-go/jwx) both ship ready-to-use `JWS` + JCS implementations. - A [JWKS endpoint](https://datatracker.ietf.org/doc/html/rfc7517) 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](https://tools.ietf.org/html/rfc8785) — most JSON libraries' `sort_keys=true` + compact separators produces byte-identical output for ASCII-keyed cards. The [A2A Python SDK](https://github.com/a2aproject/a2a-sdk-python) ships a working sign helper in [`a2a/cards/signing.py`](https://github.com/a2aproject/a2a-sdk-python/blob/main/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](https://github.com/Linux-Foundation/a2a-compose) 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](https://developers.cloudflare.com/ai-gateway/), Vercel's [AI SDK](https://sdk.vercel.ai/)) 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](https://digital-strategy.ec.europa.eu/en/policies/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](https://agenstry.com/reports/state-of-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 - [A2A v1.0.0 release](https://github.com/a2aproject/A2A/releases/tag/v1.0.0) — A2A Project, 12 March 2026. - [A2A v1.0 specification, §8.4 Agent Card Signing](https://a2a-protocol.org/latest/specification/#84-agent-card-signing) — Linux Foundation, March 2026. - [RFC 7515 — JSON Web Signature](https://tools.ietf.org/html/rfc7515) — IETF, May 2015. - [RFC 7517 — JSON Web Key](https://datatracker.ietf.org/doc/html/rfc7517) — IETF, May 2015. - [RFC 8785 — JSON Canonicalization Scheme](https://tools.ietf.org/html/rfc8785) — IETF, June 2020. - [a2aregistry submission documentation](https://github.com/Linux-Foundation/a2aregistry/blob/main/docs/submitting.md) — Linux Foundation, retrieved 2026-05. - [A2A Python SDK signing helper](https://github.com/a2aproject/a2a-sdk-python/blob/main/a2a/cards/signing.py) — A2A Project, retrieved 2026-05. - [Coinbase CDP Discovery API](https://docs.cdp.coinbase.com/x402/docs/discovery) — Coinbase, retrieved 2026-05. - [Agenstry: card-to-key vs key-to-identity critique](https://agenstry.com/blog/a2a-signed-cards-key-not-identity) — Sebastiaan Hilbers, 19 May 2026. - [State of the Agent Economy — live signed-card funnel](https://agenstry.com/reports/state-of-agent-economy) — Agenstry, live. ## Cite this post ```bibtex @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} } ```