Verifiable Receipt for AI Tool Calls
Last updated: 2026-09-23
Short answer: A verifiable receipt for AI tool calls is a public, execution-scoped record that identifies one call, preserves the relevant observation and integrity material, and gives another reviewer a verification URL. It proves what the receipt store recorded, not an outside result that the system never observed.
Last reviewed 2026-09-23
What is a verifiable receipt for AI tool calls?
A verifiable receipt is the evidence handoff for one AI tool call. The request represents intent. The tool response represents what the execution layer observed. The receipt joins those facts through a stable identifier, a timestamp, a reproducible representation, and a public path another person or AI can inspect without the original chat.
The word verifiable describes a procedure, not a universal guarantee. A reviewer should be able to resolve the record, compare the call fields, reproduce or inspect the canonical representation, and receive a consistent verifier response. If an external provider did not return a confirmation, the receipt should say that evidence is unavailable rather than infer success.
Which eight components belong in the design?
Identify the capability that crossed the execution boundary and the version or schema context used for the call. This makes later interpretation less ambiguous.
Record safe-to-publish arguments, a redacted projection, or a commitment to the original parameters. Do not publish secrets merely to make a receipt look complete.
Preserve the observed result or a well-defined result preview. The output should remain distinct from an agent's summary or a proposed next step.
Record when the system created or observed the execution, using a documented time format. Ordering matters when calls are retried or chained.
Identify the caller, session, owner scope, or agent identity when the workflow has a safe and meaningful value to publish. An absent identity should stay absent.
A signature can bind a record to a signing key and support authenticity checks. A hash over canonical bytes provides integrity, but it is not automatically a signature or proof of authorship.
A parent hash can connect one receipt to an earlier receipt in a job or chain. It is useful for ordering and tamper evidence, but it does not prove that the parent action achieved an outside effect.
A stable public URL lets a reviewer fetch the same record and run the verification procedure without depending on a private dashboard or the original AI client.
How should those components be interpreted?
The eight components describe a complete receipt design, not a claim that every implementation includes every field on every call. Current Zambo receipts expose a public identifier, recorded tool information, timestamps, observed result fields, canonical integrity material, provenance, and a public verifier when those values are available for the selected execution. Agent identity, parent receipt hash, and signature material depend on the workflow and should never be fabricated when absent.
This distinction protects the reader from confusing a good schema with evidence that was not actually captured. A receipt can be structurally valid while still reporting a failed provider call, an unavailable external confirmation, or a redacted parameter set.
What implementation approaches are available?
Structured record plus canonical bytes
Store a documented JSON or equivalent record, choose the exact bytes covered by the integrity check, and expose the hash and representation needed for reproduction. RFC 8785 is one public reference for JSON canonicalization. The implementation must say which fields are included and how redaction affects the bytes.
Append-only chain
For a multi-step job, each receipt can point to a parent or previous entry. A reviewer can then check ordering and detect a changed link. A chain still records only the observations that entered it. It cannot fill in a provider callback that was never received.
Signed records
A cryptographic signature can bind a payload to a key and let a verifier check authenticity. Key custody, rotation, revocation, algorithm choice, and public-key distribution become part of the verification contract. Do not call a hash a signature, and do not treat a signature as evidence of an external outcome.
Hosted public verifier
A hosted verifier gives a reviewer a stable URL and one consistent response shape. It should protect private data, distinguish missing records from failed checks, and preserve the difference between execution status and upstream evidence.
Open the live_price receipt and call its verifier. This read-only record demonstrates the public execution and integrity path.
How do I verify an AI tool call receipt?
- Resolve the public verification URL and confirm that the receipt ID is the call you intended to inspect.
- Compare the tool name and version, input parameters or commitment, output data, timestamp, and agent or session identity.
- Inspect canonical bytes or the documented representation and compare the declared integrity value.
- Follow the parent receipt hash when the workflow provides one, checking that the chain order is coherent.
- Check the cryptographic signature only when the implementation publishes a verifier and key context for it.
- Review provenance and external evidence separately from the receipt's local integrity result.
- Report only what was observed. A verified tool response is not automatically a completed outside action.
curl -fsSL https://zambo.dev/api/receipt/83ae4fd7-b9f8-497c-b842-72381c8ee6a8/verify \
| jq '{id,tool,created_at,verification_status,output_hash,external_evidence}'Frequently asked questions
What is a verifiable receipt for AI tool calls?
A verifiable receipt for AI tool calls is a public, execution-scoped record that identifies a tool call, preserves the relevant observation and integrity material, and gives another reviewer a verification URL.
What should an AI tool call receipt contain?
A complete design can include the tool name and version, input parameters, output data, execution timestamp, agent identity, cryptographic signature, parent receipt hash, and verification URL.
Does a verifiable receipt prove an outside result?
No. It proves what the receipt store recorded and what its checks verify. An outside result needs a real callback, read-back, settlement reference, or other upstream evidence.
How do I verify an AI tool call receipt?
Open the public record, compare its identifier and fields, call the verifier, check the integrity result, and review any external evidence separately from the recorded execution.