[Feat]: Transaction accountability: cryptographic binding between authorization and execution

[arian-gogani]

Is your feature request related to a problem? Please describe.

When an AI agent completes a UCP checkout on behalf of a user, there's no way for a third party to verify that what was purchased matches what the user authorized. The agent says "buy red roses for $35" and the checkout completes — but the only record of what was authorized lives inside the agent's context window, which is ephemeral and not independently verifiable.

This creates real problems:

• Disputes. If a user says "I told the agent to buy X but it bought Y," there's no cryptographic evidence either way. The merchant has the order, the user has a memory, and nobody has a signed record of what the agent was told to do.
• Consumer protection on card rails. UCP's own documentation flags "unresolved consumer-protection rules for autonomous-agent transactions" as an open question. Chargebacks need evidence, and right now there isn't a verifiable chain from user intent to agent authorization to checkout execution.
• EU AI Act Article 12. Enforcement starts August 2, 2026. Record-keeping requirements for high-risk AI systems apply to agents making financial decisions. A UCP checkout session doesn't currently produce the kind of tamper-evident audit trail that satisfies Article 12.When an AI agent completes a UCP checkout on behalf of a user, there's no way for a third party to verify that what was purchased matches what the user authorized. The agent says "buy red roses for $35" and the checkout completes, but the only record of what was authorized lives inside the agent's context window — ephemeral and not independently verifiable.
  This creates real problems:

Disputes. If a user says "I told the agent to buy X but it bought Y," there's no cryptographic evidence either way. The merchant has the order, the user has a memory, nobody has a signed record of what the agent was told to do.

Consumer protection on card rails. UCP's own docs flag "unresolved consumer-protection rules for autonomous-agent transactions" as an open question. Chargebacks need evidence, and right now there isn't a verifiable chain from user intent to agent authorization to checkout execution.

EU AI Act Article 12. Enforcement starts August 2, 2026. Record-keeping requirements for high-risk AI systems apply to agents making financial decisions. A UCP checkout session doesn't produce the kind of tamper-evident audit trail that satisfies Article 12.

Describe the solution you'd like

A lightweight extension that wraps UCP checkout sessions in a signed receipt pair:

1. Pre-execution receipt — signed before the checkout, binding the user's authorization (what they asked for, budget constraints, restrictions) to a content-addressed hash. The "what was the agent told to do" artifact.

3. 2. Post-execution receipt — signed after checkout completion, binding actual order details (line items, totals, fulfillment) to the same chain. The "what actually happened" artifact.

5. Both receipts are hash-chained (each references the previous via sha256(JCS(prior_receipt))), so tampering with any entry invalidates everything downstream. Any third party — user, merchant, regulator, dispute arbitrator — can verify the chain without trusting the agent operator.

7. This fits into UCP's capability extension model. A dev.ucp.accountability.receipt capability could be declared in the merchant's profile, and agents that support it produce receipt pairs alongside standard checkout flows. Additive, not breaking.

9. Prior art: Microsoft Agent Governance Toolkit merged a bilateral receipt primitive (PRs #1302, #1333) for exactly this authorization-vs-execution binding. Nobulex (github.com/arian-gogani/nobulex) implements the full protocol — Ed25519, JCS/RFC 8785, hash-chained receipts. 189K lines TypeScript, 6K+ tests, MIT licensed. 8 independent implementations have achieved byte-identical canonicalization. Currently in the AAIF project proposal process ([Project Proposal] Nobulex aaif/project-proposals#20) with TC sponsorship.

11. Happy to write a concrete spec for a dev.ucp.accountability.receipt extension and a reference implementation against the JS SDK if there's interest.A lightweight extension that wraps UCP checkout sessions in a signed receipt pair:

12. Pre-execution receipt — signed before the checkout, binding the user's authorization (what they asked for, budget constraints, any restrictions) to a content-addressed hash. This is the "what was the agent told to do" artifact.

13. Post-execution receipt — signed after checkout completion, binding the actual order details (line items, totals, fulfillment) to the same chain. This is the "what actually happened" artifact.

Both receipts are hash-chained (each references the previous via sha256(JCS(prior_receipt))), so tampering with any entry invalidates everything downstream. Any third party — the user, the merchant, a regulator, a dispute arbitrator — can verify the chain without trusting the agent operator.

This fits naturally into UCP's capability extension model. A dev.ucp.accountability.receipt capability could be declared in the merchant's profile, and agents that support it would produce receipt pairs alongside standard checkout flows. Agents that don't support it still work normally — it's additive, not breaking.

Prior art: This pattern already exists. Microsoft Agent Governance Toolkit merged a bilateral receipt primitive (PRs #1302, #1333) for exactly this authorization-vs-execution binding. Nobulex implements the full protocol (Ed25519, JCS/RFC 8785, hash-chained receipts, 189K lines TS, 6K+ tests, MIT). 8 independent implementations have achieved byte-identical canonicalization, including two clean-room verifications with zero shared code. Currently in the AAIF project proposal process with TC sponsorship.

Happy to write a concrete spec for a dev.ucp.accountability.receipt extension and a reference implementation against the JS SDK if there's interest.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct