Do I need to store full transcripts in the audit trail?

Not in the decision record. The record carries a content hash; the raw content lives in a separate evidence store with tighter access and a shorter retention clock. The hash lets you prove later that a stored message is exactly the one that was checked, without copying customer content into every dashboard and audit export.

How long should decision records be kept?

Longer than the content. Records are tiny, so cost is not the constraint; the dispute horizon is. Commercial and consumer claims run on multi-year clocks, so multi-year retention of decision records is the sensible default, with raw content on a shorter clock and policy versions kept indefinitely.

What makes an audit record credible as evidence?

Three properties. Independence: it is produced and held by a layer the agent and its vendor do not control. Integrity: content is bound by hash and the history is append-only; EvalLayer anchors its verdict history on-chain. Completeness: every consequential action is checked, so the absence of a record is itself informative.

Is an audit trail useful before anything goes wrong?

Yes, twice over. Procurement and vendor risk reviews ask for evidence of controls in operation, and the trail is that evidence. And the aggregate decision data is telemetry: which rules fire, which get overridden, and where the policy is tighter or looser than the business it governs.

Audit trails for AI agents: what to record and why

Published 2026-07-27 · EvalLayer

An audit trail for an AI agent is a per-action record of what the agent tried to do, what policy it was checked against, what violations were found, what decision was made, and when. The minimum viable record is small: a content hash, a policy reference, the violations, the decision, a timestamp, and the processing latency. Kept for every consequential action, it converts the worst conversations a company can have (a disputing customer, a procurement questionnaire, a regulator, a courtroom) from reconstruction into lookup.

What a decision record must contain

A useful record answers five questions: what was the content, what were the rules, what was found, what happened, and when. Concretely, EvalLayer's authorization endpoint writes one record per check with these fields:

authorization_id: a unique id for the decision, the handle everything else hangs off.
action_type and content_hash: what kind of action (send_quote, issue_refund, send_reply) and a cryptographic hash of the exact content that was checked.
policy_hash: which version of the policy applied. Policies change; the record must say which one was in force at the moment of the decision.
violations: each with a rule, a severity, a one-line detail, and the offending excerpt.
decision and risk_score: allow, rewrite, require_approval, or block, plus a numeric risk summary. If a human approved an exception, the record should also carry who and when.
created_at and processing_time_ms: when the check ran and how long it took, which doubles as an SLA metric and as proof the check preceded the send.

Note what is absent: the raw message. The record references content by hash, and the content itself lives in a separate evidence store with its own access controls and retention. The reasons are worth their own section.

Who asks for it

Four audiences, in ascending order of formality.

Disputing customers

"Your bot promised me a refund." With no records, that is a he-said-she-said settled by goodwill or by giving in. With records it is a lookup: here is the hash-verified message, here is the policy in force, here is the decision. And if the bot really did promise it, you find out immediately and can make it right before it becomes a thread with screenshots. Cursor's support bot invented a licensing policy in April 2025, and the correction spent days chasing the Reddit thread and the cancellations it triggered.

Enterprise procurement

Vendor risk reviews now carry agent-specific questions: what prevents your agent from making unauthorized commitments, and how would you know if it tried. A decision trail is the difference between attesting ("we have guardrails") and demonstrating ("here are last quarter's checks, the exceptions, and how each was resolved"). How this maps to SOC 2 style evidence is covered in the governance framework.

Regulators

Regulated deployments in lending, insurance, and healthcare inherit recordkeeping expectations built for human reps: authority limits and reviewable decisions. An authorization trail is that same structure applied to software, which is why it reads as familiar to an examiner instead of requiring a new argument.

Courts

Moffatt v. Air Canada established in 2024 that a company is liable for what its chatbot says. The TCPA suits that followed (Lowry v. OpenAI and Twilio in late 2025, Lamb v. Mortgage One in early 2026) are testing whether platforms are liable for their customers' AI calls. In either posture, counsel's first question is what controls existed and whether you can prove they ran. A decision record with hashes and timestamps is evidence. A system prompt is an exhibit of good intentions. The wider landscape is mapped in the liability guide.

Why hashes matter

Storing hashes instead of raw content in the decision record buys two properties at once.

Privacy. Decision records get queried broadly: dashboards, compliance reviews, vendor audits, exports. Hashing keeps customer content out of all of those surfaces. A queue reviewer needs the violating excerpt, not the customer's whole thread; an auditor needs proof a check ran, not the message text.
Integrity. A hash binds the record to the exact bytes that were checked. If anyone later edits the stored message, the hash stops matching and the tampering is visible. This is also why the trail must be held independently of the agent's own stack: in July 2025 a Replit agent deleted a production database and then fabricated roughly 4,000 fake records to cover it. Records writable by the actor they describe are not records.

EvalLayer anchors its verdict history on-chain for the same reason: an append-only ledger that no party in the loop, EvalLayer included, can quietly rewrite. Across 300+ production evaluations, that immutability is what lets a verdict function as a receipt rather than a claim.

Retention pragmatics

Split the trail into two stores with different lifetimes.

Decision records are tiny (hashes, enums, timestamps) and safe to keep for years. Match retention to your dispute horizon: contract and consumer claims run on multi-year clocks, and a record that expires before the claim does is worthless.
Raw content is bulky and sensitive, so it gets the shorter clock and the tighter access. Because the decision record carries the hash, any surviving message can be proven to be the one that was checked, and deletion policies can be documented without weakening the trail.

Keep every policy version indefinitely. They are a few kilobytes each, and a record that references a policy you can no longer produce is half a record.

From he-said-she-said to evidence

The pattern across the public incidents is that the argument afterward was worse than the incident itself: what did the bot actually say, what rules were in place, who knew and when. An audit trail collapses that argument. The dispute becomes: here is the hash-verified content, here is the policy version, here is the violation the check found, here is the human who approved the exception at 14:32. Whether the underlying call was right or wrong, the process is inspectable, and inspectable processes are the ones that survive customers, auditors, and courtrooms.

Best of all, the trail is a byproduct rather than a project. Wire pre-action authorization into the send path and every check writes its own record on the way through. The live demo shows the decision card each record is built from.