The published research that surveys this field describes an early A2A: one static file, no TTL, no signing.[2]
That snapshot was accurate when written and is now two releases stale. Reading A2A honestly in 2026 means reading the shipped specification, not the paper’s summary of it — and the shipped specification tells a more interesting story than “simple discovery card.” A2A tried to become a trust layer. Watching where that effort succeeds and where it stops is the cleanest possible introduction to the line this entire arc walks.
What A2A Actually Shipped
Start with the record, because it matters. A2A reached version 1.0.0 in 2026 under the Linux Foundation, with a specification whose normative source is a Protocol Buffers definition, a public repository past 24,000 stars and 580-plus commits across eleven releases, and stated support from more than 150 organizations including native platform integrations at the major clouds.[1][3] This is not an unshipped scaffold. It is one of the most broadly adopted agent-interoperability standards in existence. Any teardown that treats it as a toy is arguing with a version that no longer exists.
The current Agent Card is still a JSON document resolved at a well-known path — now /.well-known/agent-card.json, the earlier agent.json preserved only as a legacy anchor.[1] It still carries identity, skills, endpoint, and security schemes. But three additions move it decisively past the static-file phase the survey placed it in.
| Property | Commonly cited A2A (survey snapshot) | A2A v1.0 as shipped |
|---|---|---|
| Well-known path | /.well-known/agent.json | /.well-known/agent-card.json (old path legacy) |
| Card signing | None (plain JSON over HTTPS) | AgentCardSignature — JWS over JCS-canonicalized card |
| Authorization | Not addressed | In-task authorization + authorization scoping |
| Auth schemes | Optional bearer token | OAuth2, OIDC, mutual TLS, API key |
| Versioning | None | Per-request A2A-Version negotiation |
| Extended card | None | Authenticated extended Agent Card |
First, the card can be signed. The specification defines an AgentCardSignature using JSON Web Signatures computed over a canonicalized form of the card.[1] A consumer can now verify that the card was published by the holder of a particular key and that its bytes have not been altered in transit. This is a real cryptographic guarantee, and it is exactly the guarantee the survey’s snapshot said A2A lacked.
Second, authority is addressed, not merely described. The spec defines in-task authorization, authorization scoping on task access, and a full set of standard security schemes — OAuth2, OpenID Connect, mutual TLS.[1] Task listing must be authorization-scoped so a client sees only tasks it is permitted to see. The card is no longer silent on who may do what.
Third, the record is no longer strictly static. Version negotiation happens per request through an A2A-Version header; an authenticated client can fetch an extended Agent Card richer than the public one; caching rules are specified rather than left to HTTP defaults.[1] The single-clock, single-document model has loosened.
So the honest 2026 reading is not “A2A is a simple card that never tried.” It is: A2A climbed the evolution ladder the prologue described — from static self-description toward verifiable, federated trust — and got a real distance up it. That makes it the ideal first specimen, because it shows the ladder is real and then shows exactly where the climb stops.
Where the Climb Stops
Here is where it stops, and it is the same wall the AgentFacts teardown isolates. A signature over the Agent Card proves two things: who published the card, and that the bytes are intact. It does not tell you which keys to trust — and the A2A specification is deliberate about this. It does not define key-trust decisions, leaving them to the consumer’s threat model. That is the correct engineering choice; no protocol can decide your trust anchors for you. But it means the signature is a notarization, not a verification. A validly signed Agent Card can advertise a capability the agent does not actually possess, a certification it was never granted, an authorization scope wider than anything an enterprise approved — and the signature will check out perfectly, because the signature was never a claim about truth. It was a claim about authorship and integrity.
Read against the five Substrate Fitness Criteria, A2A v1.0 scores far better than its stale reputation and still leaves the decisive question open.
Discoverability — strong. A well-known path, a self-describing capability and skills schema, declared interfaces, and version negotiation.[1] Discovery is what A2A was built for and what it does best. The extended-card mechanism even lets an authenticated caller discover more than the public card exposes.
Context integrity — partial, and improved. The static file with no freshness signal is no longer the whole story: version negotiation and specified caching rules give a consumer more basis to know whether the card is current.[1] But there is still no TTL on the endpoint itself and no live-state guarantee. Under rapid endpoint movement, drift is reduced, not eliminated.
Action authority — partial. This is the largest change from the survey’s snapshot. In-task authorization and authorization scoping mean authority is now addressed within the protocol.[1] What the card still does not do is bind a verified capability to identity — it declares security schemes and scopes access, but the binding between “this agent is authorized for X” and “this agent verifiably is what it claims” runs through keys whose trust the protocol explicitly declines to establish.
Permissioning — partial. Authorization scoping and standard OAuth/OIDC/mTLS schemes are real permissioning surface.[1] The gap is revocation: the card can be re-signed and re-fetched, but there is no independent, sub-second revocation path decoupled from the card’s own refresh — the kind of governance-clock revocation an enterprise needs when trust breaks mid-flight.
Provenance — partial. The JWS signature is genuine provenance of authorship and integrity.[1] It is not provenance of truth: the spec does not establish which issuers to trust, and there is no third-party attestation model binding a claim to an accountable verifier. The card proves who wrote it, not whether what they wrote is so.
| Criterion | Rating | Basis |
|---|---|---|
| Discoverability | Strong | Well-known path, self-describing schema, declared interfaces, version negotiation |
| Context integrity | Partial | Caching rules + version negotiation reduce drift; still no endpoint TTL or live-state guarantee |
| Action authority | Partial | In-task authorization + scoping added; no binding of verified capability to identity |
| Permissioning | Partial | OAuth2/OIDC/mTLS + scoping; no independent governance-clock revocation |
| Provenance | Partial | JWS proves authorship + integrity; spec declines to establish issuer trust — notarization, not verification |
The Honest Accounting
The accounting runs both directions, and the credit is larger than the field’s conventional read allows. A2A is not a naive discovery format. It is a widely adopted, actively governed standard that recognized the trust gap and built real cryptographic and authorization machinery to close part of it. An enterprise can do meaningful governance with signed cards, scoped authorization, and standard auth schemes. What it cannot do — what A2A by explicit design does not attempt — is convert a signed capability claim into a verified one, or revoke authority on a governance clock independent of the card’s refresh. A2A climbed from “where is this agent and what does it say it does” to “who published this description and what may the caller do” — a real ascent. It stops short of “can I prove what this agent was verified and authorized to do, and stop it when that verification is withdrawn.” That final step is alignment-grade assurance, and it is the step every format in this arc reaches for and none, so far, completes.
A signature over the Agent Card proves who published it and that the bytes are intact. It does not prove that the capability, certification, or scope the card claims is true.
A2A climbed from “where is this agent and what does it say it does” to “who published this description and what may the caller do.” It stops short of “can I prove what this agent was verified to do, and revoke it when that verification is withdrawn.”
