Independent Submission B. Zambo
Internet-Draft Zambo
Intended status: Informational 26 September 2026
Expires: 30 March 2027
AER-1: A Portable Execution Receipt for AI Agent Tool Calls
draft-zambo-aer1-01
Abstract
This document specifies AER-1, a small vocabulary for recording one
AI agent tool call as a portable, independently checkable execution
receipt. A receipt identifies the execution, records when it
happened, preserves the canonical bytes used for the output
commitment, names the tool and caller scope, carries a provenance
class, and resolves at a stable public URL. The format separates
what the system observed from claims about the outside world, and it
separates provenance (who ran or reported the action) from the record
itself. A reference implementation is deployed, and its receipts are
publicly verifiable without an account or token.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zambo Expires 30 March 2027 [Page 1]
Internet-Draft AER-1 September 2026
Implementation Status
This section records the implementation status of the AER-1
vocabulary at the time of this revision, following [RFC7942]. It
will be removed before publication as an RFC.
Reference implementation. Zambo (https://zambo.dev), operated by
the document author, is a deployed implementation of Sections 3
through 9. Tool calls made over HTTPS as JSON-RPC to
https://zambo.dev/api/mcp receive a public receipt page at
https://zambo.dev/run/<id>, retrievable without an account, wallet,
or token. A machine-readable verifier is exposed as described in
Section 6. Receipts are anchored to public Nostr relays with an
envelope binding the receipt identifier, the output hash, and the
evidence hash (envelope "zambo-receipt-anchor/1").
Independent verification. The Section 6 verification procedure has
been exercised against live receipts by independent third parties:
* On 2026-09-16, an independent agent ("Merv", on the Clawstr
network) verified a live receipt
(id 0ec81343-cc1f-4c25-9c33-d76b5582406d) in three checks: the
SHA-256 of the decoded canonical bytes matched the output
commitment, the upstream evidence hash matched, and the anchor
event carried a valid signature retrievable on independent
relays. The same party reported that the anchor envelope did
not then bind the evidence hash; the reference implementation
has since shipped the binding envelope described above.
* On 2026-09-16, an independent agent ("nilo_agent", on Nostr)
ran adversarial verification challenges against live receipts,
including a witness round and a strong-form Bitcoin-anchored
challenge (anchor block 967351, receipt 88094e26), each
answered with bytes the challenger could check independently.
* On 2026-09-25 and 2026-09-26, an independent agent ("Devan",
on Nostr) published timestamped probe receipts (v1 and v2)
exercising independent verification of agent work in the same
receipt model.
No other implementations are known to the author at the time of
writing. Reports of additional implementations or independent
verification results are solicited.
Zambo Expires 30 March 2027 [Page 2]
Internet-Draft AER-1 September 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Receipt Record . . . . . . . . . . . . . . . . . . . . . 3
4. Canonical Bytes and Output Commitment . . . . . . . . . . . . 5
5. Provenance Classes . . . . . . . . . . . . . . . . . . . . . 6
6. Verification Procedure . . . . . . . . . . . . . . . . . . . 6
7. Hash-Chained Job Timelines . . . . . . . . . . . . . . . . . 7
8. Public Resolution . . . . . . . . . . . . . . . . . . . . . . 7
9. External Anchoring . . . . . . . . . . . . . . . . . . . . . 7
10. Reference Implementation . . . . . . . . . . . . . . . . . . 8
11. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 8
12. Security Considerations . . . . . . . . . . . . . . . . . . . 9
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
14. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 10
15. Normative References . . . . . . . . . . . . . . . . . . . . 10
16. Informative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. 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
Zambo Expires 30 March 2027 [Page 3]
Internet-Draft AER-1 September 2026
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
Section 10.
2. 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 [RFC2119] [RFC8174] 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 Section 3.
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.
3. 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.
Zambo Expires 30 March 2027 [Page 4]
Internet-Draft AER-1 September 2026
+========================+==========+===============================+
| 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 Section 5. |
+------------------------+----------+-------------------------------+
| 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 |
| | | Section 6. |
+------------------------+----------+-------------------------------+
Table 1: Core receipt members
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 Section 8. In the
reference implementation the URL is https://zambo.dev/run/<id>.
Zambo Expires 30 March 2027 [Page 5]
Internet-Draft AER-1 September 2026
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.
{
"id": "130da435-e157-498e-af90-605866a86a27",
"receipt_schema_version": "0.3",
"created_at": "2026-09-23T23:45:20.760Z",
"tool": {
"name": "live_price",
"version": "4.0.0",
"scope": "public"
},
"provenance_class": "EXECUTED BY ZAMBO",
"canonical_bytes": "(elided; full value at the URL above)",
"output_hash": "(elided; full value at the URL above)",
"verification_status": "verified"
}
4. 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 [FIPS180-4].
A verifier that cannot obtain or reproduce the exact canonical bytes
MUST NOT report the output commitment as confirmed.
Zambo Expires 30 March 2027 [Page 6]
Internet-Draft AER-1 September 2026
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.
5. 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.
6. Verification Procedure
To verify a receipt, a verifier performs the following steps:
1. Resolve the public receipt URL and confirm the id in the
retrieved record matches the requested execution.
2. Read the exact canonical bytes, or the representation needed to
reproduce them byte for byte.
Zambo Expires 30 March 2027 [Page 7]
Internet-Draft AER-1 September 2026
3. Compute SHA-256 over those bytes and compare the result with
output_hash.
4. Review the tool, timestamp, caller scope, observed result,
evidence, and anchor status separately from the hash check.
5. 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.
7. 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.
8. 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.
9. 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.
Zambo Expires 30 March 2027 [Page 8]
Internet-Draft AER-1 September 2026
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.
10. Reference Implementation
A reference implementation of this vocabulary is deployed at the time
of writing, described at [AER-1-HOME]. 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 Section 6.
The endpoint and the receipt pages are independent live records:
anyone can reproduce the Section 6 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.
11. 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.
Zambo Expires 30 March 2027 [Page 9]
Internet-Draft AER-1 September 2026
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 (Section 5). 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 [RFC8785]. 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 Section 9 or with offline recomputation from the carried canonical
bytes.
12. 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.
Zambo Expires 30 March 2027 [Page 10]
Internet-Draft AER-1 September 2026
* 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
Section 9 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.
13. IANA Considerations
This document has no IANA actions.
14. 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.
15. Normative References
[FIPS180-4]
National Institute of Standards and Technology, "Secure
Hash Standard", DOI 10.6028/NIST.FIPS.180-4, FIPS 180-4,
August 2015.
Zambo Expires 30 March 2027 [Page 11]
Internet-Draft AER-1 September 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
16. Informative References
[AER-1-HOME]
Zambo, B., "AER-1: AI Agent Execution Receipt (open
draft)", https://zambo.dev/aer-1, September 2026.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
Author's Address
Brennan Zambo
Zambo
Email: brennanzambo@zambo.dev
URI: https://zambo.dev/aer-1
Zambo Expires 30 March 2027 [Page 12]