AI agent trust receipts: trust the record, not the report.

What makes an agent's work worth trusting? Not the agent's confidence, and not a summary written by the process that did the work. Zambo is the verifiable work layer for AI, and the instrument for this problem is the trust receipt: a verifiable execution receipt that a receiver can check without trusting anyone in the chain. Its inputs are recorded, its saved result is committed under a digest at execution time, its provenance class is stated, and a public verify endpoint recomputes the commitments for anyone who asks. Trust stops being a feeling about the agent and becomes a property of the record, checked the same way by the client, the auditor, and the next AI session.

Worked example: one receipt, checked the way a stranger would check it

On October 16, 2026, a live_price call for DOGE executed at 10:23:14 UTC and minted receipt e6c7c74c-c62c-4538-b466-27af67c0cb76, provenance class EXECUTED BY ZAMBO, tool live_price version 4.0.0, public scope. Read the record the way a receiver does. Recorded inputs: the call's arguments, committed under input hash sha256:f292d4f93bc9a9b25c703b0dd50e039fa58a379cb7425b3fc639846bd92477d0 in the zambo-json-sorted-keys-utf8-v1 layout. Saved result: DOGE $0.08219 USD, up 3.04% in 24 hours, market cap $12.85B, live price via CoinGecko, committed under output digest sha256:002efa8e78ef9690dd5c2b399d7d2e4cfbb056101576106f8b935d262983f36d. Evidence: the captured source response is itself hashed, evidence sha256:0c719bdcf85dd396cbc5cccc469a5d4946e59e9111af485333586ea694e5aab9. The check: the public verify endpoint reports the receipt verified, with the commitment, canonical payload, provenance binding, and metadata binding checks all passing. Nothing in that paragraph was taken on anyone's word: every value sits in the public record, and the recompute either matches or it does not.

The same discipline covers the step that goes wrong. Minutes later a pdf_extract call failed at 10:23:26 UTC, and the failure left receipt 010921b2-6264-4e97-aa7b-2bcaab8f6ba7, also verified, output digest sha256:687e8e379b4a5bc53e5233b8430788261515ed97a802f29a2d6f7321871d2ae6, whose saved result is the error itself. A trust record that only exists for successes is a highlight reel. This one records the miss with the same commitment as the hit, which is exactly why a claimed success backed by nothing, or by an error receipt, gets caught.

Hold one yourself: the live demo runs one real call and hands you its verifiable receipt, no signup.

Published October 16, 2026. Updated October 20, 2026. Written against AER-1, IETF Internet-Draft revision 23: draft-zambo-aer1-23. AER-1 is an IETF Internet-Draft, not a finalized standard.

AI agent trust receipts

The short answer. People searching for trust receipts are asking one question in two forms: what record would let me rely on this agent's work, and who stands behind that record? The answer to the first is a verifiable execution receipt: recorded inputs, a saved result committed under a digest at execution time, a stated provenance class, and a public check anyone can recompute. The answer to the second is that, on an open format, nobody has to stand behind it in the room. The record carries its own commitments, and the receiver checks them directly. A receipt you can only check by asking its issuer is a feature of that issuer's product. A receipt a stranger can recompute is evidence, and evidence is the only form trust should take when work changes hands.

Scope, stated once and applied everywhere on this page: a verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was correct, and it does not prove an external event happened beyond what the record itself shows. The trust on offer is narrow and strong: this call ran, with these inputs, and this is the result it saved, unchanged since the moment it was saved.

The five properties that make a receipt worth trusting

  • Recorded inputs. The receipt binds what the call was asked to do, under an input hash with a published layout. A result without its inputs is a number without a question: impressive, and uncheckable.
  • Committed output. The saved result is digested at execution time, not when the report is written. Edit one byte of the result afterward and the digest no longer matches, and the record says so to anyone who recomputes it.
  • Stated provenance. The record says what kind of execution produced it, as a class the receiver can weigh. A result the system executed itself and a claim an agent logged about outside work are different kinds of evidence, and the record should never blur them.
  • Public, recomputable verification. The check runs against the record itself, through a public endpoint or an independent implementation, with each binding reported separately. Verification that phones home to the presenter for a yes is not verification.
  • Failures recorded too. Errors, timeouts, and empty results mint records with the same commitments as successes. Without this property, the absence of a receipt is ambiguous, and ambiguity is where untrustworthy work hides.

Hold any record an agent hands you against those five. The ones it fails are the places your trust is currently being extended on credit.

How to run the trust check

  1. Start from the claim. Write down, in the agent's own words, what it says it did: which call, with what inputs, producing what result. Vague claims get pinned down now, not after the check.
  2. Ask for the receipt, not the transcript. The transcript is the agent's account of the call. The receipt is the executing system's record of it, written at execution time. If the answer comes back as a screenshot or a pasted log line, you have been handed testimony, and the check cannot start.
  3. Read the four fields. Recorded inputs, saved result, output digest, provenance class. The inputs tell you whether the call that ran is the call that was claimed. The provenance class tells you what kind of evidence you are holding.
  4. Run the recompute. The public verify endpoint recomputes the digest from the saved result and compares it with the committed digest, then reports the provenance and metadata bindings separately. A pass means the record in front of you is the record that was committed at execution time.
  5. Compare the saved result with the claim. This is the step summaries exist to skip. The saved result either matches the claim or it does not, and both readings are findings: a match closes the question for that step, and a mismatch locates the exact step where the story and the record part.

The three outcomes, plainly: record verifies and matches the claim, trust that step. Record verifies and contradicts the claim, the record wins and the claim gets corrected. No record, or only an error receipt, the step did not run as claimed. The sibling failure modes have their own pages: the invented result in How do I catch an AI agent making up results?, and the silent failure in the silent tool failure page.

Trust at the scale of a whole job

Single receipts settle single calls. Jobs are where trust is usually spent, so the same construction closes over a whole run: every step's receipt, in order, bound under one root at close. On October 16, 2026, a three-call run (live prices for BTC, ETH, and SOL) closed as workflow receipt fa512cd8-6af4-4d7c-ae30-174a8bae66e8 at 10:22:43 UTC. Its entries: 0d1b711a (BTC $81,959.00, output digest sha256:4ee6e206ed138866a9cf36c5c42cab4ea90e38b044d514b0b2fd69b8146b3076), 6c632066 (ETH $2,451.70, output digest sha256:420db5c7129f84d2f119f037d39397fa07e1202bb9055359977f9d91d97364d7), and bab0fb22 (SOL $105.97, output digest sha256:7b67d40bccb9e8c5bd3fd798a296b8ae692ab7bc6ab966c2b6c5969723fff8e3), each verified on the public endpoint. The root served for the run is 7939977021a4ee0b2c7e24679609a7b79e1dd14025c57e4d85b23e906b268111, and recomputing it from the three receipt identifiers under the construction in Section 8.1 of the draft reproduces that root exactly. Insert a step, drop one, or reorder them, and the root stops matching. That job-level record is the execution ledger form of the same idea, covered in the AI agent transparency log page.

What a trust receipt does not do

It does not grade the work. A receipt over a wrong answer verifies exactly as cleanly as a receipt over a right one, because the commitment is to the saved result, not to its quality. It does not authenticate the issuer by itself: the verify endpoint reports issuer authentication as not checked, and the provenance binding establishes that the stated class is consistent with the record's bytes, not who operates the system. And it does not reach outside the record: a call that ran somewhere else, outside the recorded path, has no trust receipt, and its result stands on the same testimony as ever. These limits are not fine print. They are what keep the claim worth making: a record that promises exactly what it can prove, and proves exactly what it promises.

The format underneath: AER-1

The receipts used in every section above follow one open format: AER-1, IETF Internet-Draft revision 23 (draft-zambo-aer1-23). AER-1 is an IETF Internet-Draft, not a finalized standard. It defines the per-step verifiable receipt and the workflow record that links receipts for a run, so a receipt produced in one place can be checked by a receiver somewhere else, with no account on the system that produced it and no cooperation from the operator who ran the agent. The trust discipline on this page is the operating pattern around the format: records at execution time, recompute at receiving time, claims judged against records.

To put receipts under your own agent's work: start with the live demo for a single checked call, then a Zambo Day Pass for a day of calls with a verifiable receipt under each one. The trust question itself, worked as a checklist, is in How can I trust my AI agent's work?

Questions, answered

What is an AI agent trust receipt?

It is a verifiable execution receipt doing the trust job in a handover. When agent work changes hands, the receiver needs a record they can rely on without relying on the agent or its operator. A trust receipt is that record: the call's inputs recorded, the saved result committed under a digest at execution time, the provenance class stated, and a public check that recomputes the commitments. There is no separate trust file format and no trust score. The trust comes from the checks the record passes, and any record that cannot be recomputed by a stranger is not a trust receipt yet, whatever it is called.

What makes a receipt trustworthy?

Five properties. The inputs are recorded, so the receiver can see what the call was actually asked to do. The saved result is committed under a digest at execution time, so changing it afterward breaks the record detectably. The provenance class is stated, so the receiver knows what kind of execution produced it. Verification is public and recomputable, so the check does not run on the presenter's say-so. And failures are recorded the same way as successes, so a missing or failed call leaves a visible mark instead of a gap nobody mentions. A record with all five can carry trust. A record missing any of them is asking for trust instead of earning it.

How do I check a trust receipt?

Open the receipt and read four things: the recorded inputs, the saved result, the output digest, and the provenance class. Then run the check: the public verify endpoint recomputes the digest from the saved result and compares it against the committed one, and reports each binding check separately. Then compare the saved result against what the agent claimed. Three outcomes are possible. The record verifies and matches the claim: trust that step. The record verifies but the saved result differs from the claim: the claim is wrong, and the record shows how. There is no record, or the only record is an error receipt: the step did not run as claimed, whatever the summary says.

Does a trust receipt prove the agent's work was correct?

No. A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was correct, and it does not prove an external event happened beyond what the record itself shows. What it settles is the prior question: that this call ran, with these inputs, and produced this saved result at this time, in a form a receiver can recompute. Correctness is still a review judgment. The receipt's job is to make sure the review happens against the real record, not against a summary written by the process being reviewed.

Can a trust receipt be faked?

A presenter can fabricate a document that looks like a receipt, the same way anyone can fabricate a screenshot or a log excerpt. What they cannot do is make a fabricated document pass the check: verification recomputes the digest from the saved result and compares it with the committed digest and the bound metadata, and a fabricated or edited record fails that recompute. Two honest limits apply. The check proves the record is committed and unchanged; it does not by itself authenticate who issued it, and the verify endpoint reports issuer authentication as not checked. And a receipt only covers the call it records, which is why the failure case matters: a step with no receipt is a step with no trust record, and the check treats it that way.

What are AI agent trust receipts?

AI agent trust receipts are verifiable execution receipts doing the trust job when agent work changes hands: each one records the tool that ran, the time, the recorded inputs, and the saved result under a hash commitment computed when the call ran, so a receiver who was not there can recompute the commitment and rely on the record instead of on the agent's confidence. A step with no receipt has no trust record and stays a claim. The receipts prove the saved record was not changed since it was saved; they do not prove the work was correct.

AI agent trust receipts: the two-minute trust check

The problem: you are asked to trust work you did not watch, from an agent you did not supervise, on the strength of its own summary. AI agent trust receipts replace that ask with a check you can run yourself, and it takes about two minutes. One: ask for the job's record, the receipts bound in order by its workflow record, not a narrative about the job. Two: pick the two or three steps the whole delivery stands on. Three: for each one, open the receipt, recompute the commitment from the saved result, and read the saved result itself. Four: write down the split, steps that recompute and steps that stay claims, and let only the first group carry weight.

The check works because of when the record was made. Each receipt was fixed at execution time, so a result edited afterward fails its recompute, and a step that never ran has no receipt to show. The open format underneath is AER-1, published as IETF Internet-Draft draft-zambo-aer1-23. What the check settles is narrow: the saved record was not changed since it was saved. Whether the work was good remains your judgment, now made against results you verified instead of a summary you were handed.

Related