Trust & Safety · Standards tracker

Which standards are closing the trust gap, and how far along are they?

Five public efforts are building the missing paper chain of agentic commerce — proof of permission, proof of delivery, checkable receipts, and security guidance around all of it. This page tracks each one in plain language: what it fixes, where it stands, and where its primary sources live.

How do I read this page?

Entries are listed alphabetically and described, never ranked — no winner is declared here, ever. Every status was checked against the standard’s own home on the date stamped on the entry. This is a living page: when a status changes, the entry changes and the changelog says so. The payment rails themselves are covered in Protocols: AP2 & UCP · Stripe machine payments · Verifiable Intent & Agent Pay · x402.

AP2 mandates

status checked 2026-09-02 · spec v0.2

What it fixes

Proof of permission. An AP2 mandate is a signed digital permission slip: a verifiable credential recording what the operator actually allowed an agent to buy, and up to what amount. Mandates chain into an audit trail a dispute can lean on.

Where it stands

Specification v0.2, released 2026-04-28 — the version that added “Human Not Present” payments, where the agent buys alone inside its mandate. The same day, Google donated AP2 to the FIDO Alliance; standardization continues in FIDO’s Agentic Authentication and Payments Technical Working Groups.

Where the primary sources are

Read the AP2 specification site and Google’s FIDO donation announcement. This site’s rail page: AP2 & UCP.

Offer-receipt

status checked 2026-09-02 · extension spec v0.6

What it fixes

It staples the promise to the proof. With offer-receipt, the seller signs its offer, and after payment and delivery returns a signed receipt that points back at that offer. One honest limit: the delivery confirmation is the seller’s own signature — a step forward, not independent proof.

Where it stands

An extension to x402, at version 0.6, dated 2026-02-04, in the x402 Foundation’s specification repository. Its own changelog records the path: initial draft 2025-12-22, first approved release at v0.5 on 2026-01-29, then the v0.6 revision.

Where the primary sources are

Read the offer-and-receipt extension specification. This site’s rail page: x402.

OWASP agentic security

status checked 2026-09-02 · active initiative

What it fixes

The behavior layer rather than the payment layer. OWASP agentic security is community guidance on what can go wrong when software acts with authority — stolen credentials, manipulated instructions, runaway tools — and how to defend against it. It is not a payments specification; it is the security context around all of them.

Where it stands

An active initiative of the OWASP GenAI Security Project, with an open weekly working group. Published so far: the OWASP Top 10 for Agentic Applications 2026, a peer-reviewed risk framework released 2025-12-09; the “State of Agentic AI Security and Governance” report, at version 2.01 as of 2026-06-01; and “Agentic AI — Threats and Mitigations” guidance.

Where the primary sources are

Read the Agentic Security Initiative page and the Top 10 for Agentic Applications.

SEP-2828 signed receipts

status checked 2026-09-02 · continues at the IETF, draft rev 07

What it fixes

A signed record of the work itself. SEP-2828 proposed machine-checkable execution receipts for tool calls: the decision to act, the execution, and the outcome, bound together so “what ran” can be checked — the half a payment receipt never covers.

Where it stands

It began in the MCP standards process as proposal #2828. The author withdrew it from MCP — the proposal closed 2026-07-18, with an on-thread note that this was deliberate — and the specification continues at the IETF as draft-sirkkavaara-vaara-receipt, revision 07, dated 2026-08-12. It is an Informational Internet-Draft: work in progress by the IETF’s own rules, not a finished standard, and it expires 2027-02-13 unless revised.

Where the primary sources are

Read the IETF draft on the Datatracker and the original MCP proposal thread.

Verifiable Intent

status checked 2026-09-02 · draft v0.1

What it fixes

Proof of authorization before money moves. Verifiable Intent defines a tamper-evident delegation chain — credential issuer to user to agent — with machine-verifiable constraints such as amount bounds and merchant allowlists, so a merchant or network can check “did someone actually approve this?” before settlement.

Where it stands

Draft v0.1, open-sourced 2026-03-05 under the Apache 2.0 license. Maintained by Mastercard and open to multi-stakeholder contribution. Per Google’s announcement it is AP2-compatible and also being donated to the FIDO Alliance; integration mappings are published for AP2, ACP, and UCP.

Where the primary sources are

Read the specification site and the specification repository. This site’s rail page: Verifiable Intent & Agent Pay.

What do these statuses add up to?

Every link of the paper chain has a public effort behind it, and none of the efforts is finished. Permission has the most mileage — AP2 at v0.2 and Verifiable Intent at v0.1 both sit inside FIDO’s standardization process. Delivery proof and receipts are younger: an extension spec and an Internet-Draft. That is what a growing economy’s standards layer looks like mid-build — which is exactly why the failure modes still work, and why this page exists to be checked back on.