AML/Sanctions AI Agent Payments cheat sheet: add a verifiable payment evidence section

[tomjwxf]

The recently merged AML and Sanctions Compliance for AI Agent Payments cheat sheet (#2210) covers screening and compliance obligations well. One layer it does not yet cover, and which examiners ask about first, is evidence: when an AI agent initiates a payment, what artifact proves after the fact that the payment was screened, that it stayed within authorized limits, and that the record has not been altered?

Proposed addition: a short section on signed payment evidence, covering:

1. Sign the decision at execution time. Each agent payment decision (allow, deny, or held for human approval) produces a receipt signed over a canonical serialization, so the record is fixed when the decision happens. Denials matter as much as approvals: proving a sanctioned payment was blocked is the record an examiner wants.
2. Independently verifiable. The receipt verifies offline against the operator's published key with open tooling; the examiner does not have to trust the operator's logging infrastructure. Receipts should chain, so omission is detectable, not just tampering.
3. Minimum disclosure. Payment receipts can carry the amount, the asset, and a hashed counterparty identifier, so a cap or sanctions predicate can be verified by a third party without exposing the full counterparty graph. Aggregate predicates (every payment this period stayed under X, no payment reached a listed counterparty class) can be proven over the complete receipt set rather than by disclosing each payment.
4. Wire-format awareness. For HTTP-native payment protocols now used by agents (e.g. x402, EIP-3009 authorizations), the evidence layer should record the payment facts from the actual wire shapes rather than an application-level restatement.

There is standards-track prior art to reference (IETF draft-farley-acta-signed-receipts, revision 02, which I author; disclosed for transparency) and more than one open-source implementation of signed agent-payment receipts, so the section can cite practice rather than proposal. Happy to draft the PR if the maintainers and the original cheat sheet author (@arian-gogani) are open to it.

[jmanico]

Please keep in mind that these are cheatsheets, and not meant to be detailed guides. As long as you keep the advice concise and to the point, and not too detailed, we take PR's.

[jmanico]

This PR includes a self-reference to an IETF guide you authored. This is an ethical violation of our series.