What does a receipt check actually establish?

Our v0.1 checker printed VERIFIED for a near-empty receipt

On 2 November we gave our own v0.1 checker a near-empty agent receipt, a signed record of an AI agent’s work, and it printed VERIFIED. The receipt held three fields: a version, a one-leaf log entry and retained: 0, a claim that zero bytes were kept. Every check the program ran came out true for that receipt, and it had checked only a version string, two signatures, a proof and one number [8] [10].

The word sounded like a verdict on the whole receipt. Its full line read VERIFIED (signature and log, against the trust store); attestation root pending. The signatures were correct, made with keys we’d told the checker to trust [8] [10].

The checker was the reference verifier for Attested Agent Receipt v0.1, our first receipt draft, since archived [4]. It’s an offline Node program that sees only the files it’s given [5] [6]. We kept its code and failure records and wrote a stricter format, Signed Agent Receipt v0.2 [11].

The v0.1 checks were too few, and one read proof directions backwards

The checker did less than the word VERIFIED suggests, and some of what it did was wrong. It runs six steps, in this order [5] [6]:

1. It checks that the version field, aar, equals "0.1".
2. It writes the body in one fixed byte form.
3. It checks the Ed25519 signature against a key from the supplied trust store.
4. It computes the leaf, the receipt’s entry in the log, from a hash of the canonical body without its log field.
5. It checks the log proof against a supplied signed head, the log’s signed root and size.
6. It checks that the retained field is zero.

That’s the whole list, apart from a ledger summary that only counts the entries it was handed and always prints PASS. Nothing checks a policy or observes an effect [5] [6]. The code requires none of the draft’s other fields, so the near-empty receipt passed without a run ID, issue time, runtime, model, policy, attestation, tools or ledger [6] [8].

We wrote the same receipt with two retained fields, 99 then 0, and it also returned VERIFIED, because the JSON parser kept the last value [6] [8]. JCS (RFC 8785) forbids duplicate field names [1]. The signature covered the parsed object, so this is a missing rejection rule rather than a forged signature [8].

In the draft, one sentence says the signature covers the body hash, while other passages, and the code, use the canonical body bytes. The code computes the hash only to display it [4] [6]. The draft’s sort rule is off too: JCS sorts member names by UTF-16 code units, the draft says code point, and the orders differ for some characters [1] [4].

The canonicalizer keeps a lone surrogate, where JCS requires an error, and writes a numeric overflow as null [1] [6]. The code’s own comment calls its canonicalizer a subset, so it makes no claim of full RFC 8785 conformance [6].

The proof check holds the clearest case of a test passing for the wrong reason. A log proof gives one sibling hash per level. The leaf’s position and the tree size fix whether each sibling sits left or right, a list of turns read from the bottom up [2].

The v0.1 code took the siblings from the bottom but the turns from the top [6]. We built an eight-leaf tree and its bottom-up proofs ourselves, without the code’s sample generator. Every proof was valid, yet in that one tree the code returned the wrong root for half of them [7]:

• positions 1, 3, 4 and 6 gave the wrong root;
• positions 0, 2, 5 and 7 gave the right one.

The four that passed have turns that read the same both ways. The shipped sample uses position 5, whose turns run right, left, right, so it could never have shown the bug [6] [7].

In the v0.1 code, the bytes a log signs for its head, sthBytes, cover only the log ID, root and tree size [4] [6]. We added a timestamp to a head without re-signing it, and the checker still accepted it [8]. The body’s own issue time, issued_at, is signed, but it’s still only the issuer’s claim. The program offers neither trusted event time nor replay detection [6].

The dated check record and its raw result transcript are published [8] [10]. So is the portable runner that produced the transcript [9].

Each output line reports one check; the label claimed more

Each line the checker prints reports one check, and only the final label speaks for the whole receipt [5] [6]. A passing line means at most that its check came out true for these inputs. A skipped check stays skipped, however many other lines pass.

Even VERIFIED, the label the near-empty receipt got, vouches for nothing in its last cell.

We reran the checker’s own fixtures read-only on Node 22.22.3 [10]:

• the sample receipt with trust and head exits 0;
• the same receipt without trust exits 3;
• the tampered and forged-root fixtures exit 1.

The forged-root fixture is weaker than its name suggests. It changes the receipt’s signed copy of the root without re-signing, so the signature fails. The log check still passes, since the checker treats that copy as informational and checks the proof against an independently signed head. So the fixture is no independent test that every root an attacker might choose gets rejected [6] [7].

Our near-empty and duplicate receipts also exited 0. We chose their keys, so they show missing input rules, and they don’t show a forgery against someone else’s key [8]. Some malformed inputs crash the program instead, a sixth outcome the table leaves out [6]. A usage error, exit 2, sits outside it too [5].

The recipient picks the keys, and a key isn’t a witness

A receipt can’t choose its own judge, so whoever relies on it has to pick the trusted keys. Picture a job applicant who supplies a reference’s phone number. The call reaches whoever the applicant picked.

Trust a key found inside a receipt, and a valid signature shows only that its maker held the matching private key. A root it supplies is no better, since a proof can match it yet place the entry in no log you accept.

Our first design got this right, and v0.2 keeps it [11]. The v0.1 trust store maps each runtime-key ID and log ID to a public key, and the signed head arrives separately. One thing the v0.1 checker takes on faith is the trust-store file itself, so those keys need an independent source that keeps them current [4] [5].

No JSON document can decide which issuers and logs to accept, who hands out their keys, how to rotate them, what to do after a compromise or which policy applies. Even a genuine signed head from a log you accept leaves open whether the log is complete, whether others saw the same history and whether the event happened.

RFC 9162, the Certificate Transparency (CT) specification, separates inclusion proofs from consistency proofs, describes log monitors and warns of split views [2]. One proof against one signed root can’t see a log’s history, and neither of our versions implements CT [6] [11]. Our spec essay covers what one root can show.

A trusted key can still sign a false or incomplete account. Had the near-empty receipt listed every field, it would still be only the issuer’s word. The W3C’s Verifiable Credentials model draws the same line, between checking a secured statement and judging whether its claims are true [3].

The v0.1 program never looks past the bytes. It appraises no hardware evidence and only compares a stated retained count with zero [5] [6]. Proof that an event happened needs an observer that states what it could see and ties its record to the receipt and policy version. Our private-verification essay takes up that observer.

v0.2 requires every field, and a pass claims less

The v0.2 spec answers with stricter rules and a narrower claim. Every field is required, so the spec rules out a receipt as bare as ours. A field that appears twice is rejected, even when one copy hides its name behind an escape sequence, and plain JSON numbers are rejected. Each signature covers exact bytes that start with a label naming its role, issuer or log, and the issuer key and the log key must be different keys [11] [12].

The one positive result, ARTIFACT CHECKS PASSED, means three things and no more. The receipt matches a fixed schema, keys the recipient chose made its signatures, and it sits under one signed log root. Hardware attestation, execution, complete observation, retention, deletion, time and log history all stay outside that result [11].

A receipt with all four inventory lists empty still passes, and the result no longer says anything an empty list would contradict [11]. Our spec essay walks through the format and why it dropped the word attested.

Our evidence for v0.2 is one internal review, done with AI agents’ help, whose adversarial tests were written separately from the code. We publish a summary of its record, but not the v0.2 source code, tests or fixtures, and no outside cryptographer has reviewed v0.2 [12] [13].

A checker should say which checks it ran, and stop

A receipt checker should list the checks it ran and claim nothing more, whatever format carries the record. Our first checker failed that test, and v0.2’s result passes it by claiming less [11].

The strongest objection is that our format shouldn’t exist. Ordinary signed JSON, checked with well-maintained libraries, already ties bytes to a key. We haven’t tested whether a custom format adds anything over the same fields in plain signed JSON. We also have no performance measurements that would justify a custom format.

If a well-maintained signed-JSON tool can print a result that lists its checks and stops, use it. More confidence needs an outside cryptographer’s review and a second checker, maintained by someone else, that agrees with ours on shared test vectors [12] [13].

Once the bytes are handled well, the hard question moves to events: signed lies, omitted effects, controlled bypasses and hidden histories that no reviewer could tell apart. A checker’s output can’t sort them. Our proposed-studies page sets out a study for them.