AgentAuditTrail Join the working group

The open standard for AI agent evidence

The evidence-grade record of what an AI agent actually did.

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.

Built on draft-sharif-agent-audit-trail — currently at revision 05 and actively updated in the open on the IETF Datatracker, with a public, timestamped revision history dating from 29 March 2026. Independently implemented and cited across industry, standards and academic work.

Supported in law & evidence

Developed with global leaders in law, evidence and comparative justice, so the record stands up where it matters — in front of auditors, regulators and courts.

Built by practitioners

Created by cybersecurity leaders with over three decades of hands-on experience implementing and securing enterprise and government systems.

Open & revisable

Specified as an IETF Internet-Draft series — every revision public, dated and open for anyone to read, implement or challenge.

( Leadership )

Where security engineering meets the law of evidence.

The AAT programme is led across two disciplines by two leads — the technical evidence standard and the legal-procedural methodology that makes it count in front of regulators and courts. No other agent-evidence effort is led from both sides of that line.

Technical standard

Raza Sharif

Fellow of the British Computer Society (FBCS) · CISSP · CSSLP
Founder & CEO, CyberSecAI Ltd, London · Author of draft-sharif-agent-audit-trail

Named Cybersecurity & AI Architecture Executive of the Year 2026, London · C-Suite Insider

Author of the AAT technical standard and fourteen IETF Internet-Drafts on autonomous-AI security. Two decades leading security architecture for UK Government and major financial institutions; author of Breach 20/20: Data Breach Prevention — AI Edition and of The Reproducibility Criterion for Machine-Generated Evidence.

Legal-evidence methodology
RUO - Research Unit One

Prof. Daniela Mainenti

President & Scientific Director, RUO — Research Unit One
Professor of Comparative Criminal Procedure

Leads LawTrace, RUO's independent legal-procedural evidence methodology — defining the requirements for reconstructability, contestability, human accountability and legal scrutiny of AI-generated and AI-assisted decisions, so that technical traceability becomes legally intelligible evidence.

Two sovereign layers, standing side by side: LawTrace defines what must be capable of being reconstructed, verified and contested in law; AAT defines the technical requirements that make the underlying records tamper-evident and independently verifiable.

“AI accountability begins where technical traceability becomes legally intelligible evidence. LawTrace exists to build that bridge.”

— Prof. Daniela Mainenti, President & Scientific Director, RUO
182normative requirements
103 MUST · 49 SHOULD · 30 MAY
12mandatory fields in
every audit record
7registered action types
tool call → lifecycle
6regulatory mappings
EU AI Act → PCI DSS
6public revisions
-00 → -05, in the open

( The problem )

A log the operator can edit is the operator's word — not evidence.

Autonomous agents spend money, change records, control infrastructure and act on people's lives. When one of those actions is disputed — by a customer, an auditor, a regulator or a court — the question is never “do you have logs?” It is “why should anyone believe them?”

AAT answers that question structurally. Records are written before the action executes, so a crash or a cover-up cannot erase intent. Every record hashes the one before it, so history cannot be rewritten without detection. Every record is signed, so authorship cannot be denied. And the whole chain verifies offline, with public keys alone — no trust in the operator required.

( What the standard requires )

Twelve requirement families. One verifiable chain.

The full normative text lives in the draft — this is the shape of it: what a conforming implementation must actually do.

AAT / R1

Audit record format

Twelve mandatory fields on every record — from record_id and agent_id to trust_level, prev_hash and record_phase — with strict field constraints, so records are machine-verifiable and portable across implementations.

AAT / R2

Pre-execution recording

Intent is recorded before the action runs, with a completion record after. A crashed, killed or rogue agent cannot un-happen its own intent. High-risk systems carry stricter requirements.

AAT / R3

Recording independence

Self-recording and independent recording are distinguished, and the integrity of trust-level assignment is protected — the recorder's honesty is a stated, graded property, never an assumption.

AAT / R4

Tamper-evident chaining

SHA-256 hash chain over canonicalised records, a signature envelope on every record, a defined chain-verification procedure, and optional Merkle batch anchoring for external notarisation.

AAT / R5

Action taxonomy

Seven registered action types — tool_call, tool_response, decision, delegation, escalation, error and lifecycle — so delegation chains and escalations are first-class, auditable events.

AAT / R6

Session integrity

A genesis record opens every session, records form one ordered chain, and sessions close explicitly — no silent gaps, no orphaned actions.

AAT / R7

Retention & erasure

Retention obligations split by risk class, with tombstone records that honour the GDPR right to erasure while keeping the chain cryptographically intact — privacy law and tamper-evidence, reconciled.

AAT / R8

Export & interoperability

JSONL as the primary interchange format, with RFC 5424 syslog and CSV export defined — evidence that moves between tools, SIEMs and reviewers without translation loss.

AAT / R9

Regulatory mapping

Clause-level mappings to the EU AI Act (with a compliance-checklist appendix), SOC 2, ISO/IEC 42001, ISO/IEC 24970, prEN 18229-1 and PCI DSS v4 — the record format that regulators' logging obligations can point at.

AAT / R10

Privacy by design

Data-minimisation requirements govern what enters a record in the first place; sensitive payloads are referenced by hash rather than re-exposed in the trail.

AAT / R11

Decision reproducibility

A dedicated normative section distinguishing record integrity from decision reproducibility — the conditions, record fields, verification procedure and decision-margin analysis under which an AI decision can be independently re-derived, with honest scope limits where it cannot.

AAT / R12

Security & registries

A worked threat model — tampering, injection, timing attacks, chain breaks, replay — plus IANA registries for action types, outcomes and signature algorithms, so the standard extends without forking.

( Why AAT )

Designed as evidence, not telemetry.

Plenty of schemes can log what an agent did. AAT is built for the day the record is challenged.

/ 01

Recorded before the act

Most logging is post-hoc — the agent reports on itself after the fact. AAT records intent pre-execution, so the trail survives crashes, kills and cover-ups.

/ 02

Verifiable by outsiders

The chain verifies offline against public keys alone. An auditor, counterparty or court re-checks every record without trusting the operator — the property that separates evidence from assertion.

/ 03

Built for admissibility

Clause-level EU AI Act mapping, a compliance checklist, GDPR-reconciled erasure, and an evidential presentation lane developed with global leaders in law and evidence.

/ 04

Reproducibility, graded honestly

AAT is the only agent-evidence standard with a normative decision-reproducibility section — including where reproducibility is achievable, and where it honestly is not.

/ 05

Open process, dated priority

Developed as an IETF Internet-Draft series in public since 29 March 2026 — every revision timestamped on the Datatracker, open for anyone to read, implement and challenge.

/ 06

Extensible without forking

IANA-style registries for action types, outcomes and algorithms mean new agent behaviours get registered, not bolted on — implementations stay interoperable as the field moves.

( The research )

Grounded in published, checkable science.

The reproducibility section of this standard is not an aspiration — it is the productisation of a published working paper: The Reproducibility Criterion for Machine-Generated Evidence: Sufficient Conditions and Certification Limits for Independently Verifiable AI Decisions (Sharif, 2026).

The paper proves the necessary and sufficient conditions under which an AI decision can be independently re-derived as evidence: deterministic decoding, attested model identity, sealed inputs, and an attested execution environment — together, the complete computational closure of the inference. It matters because it draws the honest line the industry avoids: it demonstrates empirically that partial attestation is forgeable by a single unrecorded parameter — so a record that seals less than the full closure can be quietly defeated — and it defines the certification limits separating decisions that are genuinely reproducible from those that are merely recorded. That distinction is exactly what a court applying reliability scrutiny, or a regulator applying the EU AI Act's record-keeping obligations, will eventually ask about. AAT's decision-reproducibility requirements (R11) implement the paper's criterion; the paper is open access, so your experts can take the foundations apart before trusting the standard built on them.

Trust the maths. Reproducibility here is not a promise — it is a machine-checkable criterion. A certified decision is one anyone can re-run and get the same answer, not one you are asked to believe.

The full deployment of this standard — WORM evidence ledger, attested inference, reproducibility certificates and independent timestamps, stood up inside your own AWS, GCP or Azure tenancy — is delivered as the AgentPass AI Evidence Stack.

( Adoption & citation )

Independently implemented. Independently cited.

The strongest test of a standard is other people building on it without being asked.

Mindburn Labsimplemented

Independent implementation of the AAT record format — schema, JSON canonicalisation and hash-chain — in their helm-ai-kernel, with tests.

view the implementation →
Agent Flight RecorderarXiv:2609.01931 · IEEE BCCA 2026cited

Peer-reviewed academic work on AI agent forensics engaging directly with the draft — citation and critique in the published literature.

view the paper →
Bordaformat-level

Format-level adoption of the AAT record structure in independent tooling.

view →
IETF community draftsreferenced

Independent Internet-Drafts and open-source projects referencing the AAT series in their own specifications and implementations.

view →
Industry working groupsin discussion

The draft is under active discussion in industry alliance working groups on agent accountability and audit standards.

view →

Claim discipline: draft-sharif-agent-audit-trail is a series of individual IETF Internet-Drafts — a public, dated, revisable specification. It is not an adopted IETF standard, and we do not describe it as one. The implementations and citations above are independent third-party work, linked so you can verify each claim yourself.

( Law & evidence )

Supported by global leaders in law and evidence.

A record format is only half the problem; the other half is whether the record stands up when lawyers argue about it. The AAT programme is developed with global leaders in law, evidence and comparative justice — including the RUO (Research Unit One) legal-evidence collaboration — mapping the technical guarantees onto what courts and regulators actually demand: authenticity, integrity, reliability, chain of custody and contestability.

EU AI Act Art. 12 · record-keeping eIDAS qualified timestamps US FRE 901 / 902 / 707 scrutiny UK PACE & procedure rules chain of custody · forensic process

( Contribute )

Help sharpen the standard the field is already building on.

AAT improves the way it started: in the open, revision by revision, tested by the people who implement it. Three ways in:

/ 01

Review & challenge

Read the current draft and send technical comments — field semantics, threat model, verification procedure. Adversarial reviews are the most valuable kind.

/ 02

Implement

Build the record format into your agent stack, SIEM or gateway. Independent implementations drive the revisions — tell us what broke and what was ambiguous.

/ 03

Join the working group

Take part in the standing group refining the requirement families, the registries and the legal-evidence mapping across jurisdictions.