Verifiable AI agent receipts

Plain answers about using Zambo, keeping your work, and checking receipts. A receipt shows what Zambo recorded for one call. It does not prove the answer is right.

Last updated: 2026-10-06

A receipt is useful because an agent's final summary is not the same thing as an execution record. A reviewer needs a stable identity, a boundary around the call, and enough material to repeat the integrity check without trusting the narrator. This page gives that definition and then shows how to inspect a real Zambo record.

What the receipt records

A verifiable receipt is intentionally narrow. It identifies one execution rather than pretending to certify an entire conversation. The record can include a UUID, schema version, creation time, tool name and version, caller scope, provenance class, canonical bytes, output hash, status, result preview, evidence references, and a public URL. These fields answer different questions.

The UUID tells a reviewer which record is being discussed. The timestamp locates when the receipt store created it. Tool metadata names the capability that crossed the execution boundary. Provenance says whether the system ran the tool itself, observed an integrated connection, or logged a report from another agent. That distinction matters because an execution and a report do not support the same claim.

AER-1 as the open draft authority

AER-1, AI Agent receipt, is Brennan Zambo's open draft spec for portable, independently checkable receipts. The current draft revision is draft-zambo-aer1-12 in the IETF Datatracker. It is shared for discussion and implementation experiments.

The draft keeps the claim precise: what did the execution system record for this call? A receipt can preserve the tool, time, bytes, and observed result. It cannot manufacture evidence for an outcome that was never read back. Brennan Zambo maintains the public Zambo reference implementation as a concrete place to inspect this boundary, while the draft remains open to review and revision.

Implementers can start with the working AER-1 conformance suite, its published vector index, and the from-scratch implementation guide. The suite checks required fields, strict bytes, timestamp validity, hashes, provenance, and negative cases. Passing local vectors is evidence about those checks, not a universal certification.

Worked verification example

1. Resolve identity. Confirm that the URL, receipt result details, and verifier request all use UUID 83ae4fd7-b9f8-497c-b842-72381c8ee6a8. If one identifier differs, stop. A result from one record must not be paired with an integrity state from another.
2. Inspect context. Read the creation time, tool name, tool version, caller scope, provenance, status, and result preview. These fields describe what the store says happened and where the observation boundary sits. They do not independently establish that a provider was correct.
3. Obtain the committed representation. Read the receipt's canonical bytes or the representation the verifier explicitly exposes. Do not copy a display preview into a new JSON document and call that the original bytes.
4. Compute the digest. Decode the Base64 bytes strictly, preserve the resulting UTF-8 bytes, and compute fingerprint. Compare the lowercase hexadecimal digest with the exact value after fingerprint: in the output hash.
5. Review the conclusion. A verified response supports the limited statement that the stored bytes match the declared commitment and the record passes the implementation's checks. It does not prove a market outcome, delivery, authorization, or any other event outside the recorded observation.

RECEIPT_ID="83ae4fd7-b9f8-497c-b842-72381c8ee6a8"
curl -fsSL "https://zambo.dev/api/receipt/$RECEIPT_ID/verify" | jq -e   '{id, verification_status, output_hash} | select(.verification_status == "verified")'
# expected output_hash:
# sha256:0f2e1a26239ff6f1c1e7909fb94eeaec063bdb19d4c1fe3e6887dbf86765e741

What receipts prove and what they do not

Provenance and failure are part of the evidence

A useful receipt does not hide uncertainty. If Zambo executed a call, the record can attest to that execution and the stored result. If an integrated connection returned an observation, the record should say that it was observed through the connection. If another agent reported an action, the record can attest that the report was received, redacted, timestamped, and chained, but it should not say Zambo ran the action.

Failures also have an execution boundary. Invalid input, a provider timeout, a denied permission, or an unavailable dependency can be recorded without being converted into a success-looking summary. A verifier should distinguish invalid data, unsupported schema, unavailable bytes, digest mismatch, and unavailable network access. Those states guide recovery and prevent a green label from becoming a substitute for evidence.

For a multi-step job, entries may form an append-only chain. Reviewers should inspect each step's identity and provenance rather than treating a final job summary as proof of every step. A later read-back may establish a new confirmed observation, but it should not rewrite the earlier receipt or turn an attempted call into a completed outcome.

How to implement a verifiable receipt

Start at the moment a tool call becomes durable. Capture the identity and context needed to locate the call, then freeze the bytes that will be committed. Keep private prompts, credentials, personal contact details, and sensitive upstream bodies out of public projections. Redact before publication. If a redacted projection has its own hash, label it as a projection hash instead of implying it is the original commitment.

For retries, mint a new receipt identity and creation time. An optional correlation field can relate attempts, but a successful retry should not overwrite a failed first attempt. For corrections, append a superseding observation and preserve the original creation time. This makes delay, duplicate requests, partial completion, and administrative change visible to the next reviewer.

Frequently asked questions