Summary

  • AER-1 revision 09 can prove that every visible execution-receipt entry belongs to one ordered, internally consistent chain. A presenter who can delete entries and rebuild the links can still produce a shorter chain that passes those checks.
  • The draft's optional external commitment binds the final entry digest, count, job identity and publication time. Count alone is insufficient, and even a good anchor proves only the endpoint of the recorded timeline—not that every real action was recorded.

An auditor receives six execution receipts. Their sequence begins at one and advances without a gap. Every prev_digest points to the digest the auditor independently recomputes for the preceding entry. One job identifier runs through the set. Only the final entry carries close:true. Every receipt hash matches its canonical bytes.

The chain verifies.

It may once have contained eight entries.

That is not a paradox, nor a newly discovered break in SHA-256. It is the explicit trust boundary in revision 09 of AER-1: A Portable Execution Receipt for AI Agent Tool Calls. A party able to remove entries from the beginning or end and recompute all surviving links can present a complete, valid shorter chain. Internal verification answers whether the chain in hand is self-consistent. It does not establish that the chain in hand is the original whole.

The draft was posted on 1 October 2026 as an active individual Internet-Draft. Datatracker warns that individual submissions are not endorsed by the IETF and have no formal standing in its standards process. Datatracker lists no RFC stream or intended RFC status; the document itself says Independent Submission and intended Informational. It expires on 1 April 2027 and is not an RFC. Those labels matter because implementation claims should not be mistaken for institutional adoption.

What the links actually bind

Revision 09 defines a job timeline as a non-empty array of chain entries. Each entry carries a previous digest, sequence number, job identifier, receipt identifier, tool name, provenance class, canonical receipt bytes, output hash and an optional close flag. To recompute the entry digest, a verifier decodes the receipt bytes, checks their own hash, then canonicalizes a JSON object containing close, id, job_id, output_hash, prev_digest, provenance_class, seq and tool. SHA-256 is applied to those canonical bytes.

The genesis entry uses 64 zero characters as its previous digest. Sequence numbers start at one and rise by exactly one. Every entry belongs to the same job. The last entry must close; no earlier entry may close. A verifier recalculates every digest rather than trusting stored links.

That construction is materially stronger than revision 06, whose entry digest covered only the decoded canonical receipt bytes. Revision 07 added the surrounding metadata to the commitment; revisions 08 and 09 retain that construction. A historical revision-06 chain therefore cannot be silently evaluated under current semantics. Version is part of the evidence.

Within its boundary, the current mechanism is useful. If someone edits a tool name, provenance class, receipt identifier, output commitment, job identifier, sequence or closing state without rebuilding the suffix, the next link breaks. Insertion, deletion, reordering and relabelling become visible when the attacker cannot regenerate the dependent chain.

The italic phrase is the control surface: when the attacker cannot regenerate the dependent chain.

A valid shorter history

Suppose entries seven and eight are removed from an eight-entry job. The presenter changes entry six to close the job and recomputes its digest. Because there is no seventh entry whose prev_digest commits to the old digest of entry six, the revised six-entry chain can satisfy every internal rule. Removing entries from the beginning is also possible if the remaining events are rebuilt as a new sequence starting at one with a new genesis link.

The draft calls this an honest limitation of hash chaining. It says a chain check alone must not be represented as truncation-proof. The system needs a commitment outside the chain: a witness, a timestamped head, an anchor, or a workflow manifest that binds the expected steps or count.

Revision 08 added guidance that such a commitment should bind the final digest. Revision 09 turns that guidance into an optional interoperable artifact containing four fields: job_id, final_entry_digest, entry_count and published_at. The commitment lives outside the chain. Putting it in the final entry would be circular because a final entry cannot contain its own final digest before that digest exists.

The verifier recomputes the visible final digest, counts the entries, checks the job identity and compares all of them with the external artifact. A failed comparison leaves the artifact non-binding. A separately retrieved matching commitment can show that the visible chain reaches the endpoint that a witness saw at a particular publication time.

Why the count is not enough

An eight-entry count can reveal a six-entry truncation. It cannot protect the content of the eighth entry.

Every non-final entry gains a second layer of protection because its digest appears in the following entry's prev_digest. The last entry has no successor. A presenter can replace the last entry, preserve the total count, recompute that last digest and still satisfy internal chain verification. A count-only promise sees eight entries before and after. An external promise of the final digest sees the substitution.

This is why the four fields belong together. The count constrains length. The final digest constrains the visible endpoint. The job identifier prevents an endpoint from being borrowed from another job. Publication time says when the witness made the commitment available. None is a substitute for the others.

Nor is publication the same as independent observation. An operator should preserve the commitment as published, the witness identity, the retrieval path, the retrieval time and the verification result. If the chain producer controls both the chain and an alterable commitment page, the architecture has two files but one trust domain.

An anchor does not enlarge the sensor

External anchoring strengthens continuity. It does not enlarge what the receipt system observed.

A passing receipt hash says that the canonical bytes in the receipt match their commitment. An entry marked LOGGED BY AGENT remains an agent report. Chaining it does not turn it into an independently observed tool call. A perfectly anchored visible timeline cannot show an unlogged side-channel action, an omitted call that never crossed the recorder, authorization that was never captured, or a real-world payment, delivery or configuration change that the receipt does not independently observe.

The distinction follows a simple operating discipline: the symbolic layer should claim only what its evidence can carry. The chain is a common format for preserving order and commitments. The witness can preserve an endpoint. Consequence authority remains with the organisation that decides what completeness is required and what external outcome must be confirmed.

For high-consequence jobs, endpoint integrity therefore needs a companion coverage plan. Preserve the authorised or expected-action set before execution; reconcile visible receipts against it afterwards; and collect outcome evidence from the system that actually owns the effect. A witnessed close is not a coverage receipt. A coverage receipt is not an outcome receipt.