AI agent audit trail

What an agent audit trail has to contain.

Not a product tour — a specification. Eight things the record must carry to survive the person who will eventually read it, whoever you buy from, including us.

  • No card to start
  • Nothing is blocked until you say so
  • Your proof stays yours if you leave
The specification

Eight fields, or it is just a log.

Each one exists because an investigation ends on it. Miss one, and that is the question you cannot answer under oath.

The actor
Which agent acted — and whether a human was in the loop, which is a separate fact from which human.
The action
What was done, in a vocabulary a tool you did not write can still read.
On whose behalf
The customer or person it acted for. Without this there is no per-customer answer, complaint, or erasure.
The approver
The named person who signed off, taken from an authenticated session — never from the request. The field every investigation ends on.
The reason
Why — mandatory on adverse decisions, because a verdict without a reason already fails disclosure rules in force.
The fingerprints
A cryptographic digest of what went in and came out, so integrity is provable without the trail holding your data.
The rule
Which policy evaluated the action, its version, and whether it was enforcing or only watching.
The order
Each entry carries the fingerprint of the one before it — so “nothing was inserted, removed or reordered” is checkable, not asserted.
The test

Hand it to a stranger.

A trail only the vendor can check is a claim. The whole exercise is what happens when someone who does not trust you runs the check.

anyone, anywhere — with nothing but Node
node -e "const b=require('./evidence.json');require('fs').writeFileSync('verify.mjs',b.verifier)"
node verify.mjs ./evidence.json
✓ VERIFIED — chain intact, checkpoints countersigned

That is our export being verified offline: no account, no API call, nothing from us. The verifier recomputes every fingerprint and names the exact sequence where any edit began.

What this does not prove
Verification proves the records were not altered after they were sealed. It cannot prove the trail is complete — an action that never reached it is not in it, and no signature can say otherwise. Coverage is a property of your deployment, and an honest vendor never conflates the two.
Asked precisely

Four questions that define the artefact.

Including who can actually demand yours — where the first answer, in practice, is a customer rather than a regulator.

Where this fits in the category →
01Is an application log an audit trail?
No, for three reasons that survive any amount of log volume: it can be edited without trace, it expires before the obligation does, and it names a service account where an investigation needs a person. A log records that something ran; a trail proves what happened.
02Do agent frameworks provide one?
They provide traces — excellent for debugging, built for engineers, mutable, and short-lived. Some emit OpenTelemetry spans, which is genuinely useful: a trail can be built from the same spans. The framework gives you the signal; it does not give you the evidence.
03Who can demand ours?
A regulator under the EU AI Act's logging duty, an examiner under SEC 17a-4 or FINRA supervision, a court in discovery, and — most often in practice — an enterprise customer's security review before they sign. The last one arrives years before the others.
04What makes a trail verifiable rather than trusted?
The check runs without the vendor. Ours exports one self-contained file — events, checkpoints, public keys, and the verifier itself — and the auditor runs it offline. If verification requires our servers, our account, or our goodwill, the trail is a claim with extra steps.
Start

Keep it before anyone asks.

A trail only counts if it already existed when the question arrived. Two lines in one agent, free while you evaluate.

Start freeSee it live
  • No card to start
  • Nothing is blocked until you say so
  • Your proof stays yours if you leave