AER-1: A Portable Execution Receipt for AI Agent Tool Calls

Introduction AI agents increasingly act through tool calls: they query prices, send messages, modify files, and invoke services on a principal's behalf. When something later needs checking -- what happened, when it happened, and what the system actually observed -- the parties involved usually have only vendor-specific logs, screenshots, or the agent's own summary. None of these is portable across implementations, and none lets an independent third party recompute what was recorded. AER-1 (AI Agent Execution Receipt, version 1) defines a small, portable vocabulary for recording one agent tool call as a verifiable receipt. The receipt answers a narrow question: what did this system record for this execution? It does not prove an external business outcome the system did not observe, and it does not turn a planned, blocked, or preview action into a completed execution. This document is an open proposal authored by Brennan Zambo. It is not a claim to invent or own the broader execution-receipt category, and it does not establish certification, registry membership, universal adoption, or a finalized standards status. It is intended for discussion, implementation experiments, and interoperability feedback. A reference implementation is deployed at the time of writing, and its receipts are publicly verifiable as described in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document also uses the following terms:

Execution:: One invocation of one tool by or on behalf of an agent, with its inputs, observed result, and timing.
Receipt:: A public record for one execution with a stable identifier, execution metadata, canonical bytes, and an output commitment, as defined in .
Canonical bytes:: The exact UTF-8 byte sequence over which the output commitment was computed. Verifiers MUST receive or reproduce the same bytes before comparing hashes.
Observed result:: The result the implementation received and stored for the execution. A receipt reports observation, not an unsupported claim about the world beyond the observation.
Output commitment:: A SHA-256 digest of the canonical bytes, written "sha256:" followed by the lowercase hexadecimal digest.

The Receipt Record A receipt is a JSON object with the following members. This is the smallest useful interoperable shape; implementations MAY add fields, but additions MUST NOT make the core identity or verification fields ambiguous. Core receipt members

Field	Required	Meaning
id	MUST	Stable UUID identifying the receipt.
receipt_schema_version	MUST	Schema version. "0.3" in the reference implementation.
created_at	MUST	Timestamp of record creation, in RFC 3339 format.
tool	MUST	Object naming the tool: name, version, and caller scope (for example "public").
provenance_class	MUST	One of the provenance classes in .
canonical_bytes	MUST	Base64 encoding of the exact UTF-8 bytes hashed for the output commitment.
output_hash	MUST	"sha256:" plus the lowercase hex digest of the decoded canonical_bytes.
verification_status	MUST	"verified" when the stored record passes the procedure in .

The public URL is not a stored member; it is a resolution rule. Every receipt MUST be retrievable at a stable public URL without an account, wallet, or token, as specified in . In the reference implementation the URL is https://zambo.dev/run/<id>. Deployed records carry additional members outside the interoperable core (for example caller identity, evidence references, external anchor data, per-check results, side-effect declarations, and a result preview). A verifier MUST NOT require them, and their presence MUST NOT change the meaning of the core members. Example: the following shows the core fields of a real receipt issued by the reference implementation (id 130da435-e157-498e-af90-605866a86a27, a live_price call). The canonical bytes and output hash are elided here to respect line-length limits; the complete record is published at https://zambo.dev/run/130da435-e157-498e-af90-605866a86a27, where the output hash was independently recomputed from the decoded canonical bytes while preparing this document and matches.

Canonical Bytes and Output Commitment Interoperability fails when every implementation gives a different name to the same boundary, so the checkable core of a receipt is deliberately small: an identifier locates the record, a creation time orders it, a tool and caller scope identify the execution context, and canonical bytes plus an output hash make the stored representation checkable. The producer MUST preserve the exact UTF-8 byte sequence that was hashed, and MUST expose it (directly, or in a form from which a verifier can reproduce it byte for byte) so that any party can recompute the digest. The digest algorithm is SHA-256 . A verifier that cannot obtain or reproduce the exact canonical bytes MUST NOT report the output commitment as confirmed. A result preview MAY accompany the receipt to give a human reader a useful first read. A preview is not the source dataset, and a verifier MUST NOT treat agreement with a preview as agreement with the committed bytes.

Provenance Classes A whole job can combine actions performed by the recording system itself, actions observed through an integrated gateway, and actions reported by another agent. Those cases can all be useful, but they do not support the same statement, so every receipt MUST name exactly one provenance class. Verification MUST NOT upgrade a report into an observation. The three classes are:

EXECUTED BY ZAMBO:: The recording system ran the tool and recorded the returned result. The receipt can attest to that execution and its stored output commitment.
OBSERVED VIA GATEWAY:: The recording system observed the action through an integrated gateway. The receipt attests to the gateway observation, not to facts beyond what the gateway returned.
LOGGED BY AGENT:: An external agent reported the action through a journal interface. The receipt attests that the report was received, redacted, timestamped, and chained. The recording system does not claim it ran or observed the action.

The first label names the recording system; its interoperable content is the definition, and another implementation substitutes its own system name in that position. The second and third labels are fixed strings. Provenance is a separate design axis from the receipt envelope. Two receipts with identical envelopes can carry different provenance, and a verifier MUST surface the provenance class alongside every other field when presenting a receipt.

Verification Procedure To verify a receipt, a verifier performs the following steps:

Resolve the public receipt URL and confirm the id in the retrieved record matches the requested execution.
Read the exact canonical bytes, or the representation needed to reproduce them byte for byte.
Compute SHA-256 over those bytes and compare the result with output_hash.
Review the tool, timestamp, caller scope, observed result, evidence, and anchor status separately from the hash check.
Report only what the stored observation supports. A passing hash confirms the bytes match the commitment; it does not confirm anything the system did not observe.

A machine-readable verifier SHOULD expose the same procedure over HTTP, returning the receipt identifier, verification status, and output hash, and signaling failure with a non-success status when the record does not verify. In the reference implementation, an HTTP GET on https://zambo.dev/api/receipt/<id>/verify returns a JSON object containing at least id, verification_status, and output_hash.

Hash-Chained Job Timelines Entries for one job form an append-only hash chain: each entry commits to the previous entry's digest, so insertion, deletion, or reordering of entries is detectable by recomputation. A public page resolving the whole timeline reports whether the visible chain verifies. The reference implementation exposes this as a per-receipt chain-validity check alongside the other verification checks. Chaining provides tamper evidence for the sequence, not truth about the world. A chained entry with LOGGED BY AGENT provenance remains a chained report; the chain upgrades nothing about what the entry attests.

Public Resolution Every receipt MUST be retrievable at its public URL without an account, wallet, or token. The URL is stable: once published, the record at that URL MUST NOT be altered. Corrections are published as new receipts that reference the superseded id; they MUST NOT rewrite history at the original URL. The public page SHOULD present the receipt fields, the provenance class, the verification outcome, and the hash chain position in human-readable form alongside the raw JSON.

External Anchoring A receipt MAY be bound to one or more external timestamp anchors after issuance. Anchoring is additive: it does not alter the receipt bytes and MUST NOT invalidate the output commitment. In the reference implementation, each receipt is anchored to public Nostr relays. The anchor object carries the relay event identifier, the publisher key, the relay URLs, a published status, and the publication time, plus an envelope binding the anchor to the receipt id, the output hash, and the evidence hash. Anchoring gives verifiers a witness independent of the receipt publisher; it does not change what the receipt attests.

Reference Implementation A reference implementation of this vocabulary is deployed at the time of writing, described at . The implementation exposes the receipt contract through one MCP endpoint and gives successful calls a public receipt page:

Tool calls are made over HTTPS as JSON-RPC to https://zambo.dev/api/mcp using the tools/call method. The response contains the receipt identity and the public verification link.
Each receipt resolves at https://zambo.dev/run/<id> and can be opened and checked by anyone, with no account or token.
A verifier endpoint returns the machine-readable verification result for a receipt identifier, as described in .

The endpoint and the receipt pages are independent live records: anyone can reproduce the procedure against them today. Their availability is a deployment fact, not a standards claim; if the deployment moves, the canonical home of this document's latest revision is updated accordingly.

Design Rationale AER-1 starts with a narrow record rather than a universal theory of agent behavior. An agent may call several tools, receive information from several providers, and hand work to another agent. A reviewer still needs a stable way to identify one execution, understand what the system observed, and check whether the published bytes match the stated commitment. The draft keeps those needs separate from claims about the outside world. The vocabulary is intentionally small because interoperability fails when every implementation gives a different name to the same boundary. An identifier locates the record. A creation time orders it. A tool and caller scope identify the execution context. Canonical bytes and an output hash make the stored representation checkable. A result preview gives a human a useful first read without pretending that a preview is the entire source dataset. Provenance is a separate design axis (). A system can execute a tool itself, observe an action through an integrated gateway, or receive a report from another agent. AER-1 treats these as distinct attestations because they are distinct claims, and a verifier that cannot tell them apart cannot report honestly. On canonicalization: AER-1 preserves the producer's exact bytes and carries them explicitly, rather than mandating a canonicalization scheme such as the JSON Canonicalization Scheme . A verifier MUST NOT re-serialize the record under a different scheme and claim agreement with the commitment. The cost of this choice is stated plainly: digests computed under different canonicalizations do not interoperate, so cross-implementation verification requires byte-identical canonical content. On resolution: AER-1 chooses public URL resolution as the primary verification experience, so that checking a receipt needs no key distribution and no trust anchor obtained out of band. The tradeoff is availability dependence on the publisher; deployments that cannot accept that tradeoff can pair the record with the external anchoring in or with offline recomputation from the carried canonical bytes.

Security Considerations A receipt is evidence of what was recorded, not a security boundary by itself. The following considerations apply to implementations:

The output commitment binds the recorded bytes, not the real world. An implementation that records attacker-controlled input produces a verifiable receipt of attacker-controlled input. Verifiers MUST present the observed result as observed, never as independently true.
Canonical bytes MUST be preserved exactly. Any transformation (re-encoding, whitespace normalization, character set conversion) between recording and verification breaks the commitment and MUST cause verification to fail closed.
Public receipt URLs are stable and permanent. Implementations MUST consider privacy before publishing: a receipt that embeds personal data, credentials, or confidential business information in its canonical bytes publishes that data to everyone. Redact before recording; a receipt cannot be unpublished.
Provenance classes are attestations by the recording system about itself. A dishonest recorder can mislabel provenance. Consumers who need stronger guarantees should use the external anchoring in or bind receipts to independent witness records.
Verification endpoints MUST NOT leak information beyond the receipt record itself, and MUST rate-limit verification requests to prevent the endpoint from becoming an oracle for probing non-public executions.

IANA Considerations This document has no IANA actions.

Related Work Action receipts for AI agents are an active area with multiple concurrent individual proposals, including formats built around signed envelopes bound to decision evidence, hash-chained action records verifiable offline, and canonicalization-based offline recomputation. This document does not survey or endorse any of them by name. AER-1 differs in three ways. First, the receipt is identified by a UUID and resolved at a stable public URL, with verification offered as a public HTTP endpoint rather than offline recomputation. Second, it carries provenance (executed, observed-via-gateway, logged-by-agent) as a first-class field, so a verifier can distinguish what the recording system did from what it merely recorded. Third, a reference implementation is deployed whose receipts are publicly verifiable without an account, key, or token. AER-1 standardizes the narrow per-execution record and its public verification procedure, leaving decision semantics, authorization, and settlement bindings to other specifications.