ZAMBO.

AER-1 and SCITT agent execution evidence

Your agent finished a job on a system you do not control. The operator has a log. You have a summary the agent wrote about itself. When the client, the auditor, or your own future self asks what actually ran and what it produced, neither one is a record you can check. Two open efforts at the IETF work on that problem from two directions: AER-1 defines the record of the run itself, and SCITT defines the transparency layer a record can be registered into. They are not rivals for the same slot. They compose, and AER-1 was written so that they would.

Read the two sources first: draft-zambo-aer1-24 and draft-thaha-scitt-agent-execution-evidence-00 on the IETF Datatracker.

AER-1: IETF Internet-Draft draft-zambo-aer1-24 by Brennan Zambo, a portable execution receipt for AI agent tool calls. An Internet-Draft is not a finished standard.

AER-1 conformance: reference kit v1.5.6, conformance corpus of 119 test vectors and 122 checks, verifier published as aer1-verify, with independent implementations listed in the implementations registry

SCITT: Supply Chain Integrity, Transparency, and Trust; architecture in RFC 9943, COSE Receipts in RFC 9942. A Transparency Service returns a COSE Receipt evidencing that a statement was recorded in its append-only log.

The October profile: draft-thaha-scitt-agent-execution-evidence-00, "Agent Execution Evidence: A SCITT Profile for Verifiable Records of AI Agent Runs", filed 19 October 2026 by S. Thaha and S. Shamsudeen as an individual submission for discussion on the SCITT working group list

What this page is not: not a rating, not an endorsement, and not a conformance claim by either effort about the other. It is a crosswalk written from the two public texts.

The record of the run: AER-1

AER-1 (draft-zambo-aer1, now at revision 24) is a portable execution receipt for AI agent tool calls. When a job runs, the result it saves is digested at execution time and filed as a receipt: the tool, the inputs as digests, the saved result's digest, and where the record lives. Verification is recompute. Anyone can take the saved result, recompute its digest, and compare it against the filed receipt, with no key, no account, and no permission from the party that ran the job.

The receipt says one thing and is careful about it: the saved result has not changed since it was saved. It does not say the answer was right. Section 6 of the draft fixes the vocabulary for reporting checks on a receipt and its anchors, so a check that was never run is reported as "not checked" and never dressed up as a result.

AER-1 is shipped, not sketched. The reference kit is at v1.5.6, the conformance corpus carries 119 test vectors and 122 checks, the verifier is published as aer1-verify, and parties other than the author have implemented the draft independently and run it against the same corpus. The implementations registry on this hub lists them.

The transparency layer: SCITT, and the October profile

SCITT (Supply Chain Integrity, Transparency, and Trust, architecture in RFC 9943) defines how signed statements are registered with a Transparency Service, which returns a COSE Receipt (RFC 9942) evidencing that the statement was recorded in its append-only log. SCITT began in software supply chain provenance. Agents are its newest subject.

On 19 October 2026, S. Thaha and S. Shamsudeen filed draft-thaha-scitt-agent-execution-evidence-00, "Agent Execution Evidence: A SCITT Profile for Verifiable Records of AI Agent Runs", as an individual submission for discussion on the SCITT working group list. In its own terms, the profile defines signed statements that bind an agent's registered identity, declared capabilities, risk-based assessment, and supervised operational status to a hash-chained record of every call the agent makes. It also defines admission records, the serving party's own record of a call it received, registration policy, and offline verification bundles. Its Section 9.2 is explicit about what a passing verification does and does not establish, the same discipline of narrow claims. Its implementation status section describes a prototype: the authors' record model exists, and the encoding the document defines is not yet exported by that implementation.

How they compose: the scitt anchor

AER-1 Section 10 names the anchor types a receipt can carry: nostr, ots, witness, scitt, and rfc3161. The scitt anchor is the composition point. The AER-1 receipt stays what it is, a self-contained record anyone can verify by recompute. Anchoring registers the receipt's digest with a SCITT Transparency Service, and the COSE Receipt the service returns is filed as the anchor evidence for that registration.

Each layer then proves its own thing, and Section 6 keeps the reporting honest. The AER-1 check proves the saved result has not changed since it was saved. The anchor check reports the state of the transparency registration in the fixed outcome vocabulary: verified, verification failed, "rejected: unresolvable record", "not checked", or "absent". An unanchored receipt claims no anchor. A failed anchor check is stated as failed. Neither layer lends the other authority it did not earn, and neither claims the underlying answer was right. That judgment stays with the person checking, which is where it belongs.

If your problem is an agent that says "done" with nothing underneath to verify, start with the record: produce the evidence the AER-1 way, so it can be checked by anyone, and anchor it into SCITT where a transparency service is part of your audit picture.

Read the sources

Related