agenticweb.wiki

Agent Audit Trail

Last checked · 42 primary sources

For the WIMSE in-toto/DSSE authorization-decision audit record format (draft-gilda-wimse-agent-audit-record), see Agent Audit Record. For the COSE/SCITT execution receipt profile (draft-emirdag-scitt-ai-agent-execution), see AI Agent Execution Profile of SCITT. For campaign and conversion telemetry attribution (AAP), see Agent Attribution Protocol.

Overview

Agent Audit Trail (AAT) is an application-layer audit record specification defined in the individual IETF Internet-Draft draft-sharif-agent-audit-trail, authored by Raza Sharif at CyberSecAI Ltd [1][2]. First submitted as -00 on 29 March 2026 and updated through revision -09 on 26 October 2026, the draft specifies a canonical JSON record schema, a seven-part action taxonomy, graded recording independence, pre-execution policy-enforcement semantics, SHA-256 hash chaining over RFC 8785 canonical JSON, optional classical and post-quantum signatures, and computational reproducibility rules for autonomous AI agents [1][2][4]. In the Abstract of draft-sharif-agent-audit-trail-09, Sharif summarizes the core design [1]:

"This document specifies a standard logging format for autonomous AI agent systems. The Agent Audit Trail (AAT) defines a JSON-based record structure with mandatory fields for agent identity, the authorizing principal, action classification, outcome tracking, and trust level reporting. Records are linked via tamper-evident hash chaining using SHA-256 per RFC 8785, with optional ECDSA signatures for non-repudiation." [1]

The specification positions its record schema and retention mechanics around emerging AI governance and security frameworks — specifically the EU Artificial Intelligence Act (Regulation (EU) 2024/1689, with high-risk application dates staged to 2 December 2027 for Annex III systems and 2 August 2028 for regulated products under Regulation (EU) 2026/1744), SOC 2 Trust Services Criteria, ISO/IEC 42001, draft ISO/IEC 24970, prEN 18229-1, and PCI DSS v4.0.1 — while supporting GDPR Article 17 erasure through signed tombstone replacement [1]:

"The format addresses requirements from the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems, whose application dates were staged into 2027-2028 by Regulation (EU) 2026/1744. It also maps informatively to SOC 2 Trust Services Criteria, ISO/IEC 42001, the draft ISO/IEC 24970 and prEN 18229-1 logging standards, and PCI DSS v4.0.1 logging requirements. The design is transport-agnostic and supports export to JSONL, Syslog (RFC 5424), and CSV while preserving chain integrity. Privacy is addressed through input/output hashing, content fingerprinting, and tombstone-based deletion compatible with GDPR Article 17." [1]

Beginning with revision -04 and expanded in -07, Section 11 explicitly bounds these regulatory crosswalks as informative evidence mappings rather than legal compliance certifications [1][7][8]:

"The mappings in this section are INFORMATIVE. They indicate where AAT records can supply evidence relevant to an obligation; they are not a compliance assessment and do not assert that adopting AAT satisfies any regulation or standard. Several of the referenced instruments are drafts under active development, and their requirements may change." [1]

Mandatory Record Schema, Authorizing Principal, and Action Taxonomy

Every AAT entry is a JSON object containing 13 mandatory top-level fields (Section 3.1 of -09): record_id (fresh UUIDv4 per RFC 9562), timestamp (RFC 3339 with mandatory UTC offset), agent_id (RFC 3986 URI matching the Agent Passport when paired with draft-sharif-mcps-secure-mcp), principal (authorizing party object added in -07), agent_version (Semantic Versioning string), session_id (UUIDv4 shared across a session), action_type, action_detail (type-specific JSON object), outcome (success, failure, timeout, denied, or escalated), trust_level (L0 through L4), record_phase (pre_execution, post_execution, or concurrent, added in -01), parent_record_id (previous record_id, or null on the genesis record), and prev_hash (64-character lowercase hex SHA-256 digest of the previous record, or null on the genesis record) [1][5][8][28].

The principal object introduced in revision -07 requires every record to bind the action to the human, organization, service, or upstream agent on whose authority the agent acted via principal_type, principal_id, and authority_ref (which can reference an authorization_record_id, a delegation record, an OAuth 2.0 token identifier, or a WIMSE authorization-evidence Permit from draft-munoz-wimse-authorization-evidence-01), while preserving backward compatibility for archives produced under -06 and earlier [1][8][30]:

"Every record MUST name a principal, so that the record establishes not only what the agent did (agent_id) but on whose authority it did it." [1]

"Records produced under revision -06 and earlier predate this field. A verifier processing a mixed-revision archive SHOULD treat the absence of "principal" in such records as "principal not recorded" rather than as a validation failure." [1]

Section 7 defines seven registered action_type values and their required action_detail members: tool_call (tool_name, parameters_hash, optional tool_server, tool_version, authorization), tool_response (tool_name, response_hash, parent_call_id), decision (decision_type, optional reasoning_hash, confidence, alternatives_considered, policy_ref, authorization_record_id), delegation (cross-agent authority handoffs with target_agent_id and delegated_scope), escalation (human-in-the-loop handoffs), error (including crash recovery gaps), and lifecycle (session_start, session_end, heartbeat, and record_deleted tombstones) [1]. Trust levels L0 (unverified) through L4 (mutual authentication with revocation checking and continuous monitoring) align with Sharif's companion MCP security draft draft-sharif-mcps-secure-mcp-01 [1][28]:

"This document specifies MCPS (MCP Secure), a cryptographic security layer for the Model Context Protocol (MCP). MCPS adds agent identity verification, per-message signing, tool definition integrity, and replay protection to MCP communications" [28]

Pre-Execution Recording and Three-Tier Recording Independence

To prevent post-hoc observation logs from being presented as proof of active policy enforcement, revision -01 introduced Section 4 (Pre-Execution Recording) and the mandatory record_phase field [1][5]. Whenever an agent decision or delegation is denied or escalated — and before any state-modifying action in a high-risk deployment — the record must be written and chained with record_phase: "pre_execution" before the action runs [1]:

"When action_type is "decision" and outcome is "denied", the record MUST have record_phase set to "pre_execution". A denial that is only logged after execution provides no evidence that the denial was enforced." [1]

Section 5 (Recording Independence) establishes three tiers of recorder separation [1][5][7][9]: 1. Self-Recording (L0 and L1, Section 5.1): The agent writes its own records (recording_mode: "self"), which the specification notes carries weaker evidentiary weight [1]:

"Self-recording provides weaker evidentiary guarantees because the agent could, in principle, omit or alter records of its own actions without external detection." [1] 2. Independent Recording (L2 and above, Section 5.2) & Fail-Safe Trust Assignment (Section 5.3): At L2 and above, records should be emitted from an independent OS security principal — such as an API gateway, reverse proxy, sidecar, or MCP middleware — that signs records with a distinct key (signer_kid per RFC 7638) [1]: "For deployments at trust level L2 and above, audit records SHOULD be written by a component independent of the agent." [1] To prevent an operator from bypassing independent recording by classifying high-impact actions at L0 or L1, revision -04 added Section 5.3 (Trust-Level Assignment Integrity), requiring a fail-safe L2+ default for consequential actions unless an explicit, chained trust_assignment.downgraded: true object attributes the classifier and policy version [1][7]: "The following are consequential actions and MUST be assigned a "trust_level" of L2 or above by default: any "tool_call" or "decision" whose action_detail indicates a payment or fund movement, deletion of data, deployment to a production environment, transfer of authority ("delegation"), or egress of data to an external party. A conforming recorder MUST NOT assign a consequential action a trust level below this default UNLESS a "trust_assignment" object (Section 3.2) is present with "downgraded" set to true." [1] 3. Hardware-Attested Recording (Section 5.4, added in -08): To prove that the independent recording component itself executed on genuine, unmodified platform software and hardware, revision -08 added an optional platform_attestation object that binds a Remote ATtestation procedureS (RFC 9334: Remote ATtestation procedureS (RATS) Architecture) Verifier appraisal result (bound_value) directly to the session genesis or Merkle epoch root, following the composition pattern in M. Sokolov's draft-sokolov-rats-aep-composition-00 [1][9][31][40]: "The platform of the recording component is appraised by a RATS Verifier [RFC9334] against an endorsed reference, and the resulting attestation is bound to the audit trail through the "platform_attestation" object (Section 3.2)." [1] "This document sketches a composition pattern in which an application- layer "action evidence package" (AEP) — a signed, append-only record of an action taken by an automated (for example, AI-agent) system, the authority under which it was taken, and its outcome — is treated as Evidence in the sense of the RATS Architecture (RFC 9334) and bound to platform Evidence produced by a hardware root of trust." [31] "This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims." [40]

Tamper-Evident Chaining, Post-Quantum/Classical Signatures, Merkle Batching, and GDPR Tombstones

Section 6.1 links every record in a session by hashing the RFC 8785 canonical JSON serialization (RFC 8785: JSON Canonicalization Scheme (JCS)) of the preceding record [1][36]:

"Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable." [36]

In revision -09 (26 October 2026), Section 6.1 was corrected — following an interoperability review by Parker Piehl — to explicitly strip any detached batch object before computing prev_hash(N), matching the verification rules in Sections 3.2, 6.2, and 6.3 [1]:

"prev_hash(N) = hex(SHA-256(JCS(record(N-1) with any "batch" object removed))) For the genesis record (N=0), prev_hash MUST be null." [1]

"The author thanks Parker Piehl for identifying the inconsistency between Sections 6.1 and 6.3 corrected in -09." [1]

Section 6.2 (Signature Envelope) signs the 32-byte SHA-256 digest of the JCS-canonicalized record (including sig_alg and signer_kid, excluding signature, signature_classical, and batch) under one of three registered algorithms [1][7]: - ES256 (Default): ECDSA P-256 per FIPS 186-5 encoded as 64-byte IEEE P1363 r||s Base64url [1]:

"For a "sig_alg" of "ES256" (the default), sign using ECDSA P-256 per FIPS 186-5 [FIPS186-5] and encode as Base64url (RFC 4648 Section 5) using IEEE P1363 fixed-length r||s (64 bytes total: 32 r, 32 s)." [1] - ML-DSA-65 (Added in -04): FIPS 204 lattice-based post-quantum signature over the 32-byte hash (optionally paired with a classical ECDSA P-256 signature_classical in hybrid mode) for long-retention legal evidence [1][7]: "For a "sig_alg" of "ML-DSA-65", sign using ML-DSA-65 per FIPS 204 [FIPS204] over the same 32-byte hash and encode the raw signature as Base64url. ML-DSA-65 SHOULD be used where records must remain verifiable beyond the anticipated lifetime of classical signatures (e.g., legal evidence subject to long retention and "harvest-now, verify-later" threats)." [1] - Ed25519 (Added in -09): Pure EdDSA per RFC 8032 for deployments that already manage Ed25519 keys [1]: "For a "sig_alg" of "Ed25519", sign the same 32-byte hash as the message using Ed25519 (pure EdDSA) per RFC 8032 [RFC8032] and encode the 64-byte signature as Base64url. Ed25519 is OPTIONAL. It allows implementations that already hold Ed25519 keys to produce conforming records; "ES256" remains the default." [1]

For high-throughput workloads and compact inclusion proofs, Section 6.4 (added in -04) defines optional Merkle batch anchoring using the domain-separated tree construction of RFC 6962 / RFC 9162 (RFC 9162: Certificate Transparency Version 2.0, 0x00 leaf prefix and 0x01 interior node prefix), producing an epoch merkle_root and per-record inclusion_proof that can be anchored to an RFC 3161 Timestamp Authority, WORM storage, a Supply Chain Integrity, Transparency, and Trust (RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains) transparency service, or a RATS platform_attestation [1][7][37][39]:

"This OPTIONAL mode lets a recording component anchor a batch of records under one Merkle root, yielding logarithmic-size inclusion proofs and a single external anchor per batch. It COMPLEMENTS and does not replace the hash-chain; "prev_hash" and its verification (Sections 6.1 and 6.3) remain in force." [1]

"This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves." [37]

"SCITT [SCITT] provides a transparency service and signed receipts over statements; an AAT session hash or Merkle batch root (Section 6.4) MAY be registered with a SCITT transparency service as the external anchor used in Section 6.3, step 9." [1]

"This document defines such an architecture for single-issuer signed statement transparency." [39]

To reconcile append-only hash chaining with GDPR Article 17 right-to-erasure obligations, Section 9.3 replaces erased records with a lifecycle tombstone (event: "record_deleted") that preserves record_id, parent_record_id, prev_hash, tombstone_hash (the original record's hash so the following record's prev_hash still verifies), and optional content_fingerprint [1]. Revision -06 closed a tombstone-forgery vector by requiring the deleting authority to compute a fresh signature over the tombstone record itself in signed chains [1]:

"In a signed chain, carries a NEW signature computed by the deleting authority over the tombstone record itself (Section 6.2), with the deleting authority's own "signer_kid". The original record's signature MUST NOT be copied into the tombstone: a signature retained from the deleted record does not cover the tombstone's content and would allow a forged tombstone to erase any signed record while still verifying." [1]

Decision Reproducibility, Attestation Closure, and Relationship to WIMSE and SCITT

Added in revisions -02 and -03, Section 13 separates record reproducibility (re-verifying the hash chain and signatures, available for any model) from decision reproducibility (re-executing inference to obtain byte-identical output, restricted to open-weight models run with deterministic decoding in a pinned environment) [1][6]:

"A decision that is only recorded is "reconstructable", not "reproducible"." [1]

Section 13.6 (Attestation Closure) requires that a record only set reproducibility_class: "reproducible" when every component of the computational closure (model_weights_digest, tokenizer_digest, chat_template_digest, engine_build_digest, inference_config, environment, and sealed input) is pinned and digested [1][6]:

"A decision record MUST NOT set reproducibility_class to "reproducible" unless its attestation is closed: the weights, tokenizer, chat template, and engine build are digested (Section 13.3); the complete decoding configuration is recorded in inference_config; the numeric environment (hardware, batch_size, num_threads) is recorded in the environment object; and the input is sealed." [1]

Section 1.3 (Relationship to Other Work, added in -07) situates AAT alongside the WIMSE audit and authorization-evidence specifications (draft-gilda-wimse-agent-audit-record-02 and draft-munoz-wimse-authorization-evidence-01) and adjacent SCITT agent execution profiles (draft-emirdag-scitt-ai-agent-execution-01 and draft-mih-scitt-agent-action-capsule-00) [1][8][29][30][32][33]:

"The WIMSE agent audit record work [WIMSE-AUDIT] defines a minimum field set and requires attestation by an observer the agent does not control. AAT instead defines graded recording independence (Section 5), permitting self-recording only at L0 and L1 and requiring an independent recorder at L2 and above, and adds pre-execution enforcement evidence (Section 4) and decision reproducibility (Section 13), which that work does not cover." [1]

"This document defines a record format for AI agent authorization decisions. The format is one in-toto predicate type, signed inside a DSSE envelope. It carries the seven minimum audit fields that the WIMSE AI Identity Management System framework requires, and two properties that make those fields checkable: a canonicalization contract, and both the authorization decision and the observed effect with a derived three-valued agreement between them." [29]

"This document specifies a companion profile to the AI Agent Authentication and Authorization draft [I-D.klrc-aiagent-auth], defining a signed authorization-evidence record produced by WIMSE- authorized AI agent actions." [30]

"This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions." [32]

"This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule." [33]

On 19 September 2026, Raza Al-Rehman Sharif filed updated IETF IPR Disclosure #7609 (IPR Details - Raza Al-Rehman Sharif's Statement about IPR related to draft-sharif-agent-audit-trail, draft-sharif-openid-agent-identity, and draft-sharif-aeba) covering UK Patent Application GB2606543.3 (Agent Lifecycle Jurisdictional Compliance Forensics AML KYA, filed 25 March 2026), replacing the earlier #7559 declaration with a royalty-free RAND commitment to all implementers [10]:

"The patent holder commits to a royalty-free license to all implementers for patent claims necessary to implement the referenced Internet-Drafts, on a reasonable and non-discriminatory basis, for standard-conformant implementations of the specifications. The patent holder reserves the right to suspend this commitment, on a reciprocal basis, as to any party that asserts patent claims against implementations of these specifications (defensive suspension). This update supersedes the licensing terms stated in the original disclosure, IPR ID #7559." [10]

Who uses it

Revision -09 (26 October 2026) added Appendix E (Implementation Status) in accordance with BCP 205 (RFC 7942: Improving Awareness of Running Code: The Implementation Status Section), documenting known implementations and architecture adoptions alongside public open-source repositories and packages on PyPI and GitHub [1][41]:

Who reads it

AAT records and chains are consumed by standalone offline verifiers, compliance-pack gates, interactive chain-truncation analyzers, downstream IETF audit profiles, and RFC 5424 Syslog SIEM pipelines:

Recent coverage

See also

References

  1. Raza Sharif (CyberSecAI Ltd). `draft-sharif-agent-audit-trail-09` — Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems' (IETF Internet-Draft, Intended status: Standards Track, 26 October 2026, expires 29 April 2027).: "This document specifies a standard logging format for autonomous AI agent systems. The Agent Audit Trail (AAT) defines a JSON-based record structure with mandatory fields for agent identity, the authorizing principal, action classification, outcome tracking, and trust level reporting. Records are linked via tamper-evident hash chaining using SHA-256 per RFC 8785, with optional ECDSA signatures for non-repudiation." "The format addresses requirements from the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems, whose application dates were staged into 2027-2028 by Regulation (EU) 2026/1744. It also maps informatively to SOC 2 Trust Services Criteria, ISO/IEC 42001, the draft ISO/IEC 24970 and prEN 18229-1 logging standards, and PCI DSS v4.0.1 logging requirements. The design is transport-agnostic and supports export to JSONL, Syslog (RFC 5424), and CSV while preserving chain integrity. Privacy is addressed through input/output hashing, content fingerprinting, and tombstone-based deletion compatible with GDPR Article 17." "The mappings in this section are INFORMATIVE. They indicate where AAT records can supply evidence relevant to an obligation; they are not a compliance assessment and do not assert that adopting AAT satisfies any regulation or standard. Several of the referenced instruments are drafts under active development, and their requirements may change." "Every record MUST name a principal, so that the record establishes not only what the agent did (agent_id) but on whose authority it did it." "Records produced under revision -06 and earlier predate this field. A verifier processing a mixed-revision archive SHOULD treat the absence of "principal" in such records as "principal not recorded" rather than as a validation failure." "When action_type is "decision" and outcome is "denied", the record MUST have record_phase set to "pre_execution". A denial that is only logged after execution provides no evidence that the denial was enforced." "Self-recording provides weaker evidentiary guarantees because the agent could, in principle, omit or alter records of its own actions without external detection." "For deployments at trust level L2 and above, audit records SHOULD be written by a component independent of the agent." "The following are consequential actions and MUST be assigned a "trust_level" of L2 or above by default: any "tool_call" or "decision" whose action_detail indicates a payment or fund movement, deletion of data, deployment to a production environment, transfer of authority ("delegation"), or egress of data to an external party. A conforming recorder MUST NOT assign a consequential action a trust level below this default UNLESS a "trust_assignment" object (Section 3.2) is present with "downgraded" set to true." "The platform of the recording component is appraised by a RATS Verifier [RFC9334] against an endorsed reference, and the resulting attestation is bound to the audit trail through the "platform_attestation" object (Section 3.2)." "prev_hash(N) = hex(SHA-256(JCS(record(N-1) with any "batch" object removed))) For the genesis record (N=0), prev_hash MUST be null." "The author thanks Parker Piehl for identifying the inconsistency between Sections 6.1 and 6.3 corrected in -09." "For a "sig_alg" of "ES256" (the default), sign using ECDSA P-256 per FIPS 186-5 [FIPS186-5] and encode as Base64url (RFC 4648 Section 5) using IEEE P1363 fixed-length r||s (64 bytes total: 32 r, 32 s)." "For a "sig_alg" of "ML-DSA-65", sign using ML-DSA-65 per FIPS 204 [FIPS204] over the same 32-byte hash and encode the raw signature as Base64url. ML-DSA-65 SHOULD be used where records must remain verifiable beyond the anticipated lifetime of classical signatures (e.g., legal evidence subject to long retention and "harvest-now, verify-later" threats)." "For a "sig_alg" of "Ed25519", sign the same 32-byte hash as the message using Ed25519 (pure EdDSA) per RFC 8032 [RFC8032] and encode the 64-byte signature as Base64url. Ed25519 is OPTIONAL. It allows implementations that already hold Ed25519 keys to produce conforming records; "ES256" remains the default." "This OPTIONAL mode lets a recording component anchor a batch of records under one Merkle root, yielding logarithmic-size inclusion proofs and a single external anchor per batch. It COMPLEMENTS and does not replace the hash-chain; "prev_hash" and its verification (Sections 6.1 and 6.3) remain in force." "SCITT [SCITT] provides a transparency service and signed receipts over statements; an AAT session hash or Merkle batch root (Section 6.4) MAY be registered with a SCITT transparency service as the external anchor used in Section 6.3, step 9." "In a signed chain, carries a NEW signature computed by the deleting authority over the tombstone record itself (Section 6.2), with the deleting authority's own "signer_kid". The original record's signature MUST NOT be copied into the tombstone: a signature retained from the deleted record does not cover the tombstone's content and would allow a forged tombstone to erase any signed record while still verifying." "A decision that is only recorded is "reconstructable", not "reproducible"." "A decision record MUST NOT set reproducibility_class to "reproducible" unless its attestation is closed: the weights, tokenizer, chat template, and engine build are digested (Section 13.3); the complete decoding configuration is recorded in inference_config; the numeric environment (hardware, batch_size, num_threads) is recorded in the environment object; and the input is sealed." "The WIMSE agent audit record work [WIMSE-AUDIT] defines a minimum field set and requires attestation by an observer the agent does not control. AAT instead defines graded recording independence (Section 5), permitting self-recording only at L0 and L1 and requiring an independent recorder at L2 and above, and adds pre-execution enforcement evidence (Section 4) and decision reproducibility (Section 13), which that work does not cover." "Description: reference library for producing and verifying Agent Audit Trail records, including offline chain verification against a public key. Language: Python. Distribution: PyPI package "aat-mcp". Coverage: record format (Section 3), hash chaining and chain verification (Section 6), ES256 signatures." "Description: an agent console that exports its decision ledger as Agent Audit Trail records with a bundled offline verifier, and packages the export into a reproducible compliance bundle that is not written if any chain fails verification. Language: Rust and TypeScript. Licence: AGPL-3.0. Coverage: export conforming to the -08 revision." "Description: an on-premises secrets manager whose accepted architecture decision record (ADR-118) maps an agent evidence ledger to this document and adopts pre-execution recording (Section 4), with the secret-holding component as the recorder. Status: design accepted; no implementation was available at the time of writing." — https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-09.txt
  2. IETF Datatracker. draft-sharif-agent-audit-trail-09 - Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems (document status and revision history `-00` through `-09`, updated 26 October 2026).: "draft-sharif-agent-audit-trail-09 - Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems" — https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/
  3. IETF Datatracker JSON Metadata. `draft-sharif-agent-audit-trail/doc.json` (`rev — 09'`, `iesg_state — I-D Exists'`, checked 29 October 2026).: ""rev": "09"" — https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/doc.json
  4. Raza Sharif (CyberSecAI Ltd). `draft-sharif-agent-audit-trail-00` — Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems' (initial IETF Internet-Draft, 29 March 2026).: "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems" — https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-00.txt
  5. Raza Sharif (CyberSecAI Ltd). `draft-sharif-agent-audit-trail-01` — Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems' (IETF Internet-Draft adding `record_phase` and Sections 4–5, 19 August 2026).: "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems" — https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-01.txt
  6. Raza Sharif (CyberSecAI Ltd). `draft-sharif-agent-audit-trail-03` — Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems' (IETF Internet-Draft adding Section 13.6 Attestation Closure, 5 September 2026).: "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems" — https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-03.txt
  7. Raza Sharif (CyberSecAI Ltd). `draft-sharif-agent-audit-trail-04` — Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems' (IETF Internet-Draft adding `ML-DSA-65`, `signer_kid`, Section 5.3, and Section 6.4 Merkle Batch Anchoring, 15 September 2026).: "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems" — https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-04.txt
  8. Raza Sharif (CyberSecAI Ltd). `draft-sharif-agent-audit-trail-07` — Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems' (IETF Internet-Draft adding mandatory `principal` object and Section 1.3, 11 October 2026).: "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems" — https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-07.txt
  9. Raza Sharif (CyberSecAI Ltd). `draft-sharif-agent-audit-trail-08` — Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems' (IETF Internet-Draft adding Section 5.4 Hardware-Attested Recording and `platform_attestation`, 13 October 2026).: "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems" — https://www.ietf.org/archive/id/draft-sharif-agent-audit-trail-08.txt
  10. IETF Datatracker IPR Disclosure #7609. IPR Details - Raza Al-Rehman Sharif's Statement about IPR related to draft-sharif-agent-audit-trail, draft-sharif-openid-agent-identity, and draft-sharif-aeba (submitted 19 September 2026 for UK Patent Application `GB2606543.3`, superseding `#7559` with a Royalty-Free RAND commitment).: "The patent holder commits to a royalty-free license to all implementers for patent claims necessary to implement the referenced Internet-Drafts, on a reasonable and non-discriminatory basis, for standard-conformant implementations of the specifications. The patent holder reserves the right to suspend this commitment, on a reciprocal basis, as to any party that asserts patent claims against implementations of these specifications (defensive suspension). This update supersedes the licensing terms stated in the original disclosure, IPR ID #7559." — https://datatracker.ietf.org/ipr/7609/
  11. PyPI JSON API. `aat-mcp` package metadata (`v0.1.0`, uploaded 29 September 2026 by `cybersecai`, checked 29 October 2026).: "Conformant AAT (draft-sharif-agent-audit-trail-06) audit-trail recorder + MCP middleware: signed, hash-chained, tamper-evident, offline-verifiable evidence for AI agent tool calls." — https://pypi.org/pypi/aat-mcp/json
  12. GitHub REST API. `razashariff/aat-mcp` repository metadata (created 29 September 2026, checked 29 October 2026).: ""full_name": "razashariff/aat-mcp"" — https://api.github.com/repos/razashariff/aat-mcp
  13. Raza Sharif (`razashariff/aat-mcp`). `README.md` (`aat-mcp` signed, tamper-evident audit trail for MCP tool calls, checked 29 October 2026).: "Signed, tamper-evident audit trail for MCP tool calls, conformant to draft-sharif-agent-audit-trail-06. Every agent tool invocation becomes a signed, hash-chained record that an independent party can verify offline, without trusting the producer." — https://raw.githubusercontent.com/razashariff/aat-mcp/main/README.md
  14. PyPI JSON API. `aat-verify` package metadata (`v0.1.0`, uploaded 15 September 2026 by `cybersecai`, checked 29 October 2026).: "Standalone reference verifier for the Agent Audit Trail Internet-Draft (draft-sharif-agent-audit-trail)." — https://pypi.org/pypi/aat-verify/json
  15. CyberSecAI Ltd. Agent Audit Trail (AAT) — AI Agent Audit Log & Evidence Standard (official standard portal and AgentPass Evidence documentation, checked 29 October 2026).: "The Agent Audit Trail (AAT) is an open, implementable standard for recording every consequential action an autonomous agent takes — signed, hash-chained, recorded before execution, and verifiable by parties who do not trust the operator." "The reference implementation of the Agent Audit Trail. Every AI agent decision signed (ECDSA P-256), hash-chained, written to tamper-evident WORM storage, and exportable straight into your SIEM (Splunk, QRadar, ArcSight). Anyone can verify the chain offline with just the public key — no vendor lock, no token. Built by CyberSecAI to the draft-sharif-agent-audit-trail specification." — https://aat-standard.org/
  16. GitHub REST API. `cyl-castillo/agent-console` repository metadata (created 21 May 2026, AGPL-3.0, checked 29 October 2026).: ""description": "Minimalist AI-native console for directing agents inside a repository. Tauri + React + Claude CLI."" — https://api.github.com/repos/cyl-castillo/agent-console
  17. Cyl Castillo (`cyl-castillo/agent-console`). `README.md` (Agent Console / Testigo ledger and IETF Agent Audit Trail export documentation, checked 29 October 2026).: "Every session witnessed into a hash-chained evidence ledger (Testigo); export signed proof packets anyone verifies in a browser, or the same ledger as an IETF Agent Audit Trail (JSONL, SHA-256 over RFC 8785) that a third party verifies offline with the dependency-free aat-verify.mjs written alongside." — https://raw.githubusercontent.com/cyl-castillo/agent-console/main/README.md
  18. Agent Console (`agent-console.dev`). `llms.txt` (indexing `TESTIGO.md` and `draft-sharif-agent-audit-trail-08` export, checked 29 October 2026).: "ledger design, proof packets, the IETF audit-trail export (draft-sharif-agent-audit-trail-08) and the monorepo plan." — https://agent-console.dev/llms.txt
  19. Cyl Castillo (`cyl-castillo/agent-console`). `TESTIGO.md` (Testigo decision ledger design, `src-tauri/src/services/aat_export.rs`, and `draft-sharif-agent-audit-trail-08` compliance pack specification, updated 25 October 2026).: "Export IETF (D3, 2026-10-14): el mismo ledger exportado como Agent Audit Trail (draft-sharif-agent-audit-trail-08): un .jsonl por sesión, cada registro con los campos obligatorios del borrador, prev_hash = SHA-256 sobre JCS (RFC 8785) del registro anterior, génesis lifecycle/session_start, cierre lifecycle/session_end con session_hash, sequence_number sin huecos" — https://raw.githubusercontent.com/cyl-castillo/agent-console/main/TESTIGO.md
  20. Agent Console (`agent-console.dev`). Landing page ('One zip for the auditor', checked 29 October 2026).: "One zip for the auditor — the audit trail verified, the policy in force, verification by week, a manifest; same ledger, same bytes" — https://agent-console.dev/
  21. PyPI JSON API. `ujex-compliance-callback` package metadata (`v0.1.1`, uploaded 18 June 2026 by `axysar`, checked 29 October 2026).: "Drop-in tamper-evident audit callbacks for LangChain, LangGraph, CrewAI, AutoGen, PydanticAI. Streams events into the Ujex hash-chained audit ledger (IETF draft-sharif-agent-audit-trail-00)." — https://pypi.org/pypi/ujex-compliance-callback/json
  22. GitHub REST API. `Mindburn-Labs/helm-ai-kernel` repository metadata (created 15 February 2026, Apache-2.0, checked 29 October 2026).: ""description": "Fail-closed execution firewall for AI agents: quarantine MCP tools, proxy OpenAI-compatible requests, emit signed receipts, and verify EvidencePacks offline."" — https://api.github.com/repos/Mindburn-Labs/helm-ai-kernel
  23. GitHub REST API. `keyorixhq/keyorix` repository metadata (checked 29 October 2026).: ""full_name": "keyorixhq/keyorix"" — https://api.github.com/repos/keyorixhq/keyorix
  24. GitHub REST API. `kbipul/last-record` repository metadata (created 18 September 2026, MIT License, checked 29 October 2026).: ""description": "Check an agent tool-call log against the IETF Agent Audit Trail draft, and see what its SHA-256 chain cannot prove."" — https://api.github.com/repos/kbipul/last-record
  25. Bipul (`kbipul/last-record`). `README.md` ('Last Record: Cut the end off a hash-chained audit log and it still verifies', checked 29 October 2026).: "This tool takes an agent tool-call log, checks each record against the draft's mandatory fields, recomputes the hash chain, and then answers the question the green badge doesn't: what does a verified chain actually establish?" — https://raw.githubusercontent.com/kbipul/last-record/main/README.md
  26. Parker Piehl (Independent). `draft-piehl-agent-rule-provenance-00` — Rule Provenance for Autonomous AI Agent Audit Records' (IETF Internet-Draft, Intended status: Experimental, 11 October 2026).: "This document describes an experimental profile of the Agent Audit Trail format for AI agents. The profile records the rules an agent operates under: each version of each rule, who set and approved it, and which rules were in force when a decision was made. It keeps a decision separate from any later approval or override, binds it to the exact request, and requires that records of consequential actions go to a recorder independent of the operator and be anchored in a public log. It also sets out what these records can and cannot prove." — https://www.ietf.org/archive/id/draft-piehl-agent-rule-provenance-00.txt
  27. S. Thaha and S. Shamsudeen. `draft-thaha-scitt-agent-execution-evidence-00` — Agent Execution Evidence: A SCITT Profile for Verifiable Records of AI Agent Runs' (IETF Internet-Draft, October 2026).: "Agent Passport System [I-D.pidlisnyi-aps] and Agent Audit Trail [I-D.sharif-agent-audit-trail]: A broad authority-and-evidence framework and a logging format respectively. This profile could serve as the evidence layer of the former and commits to entries of the latter by digest; no dependency is created." — https://www.ietf.org/archive/id/draft-thaha-scitt-agent-execution-evidence-00.txt
  28. Raza Sharif (CyberSecAI Ltd). `draft-sharif-mcps-secure-mcp-01` — MCPS: Cryptographic Security Layer for the Model Context Protocol' (IETF Internet-Draft, 21 August 2026).: "This document specifies MCPS (MCP Secure), a cryptographic security layer for the Model Context Protocol (MCP). MCPS adds agent identity verification, per-message signing, tool definition integrity, and replay protection to MCP communications" — https://www.ietf.org/archive/id/draft-sharif-mcps-secure-mcp-01.txt
  29. S. Gilda et al. `draft-gilda-wimse-agent-audit-record-02` — An Audit Record Format for AI Agent Authorization Decisions' (IETF Internet-Draft, October 2026).: "This document defines a record format for AI agent authorization decisions. The format is one in-toto predicate type, signed inside a DSSE envelope. It carries the seven minimum audit fields that the WIMSE AI Identity Management System framework requires, and two properties that make those fields checkable: a canonicalization contract, and both the authorization decision and the observed effect with a derived three-valued agreement between them." — https://www.ietf.org/archive/id/draft-gilda-wimse-agent-audit-record-02.txt
  30. C. Munoz et al. `draft-munoz-wimse-authorization-evidence-01` — Signed Authorization-Evidence Records for WIMSE-Authorized AI Agent Actions' (IETF Internet-Draft, 2026).: "This document specifies a companion profile to the AI Agent Authentication and Authorization draft [I-D.klrc-aiagent-auth], defining a signed authorization-evidence record produced by WIMSE- authorized AI agent actions." — https://www.ietf.org/archive/id/draft-munoz-wimse-authorization-evidence-01.txt
  31. M. Sokolov. `draft-sokolov-rats-aep-composition-00` — Composing Application-Layer Action Evidence with Remote Attestation Procedures' (IETF Internet-Draft, October 2026).: "This document sketches a composition pattern in which an application- layer "action evidence package" (AEP) — a signed, append-only record of an action taken by an automated (for example, AI-agent) system, the authority under which it was taken, and its outcome — is treated as Evidence in the sense of the RATS Architecture (RFC 9334) and bound to platform Evidence produced by a hardware root of trust." — https://www.ietf.org/archive/id/draft-sokolov-rats-aep-composition-00.txt
  32. P. Emirdag and D. Feichtinger (Veridic Inc.). `draft-emirdag-scitt-ai-agent-execution-01` — AI Agent Execution Profile of SCITT' (IETF Internet-Draft, 12 October 2026).: "This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions." — https://www.ietf.org/archive/id/draft-emirdag-scitt-ai-agent-execution-01.txt
  33. Steven Mih (Action State Group, Inc.). `draft-mih-scitt-agent-action-capsule-00` — An Agent Action Capsule Profile for SCITT' (IETF Internet-Draft, 13 June 2026).: "This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule." — https://www.ietf.org/archive/id/draft-mih-scitt-agent-action-capsule-00.txt
  34. Steven Mih (IETF SCITT Working Group Mail Archive). [SCITT] Re: New individual submission: draft-mih-scitt-agent-action-capsule-00 (3 July 2026).: "There are also adjacent record formats (e.g. draft-sharif-agent-audit-trail, draft-bates-atp, draft-aylward-aiga), which -00 should cite as live adjacent work, not position." — https://mailarchive.ietf.org/arch/msg/scitt/kvOh8rO618FGAlIWvg7uEg_kyN8/
  35. Raza Sharif (IETF AUDIT Mailing List Archive). [Audit] Individual draft + running code: draft-sharif-agent-audit-trail-08 (agent audit record format) (22 October 2026).: "Adding a datapoint for the record-format discussion ahead of the BoF. draft-sharif-agent-audit-trail-08 (Agent Audit Trail, "AAT") is an individual Internet-Draft, first posted 29 March 2026, defining a JSON record format for actions taken by autonomous agents:" "Fit with the proposed charter: deliverable 3 (reuse and profile an existing data model for records). AAT is offered as one candidate input for that work. It does not define identity, delegation or authorization; it records the outcome of them and expects those from WIMSE / OAuth work." — https://mailarchive.ietf.org/arch/msg/audit/7jINjQq00C5Wu3_Z3qe-E0ikIe4/
  36. A. Rundgren, B. Jordan, and S. Erdtman. RFC 8785: JSON Canonicalization Scheme (JCS) (IETF Informational RFC, June 2020).: "Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable." — https://www.rfc-editor.org/rfc/rfc8785.html
  37. B. Laurie, E. Messeri, and R. Stradling. RFC 9162: Certificate Transparency Version 2.0 (IETF Experimental RFC, December 2021).: "This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves." — https://www.rfc-editor.org/rfc/rfc9162.html
  38. R. Gerhards. `RFC 5424: The Syslog Protocol` (IETF Standards Track RFC, March 2009).: "This document describes the syslog protocol, which is used to convey event notification messages." — https://www.rfc-editor.org/rfc/rfc5424.html
  39. H. Birkholz et al. RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains (IETF SCITT Architecture Standards Track RFC, 2026).: "This document defines such an architecture for single-issuer signed statement transparency." — https://www.rfc-editor.org/rfc/rfc9943.html
  40. H. Birkholz et al. RFC 9334: Remote ATtestation procedureS (RATS) Architecture (IETF Standards Track RFC, January 2023).: "This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims." — https://www.rfc-editor.org/rfc/rfc9334.html
  41. Y. Sheffer and A. Farrel. `RFC 7942: Improving Awareness of Running Code: The Implementation Status Section` (IETF Best Current Practice BCP 205, July 2016).: "This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section." — https://www.rfc-editor.org/rfc/rfc7942.html
  42. Eric Lamanna (Automatic.co). What to Demand in an Agent Vendor's SOC 2 and Audit Trail | Automatic.co (29 September 2026).: "An IETF draft defines the Agent Audit Trail (AAT), a JSON-based record structure with mandatory fields for agent identity, action classification, outcome tracking, and trust level reporting, using tamper-evident hash chaining via SHA-256. Whether or not the vendor implements AAT specifically, the field set is a reasonable floor." — https://automatic.co/blog/agent-vendor-soc2-audit-trail-requirements

JSON · Markdown · OKF v0.2