AER-1 Receipts as Audit Records for WIMSE AIMS

Introduction Section 11 of the WIMSE AIMS framework [AIMS] makes monitoring and observability a security control. It requires that "deployments MUST produce durable audit logs covering authorization decisions and subsequent remediations", that "Audit records MUST be tamper-evident and retained according to the security policy of the deployment", and it enumerates the minimum content of an audit event. It further states that implementations should let operators "reconstruct a complete execution chain of an agent task, including delegated authority, intermediate calls, and resulting actions across service boundaries". AIMS defines the requirement and the minimum field list; it does not define a record format, a digest construction, or a verification procedure. AER-1 [AER1] defines exactly those three things for one agent tool call: a JSON receipt record (Section 3 of [AER1]), a SHA-256 output commitment over canonical bytes (Section 4 of [AER1]), and a verification procedure any third party can run (Section 6 of [AER1]). AER-1 receipts chain into hash-linked job timelines (Section 7 of [AER1]) and bind into workflow receipts with a Merkle root over the step sequence (Section 8 of [AER1]). This document is a mapping, not a new format. Section 3 maps each AIMS Section 11 audit requirement to the AER-1 construct that satisfies it, including the points where AER-1 records more than AIMS asks and the points where a deployment must supply a binding AIMS assumes. Section 4 covers execution chain reconstruction. Section 5 defines optional carriage of receipts as SCITT [SCITT] statements, building on the external anchoring that [AER1] already permits in its Section 10. Section 6 states the limits of the mapping.

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. Terms from [AER1] (receipt, canonical bytes, output commitment, provenance class, execution context) and from [AIMS] (Agent, Tool, System, delegated subject) are used with the meanings those documents give them.

Mapping AIMS Audit Events to AER-1 Receipts AIMS Section 11 requires an audit event to record, at a minimum, the seven items in the left column below. The right column names the AER-1 construct that carries each item. +================================+================================+ | AIMS Section 11 audit field | AER-1 carrier | +================================+================================+ | Authenticated agent | The "tool" member's caller | | identifier | scope and the receipt's | | | provenance class (Sections 3 | | | and 5 of [AER1]); the | | | execution_context member | | | records the framework and | | | model that issued the call | | | (Section 3.2 of [AER1]). | +--------------------------------+--------------------------------+ | Delegated subject (user or | The caller scope recorded in | | system), when present | the "tool" member, bound by | | | the deployment to its subject | | | identifiers (see the note | | | following this table). | +--------------------------------+--------------------------------+ | Resource or tool being | The "tool" member (name and | | accessed | version), and the | | | execution_context "source" | | | member naming the system the | | | call acted upon. | +--------------------------------+--------------------------------+ | Action requested and | The receipt record itself. | | authorization decision | AER-1 requires a receipt for | | | every call received, including | | | a call rejected before | | | execution; the rejection | | | receipt records the requested | | | tool, the arguments as | | | received, and the error | | | returned (Section 3 of | | | [AER1]). | +--------------------------------+--------------------------------+ | Timestamp and transaction or | The "created_at" member | | request correlation | (RFC 3339) and the receipt | | identifier | "id" (a UUID); correlation | | | across calls and services is | | | carried by the chain linkage | | | of Section 7 of [AER1] and | | | the workflow membership of | | | Section 8 of [AER1]. | +--------------------------------+--------------------------------+ | Posture assessment or risk | execution_context extension | | state influencing the | members (Section 3.2 of | | decision | [AER1]). Posture is context: | | | it sits outside the hashed | | | core and MUST NOT change the | | | meaning of the core members. | +--------------------------------+--------------------------------+ | Remediation or revocation | A remediation or revocation | | events and their cause | is itself an action taken | | | through a tool or system; the | | | receipt issued for that action | | | records it, ordered among the | | | events it remediates by the | | | chain rules of Section 7 of | | | [AER1]. | +--------------------------------+--------------------------------+ Delegated subject. AIMS assumes deployments have subject identifiers; AER-1 carries the caller scope under which a call was made and the provenance class that states who ran or reported the action. A deployment adopting this mapping binds its subject identifiers to caller scopes in its own configuration, the same place AIMS Section 12 puts the rest of the deployment's authentication and authorization policy. The binding is deployment policy, not something the receipt format can assert on the deployment's behalf. Authorization decisions. The load-bearing row of the table is the fourth. AIMS requires the log to cover authorization decisions, and a decision to deny is the case conventional logging most often loses, because nothing executed and ad hoc logs are written by the executor. AER-1 inverts this: its Section 3 makes issuance independent of execution. A producer MUST issue a receipt for every tool call it receives, including a call it rejects before execution, and "a call that leaves no receipt is a conformance failure: the absence of a record MUST NOT be allowed to hide an attempted call." A deployment whose policy point rejects a request before any tool is invoked applies the same rule at that point: the component that received the request issues the rejection receipt, so the denial is a first-class, checkable record rather than a gap. Tamper evidence. AIMS requires audit records to be tamper-evident. An AER-1 receipt carries the exact canonical bytes of the recorded result and a SHA-256 output commitment over them (Sections 3 and 4 of [AER1]), plus a metadata binding (Section 3.1 of [AER1]). The verification procedure (Section 6 of [AER1]) recomputes the digest and compares; a record altered after issuance fails the comparison. Sequenced receipts additionally chain (Section 7 of [AER1]), so removal or reordering of records within a job timeline is detectable against the chain. Durability and retention. AIMS leaves retention periods to deployment policy. AER-1 receipts resolve at stable public URLs (Section 9 of [AER1]) and are self-contained JSON records, so a deployment can retain them in any store that preserves bytes; the commitment makes any later alteration of the retained copy detectable regardless of the store.

Execution Chain Reconstruction AIMS Section 11 states that implementations should let operators reconstruct a complete execution chain of an agent task across service boundaries. AER-1 provides two compositions for this. Within one producer, receipts form a hash-chained job timeline (Section 7 of [AER1]): each entry digest binds the entry to its predecessor, so the chain is ordered and gaps are visible. Across steps, a workflow receipt (Section 8 of [AER1]) binds an ordered sequence of step receipts, which may originate from different services, to a single goal, with a Merkle root over the step sequence and bidirectional links between the workflow and each step. An auditor holding the workflow receipt can enumerate the steps, resolve each step receipt at its public URL, and verify each step under Section 6 of [AER1] and the whole under Section 8.2 of [AER1], without an account with, or the cooperation of, any of the producing services. This is the reconstruction AIMS asks for, expressed over records that were checkable when they were issued rather than assembled after the fact.

Carriage as SCITT Statements [AER1] Section 10 already permits external anchoring of receipts, including anchoring to a SCITT [SCITT] transparency service. For deployments that operate or use such a service, this section fixes the carriage so independent implementations produce the same statements. The receipt producer issues a SCITT Signed Statement whose payload is the AER-1 receipt as a JSON object, whose subject is the receipt "id", and whose issuer is the producer's SCITT issuer identity. The statement's payload digest therefore commits to the same bytes the receipt's own metadata binding commits to, and the two commitments can be compared by any verifier. On registration, the transparency service returns a Transparent Statement carrying its inclusion proof; a verifier evaluating the receipt reports the anchor's outcome using the per-anchor outcome vocabulary of Section 6 of [AER1] (verified, verification failed, rejected: unresolvable record, not checked, or absent), so an unevaluated anchor is never reported with an evaluated outcome. Carriage under this section is OPTIONAL. A receipt that is never registered with a transparency service remains fully verifiable under Section 6 of [AER1]; registration adds an independently operated witness to the receipt's existence and content at a point in time, and, because a transparency service authenticates its issuers, a path to issuer authentication for deployments that require it (see Section 6). Related work in the same space binds agent evidence differently: [THAHA-BINDING] binds AI agent credential evidence using in-toto predicates within the WIMSE credential story, and [THAHA-SCITT] profiles SCITT for agent execution evidence. This document is complementary to both: it starts from the AER-1 record, which exists independently of any credential or transparency infrastructure, maps it to the AIMS audit requirements, and treats SCITT strictly as an optional carriage and anchoring layer.

Security Considerations A receipt proves a narrow thing, and this mapping inherits the narrowness. Verification under [AER1] establishes that the saved record was not changed after it was saved. It does not establish that the recorded action was correct, that it was authorized, or that the outcome it reports is true of the outside world. An AIMS deployment MUST NOT treat the presence of a valid receipt as evidence that an action was permitted; the receipt is the record of the decision and the action, and policy evaluation remains the deployment's own function, exactly as AIMS Section 12 frames it. The base AER-1 format does not authenticate the issuer of a receipt; [AER1] discloses this normatively in its own text. Provenance classes (Section 5 of [AER1]) state who ran or reported an action, but a class label is a claim, not a proof. Deployments whose threat model requires issuer authentication use an authenticated anchoring path: the SCITT carriage of Section 5, where the transparency service authenticates issuers, or another anchor medium permitted by Section 10 of [AER1] that binds the receipt digest under an identity the deployment trusts. Section 10.2 of [AER1] applies throughout: binding a receipt to an external record does not transfer the claims of one to the other. Posture and risk state recorded in execution_context are context supplied by the producer. Section 3.2 of [AER1] places execution_context outside the hashed metadata core, so a verifier MUST NOT treat posture members as evidence of the state they describe; they record what the producer reported, and a deployment that needs posture it can rely on must obtain it from its own policy components. Clock trust and equivocation limits for chained timelines are as stated in Section 13 of [AER1].

IANA Considerations This document has no IANA actions.

References

Normative References [AER1] Zambo, B., "AER-1: A Portable Execution Receipt for AI Agent Tool Calls", Internet-Draft draft-zambo-aer1-26, October 2026, <https://datatracker.ietf.org/doc/draft-zambo-aer1/26/>. [AIMS] Kasselman, P., et al., "AI Identity Management System", Internet-Draft draft-ietf-wimse-aims-00, September 2026, <https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/00/>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Informative References [SCITT] Birkholz, H., et al., "An Architecture for Trustworthy and Transparent Digital Supply Chains", Internet-Draft draft-ietf-scitt-architecture-22, <https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/22/>. [THAHA-BINDING] Thaha, A., "Evidence Binding for AI Agent Credentials", Internet-Draft draft-thaha-wimse-agent-evidence-binding-00, <https://datatracker.ietf.org/doc/draft-thaha-wimse-agent-evidence-binding/00/>. [THAHA-SCITT] Thaha, A., "Agent Execution Evidence: A SCITT Profile for Verifiable Records of AI Agent Runs", Internet-Draft draft-thaha-scitt-agent-execution-evidence-00, <https://datatracker.ietf.org/doc/draft-thaha-scitt-agent-execution-evidence/00/>. [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

Acknowledgments The AIMS framework's decision to state audit requirements, including the minimum audit event fields, without mandating a record format is what makes a mapping document like this one possible. The AER-1 conformance community's independent implementers produced the interoperability evidence cited in the Implementation Status section.