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

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 27 March 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

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 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.¶

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>.¶

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.¶

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.¶
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.¶

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.¶

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.¶
• 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.¶

Author's Address