What should an agent receipt be able to prove?

Our first receipt was called attested, though nothing checked hardware evidence

Our first agent receipt, a signed record of an AI agent’s work, was called attested, though its verifier never checked the hardware evidence the word implies. Its successor, Signed Agent Receipt v0.2, can prove only that keys the recipient chose signed its bytes in a fixed format and logged them under one signed root. Every statement signed under it carries a scope object that marks five properties as unchecked: [10]

• not-implemented for attestation and observation;
• not-measured for retention;
• not-authenticated for time;
• not-checked for history.

We named that first draft, v0.1, the Attested Agent Receipt and dated it 20 October 2026. Its attestation slot, for evidence a chip signs about itself, was meant for a device certificate chain or a vendor quote. [1] In the prototype’s made-up sample it held only the signer’s bare public key, and the verifier reported its vendor or manufacturer root check as not implemented. [2] [9]

The same verifier passed a signed receipt with almost every field missing. [8] In a synthetic eight-leaf tree, it also computed the wrong root for valid proofs at four of the eight positions we tested. [6] [9] Our verifier essay takes those failures apart.

By 2 November the word was gone. [10] The v0.2 README says the format isn’t called attested because it validates no hardware roots, appraises no runtime and establishes no remote-attestation result. [11]

Both versions reuse Ed25519 signatures and Certificate Transparency’s Merkle hashing rather than inventing their own. [1] [10] A related framework, in-toto, checks a software supply chain through signed steps and a signed layout. Its assumptions fit that chain, and its results stop short of an agent’s private work. [7] What a format adds is its choices about which checks run, on which bytes, and what the result says about everything else.

A v0.2 pass means keys the recipient chose signed and logged these bytes

Trust comes from the recipient, not the receipt. The recipient hands the checker two trust files, one of issuer keys and one of log keys. The offline checker reads only the files it’s handed and calls no outside service. [10] [11]

Issuer and log keys must differ, and the internal review found a bug in that rule. An early v0.2 build compared the keys as text, so one key in two encodings could pass as both issuer and log. The fixed code compares them in one canonical form and rejects the bypass we tested. [12]

Canonical JSON (RFC 8785) gives each document one byte form, yet it still tells programs to check signed input against their own rules before acting on it. [3] Version 0.2’s fixed schema is that check.

A record that repeats a JSON member name fails, even when an escape sequence disguises the repeat. Integers must travel as decimal strings, and a bare JSON number is rejected outright rather than rounded. Each set of signing bytes starts with a label naming its role, so a signature made for the issuer can’t pass as the log’s. The checker then verifies both Ed25519 signatures. [10] [11]

A pass prints ARTIFACT CHECKS PASSED, and the specification says the checker never prints VERIFIED. A pass also prints what it doesn’t establish, including whether: [10]

• the issuer told the truth;
• it recorded every event;
• it used a measured runtime;
• it deleted anything;
• the time is trusted;
• successive roots form one history.

Most of that list also sits in the signed scope object. The receipt’s four inventory lists may be empty, even though every field is required. So a receipt that lists nothing still passes, and the result no longer suggests otherwise. [10]

The v0.1 files and their dated failure transcripts stay unchanged. The two versions are deliberately incompatible, and no v0.1 receipt may be relabeled as v0.2. [10] [12]

An internal review, done with AI agents’ help, checked v0.2 against deterministic synthetic fixtures and a separately written set of adversarial tests. [11] [12] Its record lists the commands, the cases covered, the failures found during the review and their rechecks. No outside cryptographer has reviewed v0.2. [12]

This site publishes the specification, README and review record, not the source code, tests or raw results. So you can read the contract and the record, but you can’t rerun the tests or check their results. [12]

Every field is the issuer’s claim until something else checks it

Each field records what the issuer says happened, and checking it takes evidence from outside the receipt. The v0.1 draft proposes fields including these, in an illustrative example that comes from no customer run, public log or attestation deployment. [1]

• the software: a runtime and its claimed binary measurement, proposed attestation evidence, and claimed model and policy hashes;
• the tools: each tool’s artifact hash and stated preflight verdict;
• the network: a ledger of destination hosts, byte counts and policy decisions;
• the files: hashed paths and operations;
• the money: payment methods, merchants and salted hashes of amounts.

A model hash names bytes the issuer says it loaded, and a preflight verdict records an earlier check, not what the tool did later. The draft never defines how to capture every event across every outside service. [1]

The retained field, the issuer’s stated count of prompt or output bytes kept after the run, is the clearest case. The draft requires zero for a conformance claim, but that zero is only the issuer’s word, with no inventory of remote providers, caches, logs or backups behind it. The v0.1 code simply checks that the supplied value is zero. [1] [2] Neither version observes an agent or proves deletion, and v0.2’s scope object marks retention not-measured. [2] [10]

Leaving data out doesn’t make the rest safe. Dropping prompts and file contents closes one route for leaks, but merchants, destinations, exact times, counts and path hashes can still identify the matter. [1] Our private-verification essay works through what these fields give away.

One signed root proves one snapshot, not time or history

Version 0.2 checks only whether this statement sits under this signed root. [10] A signed root is a snapshot of one moment, like a photo of a guest book. The photo shows your name, but not when you signed or whether a page was later torn out.

Certificate Transparency (CT) adds time and history. Each signed root in CT carries a timestamp, and CT pairs inclusion proofs with consistency proofs, which show that today’s log still holds everything yesterday’s did. [4] Our first draft copied CT’s Merkle hashing and inclusion proofs, but none of the timing or monitoring that makes CT useful. [1] [4]

A v0.2 receipt has no timestamp at all. Neither the statement nor the signed root carries one, and the scope object marks time not-authenticated. [10]

Nor can one root show that everyone saw the same history. Catching that takes consistency proofs, comparisons of signed roots and independent monitors. Our offline checker runs none of them, and the scope object marks history not-checked. [4] [10] And no log, CT’s included, can show that every run reached it, or who watched the events.

An attested receipt needs a checked chain from chip to observed action

Version 0.2 marks attestation and observation not-implemented, and we’ll call a receipt attested again only when something checks the device or runtime behind it. [10] Without a vendor or manufacturer root check, the v0.1 verifier trusted only the keys in its trust store. [1] [2] RATS, the IETF’s remote-attestation architecture, leaves three choices to the parties that appraise and rely on such evidence: the appraisal policy, the reference values and freshness. [5]

An attested receipt would need a chain of three checked links. The accepted evidence must tie to a measured component, that component to the receipt’s signing key, and the receipt to the observed action. A device can guard the signing key, but the key alone doesn’t say who collected the events or make the ledger complete.

Take one small claim, before adding any roots: a run’s only outbound request went to a permitted registry. Backing it would take four things: [5]

• a defined event interval, and the processes and network routes it covers;
• an observer that can challenge the issuer’s account;
• a binding from that observer’s event record to this receipt and policy version;
• challenge and audience rules, which stop anyone replaying old evidence.

Even then, the observer sees only part of the picture, and our private-verification essay maps what it misses. Broader claims, about execution or erasure, need broader evidence, not a stronger adjective on the same record.

Only the first of four questions has a cryptographic answer

Before you rely on an agent receipt, ours or anyone’s, ask four questions in order.

1. Which key signed it, and did you choose that key?
2. Which claims may that key make?
3. Who watched the events, and what could they miss?
4. Who else will read the fields, and what could they infer or link from them?

Only the first has a cryptographic answer, and the v0.2 checker is built to give it. The other three are human decisions, about authority, observation and disclosure. A receipt can name them but can’t make them for you. [10]

They take real engineering: getting and confirming keys outside the receipt, rules for which issuers may make which claims, rotation and revocation, and your own policy on time and scope. Someone also has to run the log, decide how long it keeps entries, check its consistency and settle conflicts between its signed versions.

On fields, our bet is that fewer is better. Each field should name who observed it and what question it serves. A record from one observer, cut to what one audit decision needs, should reveal less than a full trace and still let a reviewer catch an account that conflicts with the evidence.

The test on our proposed-studies page, designed but not yet run, could prove that bet wrong. If minimizing adds material errors a reviewer won’t accept, or fails its declared privacy measure, our field policy is wrong. Even a win would leave open whether this format beats a conventional export, minimized just as far.