Glossary · Records and compliance

Receipt (agent exchange)

A signed record of one completed agent-to-agent exchange, naming the parties, the request, the outcome and the time, that either side can later verify.

A receipt for an agent exchange is a signed record of one completed interaction between two agents, stating who took part, what was requested, what the outcome was and when, in a form that either party can store and later check for tampering.

Why A2A alone does not give you one. A finished A2A task has a status, artifacts and possibly a history, but all of it is what the remote agent reports, and none of it is signed. Section 3.7 lets an agent decide which messages to keep in task history. When a customer disputes a refund, or two agents disagree about what was agreed, each side needs evidence the other cannot rewrite. NIST SP 800-53 control AU-10 describes that property as non-repudiation: irrefutable evidence that a party performed an action.

Receipts in adjacent standards.

  • x402. The x402 A2A transport returns payment settlement results in the metadata of the task’s status message, as an array of settlement responses under x402.payment.receipts.
  • SCITT. RFC 9943 (June 2026) defines a Receipt as a signed proof, from a transparency service, that a statement was registered in its verifiable data structure. RFC 9942 encodes these as COSE Receipts carrying Merkle inclusion proofs, so anyone can check that a record is in a log that has not been rewritten.

Building blocks. A receipt for an A2A task can reuse existing standards. Canonicalize the payload with JCS so both sides hash the same bytes, sign it with JWS from each party, and append it to a hash-chained or Merkle log so later edits are detectable. An illustrative payload (this is not a published format):

{
  "taskId": "5f1c2d9e-8b7a-4e3c-9d21-6a0b4c7e2f13",
  "contextId": "ctx-7",
  "client": {"agent": "https://buyer-agent.example.com/.well-known/agent-card.json"},
  "server": {"agent": "https://support.example.net/.well-known/agent-card.json"},
  "requestMessageIds": ["3b8f0c2e-5d1a-4f6b-9e7c-2a4d6f8b0c1e"],
  "outcome": {"state": "TASK_STATE_COMPLETED", "artifactIds": ["refund-confirmation-1"]},
  "completedAt": "2026-09-26T14:03:12.004Z"
}

Emissar Ledger. Emissar’s Ledger module proposes a receipt for each completed task that records the parties, their verified identities, the mandate used, the request, the outcome and timestamps, signed by both sides and retrievable by either. Status: Spec in progress.

Neighbouring terms. An audit trail is each party’s own running record. A receipt is the shared, signed record of one exchange.

Sources

  1. A2A Protocol Specification, section 3.7: Messages and Artifacts (accessed )
  2. x402 v2 transport: A2A (x402.payment.receipts) (accessed )
  3. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains (June 2026) (accessed )
  4. RFC 9942: CBOR Object Signing and Encryption (COSE) Receipts (June 2026) (accessed )
  5. NIST SP 800-53 Rev. 5 control catalog (AU-10 Non-repudiation), OSCAL JSON (accessed )
  6. Emissar: Ledger module (accessed )