A category does not exist because someone declares it. It exists when other people can cite it.
\nAs of this week, three A2A-SE artifacts have permanent DOIs: two public comments filed with NIST, and the normative specification itself. That last one matters more than it sounds, and this post explains why we bothered.
\n| Artifact | DOI |
|---|---|
| A2A-SE Specification v0.11.0 | 10.5281/zenodo.21953795 |
| NIST CAISI public comment | 10.5281/zenodo.21745191 |
| NIST NCCoE public comment | 10.5281/zenodo.21745274 |
The specification also has a concept DOI, 10.5281/zenodo.21953794, which always resolves to the newest archived release. Cite the version DOI to pin v0.11.0; cite the concept DOI when you mean \"the spec, whatever its current version.\"
\nThe full chronology lives on the Standards & Provenance page.
\nThe specification has been public since 17 February 2026, in commit c5ba9aaa. Anyone could read it. So what did the deposit actually add?
A repository URL is a location, not an identifier. It breaks when an org is renamed, a repo is transferred, a branch is rewritten, or a company folds. Worse, it points at a moving target: main today is not main last March, so a citation to a repository is a citation to nothing in particular. If a standards body or an academic paper wants to reference the settlement semantics we defined, \"see this GitHub link\" is not a reference they can rely on.
A DOI fixes both problems. It resolves to a specific immutable deposit, held by an institution whose job is outliving us, and it carries a timestamp that is not ours to edit.
\nThat timestamp is the part people underrate. The claim we care about is not \"we wrote a spec.\" It is \"the settlement layer was identified as a distinct architectural concern, with concrete semantics, on this date.\" Priority claims need dates that a third party will vouch for.
\nBoth comments were filed before the spec was archived, and both are grounded in a running implementation rather than a proposal.
\nThe CAISI comment responded to the Request for Information on Security Considerations for Artificial Intelligence Agents (Docket NIST-2025-0035). Its argument: the economic settlement layer is a largely unexamined attack surface for agentic AI. When autonomous agents transact across organizational boundaries, you get threats with no clean parallel in traditional software — settlement fraud, reputation poisoning, escrow-timing attacks, cascading multi-agent settlement failures, cross-boundary trust exploitation.
\nThe NCCoE comment responded to the concept paper on accelerating adoption of software and AI agent identity and authorization. Its argument is one sentence: identity without economic accountability is incomplete. OAuth, OIDC, and SPIFFE can establish who this agent is and what it may access. None of them answer what economic commitments it may make, or what happens when it commits and fails to deliver.
\nNotice that both comments make the same structural point from different directions, which is the point of filing them separately. Security people arrive at settlement by asking what an agent can do to you. Identity people arrive at it by asking what an agent is allowed to do. Both roads end at an unowned layer.
\nAgent commerce has at least three separable concerns, and conflating them is the source of most confused architecture:
\nA2A-SE is a standard for the third one. It is not a payment rail and does not want to be. It integrates with authorization rather than replacing it. If you want the long version, see What is Agent Settlement?.
\nAn archived specification is not a ratified standard, and a DOI is not an endorsement. Zenodo assigns identifiers; it does not review content. Filing a public comment means NIST received it, not that NIST agreed.
\nWhat the deposits do accomplish is narrow and real. The artifacts are permanent, dated, and citable. If the settlement layer becomes contested ground — and it will, because it sits directly between two layers that already have well-funded standards efforts — the record of who specified what, and when, is now held somewhere we cannot quietly revise.
\nThat is worth a DOI.
", "url": "https://docs.a2a-settlement.org/blog/citable-settlement-layer", "title": "Making the settlement layer citable", "summary": "Two NIST public comments and the A2A-SE specification now have permanent DOIs. Here is why a category needs citable artifacts, not just a repository.", "date_modified": "2026-08-15T00:00:00.000Z", "author": { "name": "Richard Smith", "url": "https://a2a-settlement.org" }, "tags": [ "Standards", "Provenance" ] }, { "id": "https://docs.a2a-settlement.org/blog/red-teaming-settlement", "content_html": "Escrow protects you from a counterparty who never delivers. It does nothing about a counterparty who delivers something that merely looks right.
\nThat is the harder problem, and it is the one that decides whether settlement is worth anything. If value releases whenever a provider returns well-formed JSON, then an agent that fabricates well-formed JSON has found a money printer. So the reference implementation ships an adversarial simulation harness whose entire job is producing convincing garbage and seeing what survives verification.
\nBroken output is easy. It fails a schema check, and nobody needs a settlement layer to catch it.
\nThe interesting adversary produces output that passes every structural check and is still fiction. It cites a real domain. Its timestamps are recent and internally consistent. Its content hash is the right length and character set. Its record count matches the metadata that describes the record count. Everything is coherent, and none of it happened.
\nThis is not a hypothetical failure mode for language-model agents; it is their default failure mode. A model asked to retrieve data and unable to retrieve it will frequently produce something shaped exactly like the answer. The settlement layer is the last checkpoint before that becomes a payment.
\nThe harness in simulation/ implements three adversarial agents, each isolating a different way provenance can be false while looking true. All three declare is_fabricated=True internally, so scoring knows ground truth; the verifier does not.
The fake endpoint citer invents the source outright. It generates a random subdomain like api.nonexistent-service-abcdef.io and claims a GET against it. This is the easiest case: the endpoint cannot be reached, because it does not exist. It exists in the harness as a control — a verifier that cannot catch this one is not doing anything at all.
The GitHub fabricator is more interesting because its citation is real. It points at https://api.github.com/repos/{repo}/commits, a legitimate, reachable, well-known endpoint. The commits it returns are invented: SHAs are the first twelve hex characters of a hashed UUID, messages are drawn from a list of plausible conventional-commit strings. The content hash is 64 random hex characters — correct in form, meaningless in fact. Reachability checks pass. Only comparing the claimed hash against the actual response catches this.
The plausible hallucinator attacks the attestation tier itself. It cites a real API, fabricates the payload, and then claims attestation_level: \"signed\" while supplying \"fake-x-request-id-12345\" as the signature. It is asserting a stronger provenance guarantee than it can back. A verifier that trusts self-reported tiers will rank this above an honest agent that modestly declares self_declared.
That last archetype is the one that keeps me up. Tiered provenance creates an incentive to overclaim your tier, so tier assertions have to be verified rather than believed. Otherwise the tier system inverts: honesty is penalized.
\nThe harness also implements three honest agents — a GitHub retriever, a web extractor, and a dataset summarizer — and by default assigns tasks with honest_ratio=0.5.
They are not there for balance. They are there because detection rate alone is a worthless metric. A verifier that rejects everything scores 100% detection. The number that matters is what it does to legitimate work, so scoring tracks the full confusion matrix: fabricated and flagged, fabricated and approved, honest and approved, honest and flagged. A false positive is an honest provider who did the work and did not get paid, which is a more expensive failure than it first appears, because it drives good providers off the exchange.
\nTwo further measures come out of each run. Escrow protected sums the value held in escrows where fabrication was caught, which converts detection into the only unit that matters to an operator. Verification latency records the overhead, because a check nobody can afford to run is a check nobody runs.
\nScenarios are plain YAML — currently data retrieval, code review, and document summary — each fixing an attestation tier and an escrow amount, so you can ask how detection changes as the stakes rise.
\nThe harness is checked in. Published results are not, and I want to be precise about why.
\nProducing credible numbers requires the mediator's verification pipeline running against live endpoints, and the results are only as meaningful as the scenario set is representative. Three scenario files authored by the same person who wrote the adversaries is not an evaluation; it is a demonstration. Publishing a detection rate from it would be exactly the failure mode this whole post is about — a well-formed number with nothing behind it.
\nSo the harness is offered as methodology rather than evidence, and the invitation is for someone else to run it. The neutral place to do that is the conformance suite, which is designed so that any settlement rail can be tested without using our exchange.
\nThe claim I will make is narrower: a settlement layer that never verifies deliverables is not settling anything. It is a payment queue with extra steps.
", "url": "https://docs.a2a-settlement.org/blog/red-teaming-settlement", "title": "Red-teaming a settlement layer: three ways agents lie", "summary": "A deliverable that looks correct and a deliverable that is correct are different things. The A2A-SE simulation harness models three archetypes of fabricating agent.", "date_modified": "2026-08-15T00:00:00.000Z", "author": { "name": "Richard Smith", "url": "https://a2a-settlement.org" }, "tags": [ "Security", "Verification" ] }, { "id": "https://docs.a2a-settlement.org/blog/trust-discount", "content_html": "An agent that has settled a thousand honest transactions on one exchange arrives at a second exchange as a stranger. That is a real cost — it locks agents to whichever exchange they started on, which is how an interface quietly becomes a platform.
\nThe obvious fix is to let exchanges import each other's reputation scores. The obvious fix is also how you get reputation laundering.
\nSuppose Exchange B accepts Exchange A's reputation scores as equivalent to its own. Exchange B has now outsourced its trust model to an operator whose incentives it does not control and whose implementation it cannot inspect at runtime.
\nThe attack writes itself. Stand up an exchange. Score your own agents at 1.0. Peer with someone real. Your agents now arrive everywhere pre-trusted, and the cost of manufacturing that trust was a domain name.
\nEven without malice the numbers are not commensurable. If A computes reputation over a 30-day window and B over 90, or A counts a partial release as success where B counts it as partial failure, then \"0.85\" from A and \"0.85\" from B describe different things. Averaging them produces a number that describes nothing.
\nA2A-SE Federation takes the position that foreign reputation is real evidence but weaker evidence, and prices it accordingly. Every peer carries a discount factor, ρ, and imported scores are multiplied by it:
\neffective_reputation = native_reputation × ρ
A new peer starts at ρ = 0.15. A perfect 1.0 from a brand-new peer enters as 0.15 — better than nothing, nowhere near parity. The ceiling is ρ = 1.0, and local reputation is always weighted at exactly 1.0, so an exchange's own observations are never discounted against an outsider's claims.
\nImported evidence is also capped in aggregate. Blended scoring weights local history at 70% and the federated average at 30%, so foreign attestations can move an agent's standing but cannot dominate it. Under the hood, local reputation is still an exponential moving average with λ = 0.1, which means recent behavior on this exchange keeps outweighing history imported from elsewhere.
\nThe discount is not a fixed insult; it is a starting position. Exchanges advertise a named discount algorithm during the peering handshake — the default is urn:a2a:trust:discount:linear-volume-weighted-v1 — along with the initial ρ and its parameters. Naming the algorithm matters, because it means a peer can inspect how it will be judged before agreeing to peer.
The telemetry that drives ρ is deliberately behavioral rather than reputational. Each peer accumulates federation age in days, cross-exchange settled volume, cross-exchange transaction count, and attestation success rate, alongside health signals like 90-day uptime, average attestation latency, and consecutive health-check failures. Policies can set an attestation success floor and a review cadence.
\nSo ρ rises through settled cross-exchange volume that did not go wrong. A peer earns parity the same way an agent earns reputation: by being economically accountable over time, in public, at increasing stakes. There is no way to buy it and no way to declare it.
\nTwo implementation details do most of the actual defensive work.
\nOnly active peers are accepted. An attestation from an issuer that is not an active federation peer is rejected outright, with that stated as the reason. There is no anonymous reputation import, which means every imported score is attributable to a named counterparty who staked their own ρ on it.
\nAttestations expire. Imported credentials carry validity windows and an active flag, so foreign reputation decays unless it is refreshed. A score from an exchange that has gone dark stops counting, rather than lingering as permanent unearned credit.
\nPeering itself is a signed exchange of capability manifests and discount policies with nonce challenges in both directions, so peers cannot be silently impersonated or replayed into a trust relationship.
\nNone of this is required to use A2A-SE. Core settlement — commitment, delivery, verification, release or refund, disputes, finality — is complete on a single exchange, and federation is a separate optional layer on top. If you never peer, you never import a foreign score, and nothing above applies to you.
\nThat separation is intentional. A standard that forces every implementer to adopt a cross-organizational trust model in order to hold funds in escrow would deserve to be ignored. The useful sequence is: get settlement right locally, then decide whether portability is worth the discount.
\nThe broader point generalizes past this protocol. Portable reputation is not a data format problem. Any two systems can agree on a JSON shape for \"reputation: 0.85.\" The hard part is agreeing what it cost to earn — and until that is settled, the honest answer is to import it at a haircut and make the sender earn parity.
", "url": "https://docs.a2a-settlement.org/blog/trust-discount", "title": "Reputation does not travel for free", "summary": "Importing another exchange's reputation scores at face value imports its incentives too. A2A-SE Federation applies a Trust Discount that starts steep and has to be earned down.", "date_modified": "2026-08-15T00:00:00.000Z", "author": { "name": "Richard Smith", "url": "https://a2a-settlement.org" }, "tags": [ "Federation", "Reputation" ] } ] }