AI agent audit trail: what to record, field by field

An AI agent audit trail is the record of what an agent tried to do and what happened as a result. For each action it captures who or what asked, what change was proposed, which rules were checked, who approved or refused it, and the outcome. The records are linked in order, so that if anyone edits or removes one later, the break is detectable.

It differs from an application log in purpose. An application log helps engineers debug; it is verbose, rotated and often edited by the people it describes. An audit trail is evidence: it is written for a reader who was not there, such as an internal auditor, a statutory auditor, a regulator or a court, and it has to stand up on its own.

Most teams start by logging the agent's tool calls: the function name, the arguments and the response. That shows what the agent did, but not why it was allowed to. If an agent posted a ₹6 lakh journal entry, the tool-call log tells you the entry was posted. It does not tell you whether a rule should have held it, whether anybody approved it, or which version of the policy was in force that day.

The missing piece is the policy decision. A useful trail records, for every proposed action, the rules evaluated, the result of each, the threshold that applied and the approval, if any. Without it, an auditor can confirm that changes happened but cannot test whether the controls around them operated, and testing controls is the auditor's job.

Whatever system you use, each record should be able to answer the questions below. The names are illustrative; the content is what matters.

Where the trail lives

Keep the trail out of reach of the thing it records. The agent, and the people who operate it, should be able to append records but not edit or delete them, and access to the trail should itself be logged. ICAI's implementation guide on the MCA audit trail makes the same point for accounting software: access to the audit trail and its back-ups should be restricted, and changes to its configuration authorised and logged. Store the trail in the jurisdiction its law requires; for Indian books of account, that means records accessible in India at all times.

Keep the set fixed once you publish it. If fields change every quarter, every verifier and every auditor's test script has to change with them.

A trail that only contains allowed actions describes what happened, but not what the controls prevented. Refusals are the evidence that a control operates: the payment held because the counterparty was new, the journal stopped because the period was closed, the change blocked because no approver was available.

Refusals also tell you where agents are being pointed at work they should not do. A cluster of refusals at the same rule is either a misconfigured agent or a rule that needs revisiting, and both are worth knowing. Record them in the same chain, with the same fields, and never charge for them or hide them in a separate log.

Vendors use these words loosely. They make different claims, and only one of them is easy to test.

Write-once storage and retention locks are useful, and you should use them where you can. But for evidence, the claim that matters is detection: if the records were changed, can someone outside your team tell? That is a property you can demonstrate, which is why careful vendors claim tamper-evidence rather than tamper-proofing. We go deeper in what tamper-evident means at L1.

A hash chain is the simplest detection mechanism. Each record includes a cryptographic digest, such as SHA-256, of the record before it. Change one byte of an earlier record and its digest changes, so the next record's link no longer matches, and nor does any link after it. Certificate Transparency logs, described in RFC 6962, use a related structure, a Merkle tree, to make public logs auditable at scale.

A chain has limits. Whoever controls the storage could rewrite the whole chain from the altered record onwards, recomputing every digest. Two additions close that gap. Signatures: each record, or each batch, is signed with a key the writer does not share, so a rewritten chain would not carry valid signatures. Outside anchors: digests are periodically timestamped by an independent party, so a rewrite would contradict an anchor that someone else holds. With both, an auditor can check the trail offline, without trusting the system that wrote it.

Retention periods come from the law that applies to the records, not from the logging tool. In India, books of account and their audit trail must be kept for eight years under section 128(5) of the Companies Act, 2013. Under the EU AI Act, providers of high-risk systems keep automatically generated logs for at least six months (Article 19) and deployers keep the logs under their control for at least six months (Article 26(6)), unless other law requires longer.

Personal data creates a tension: India's Digital Personal Data Protection Act, 2023 and the EU's GDPR both give people rights to erasure, while an append-only chain cannot be edited. The usual answer is to keep personal data out of the chained record itself: store a reference or a salted hash in the record, keep the personal data in a separate store that can be erased, and rely on the legal exception for data that must be retained to comply with another law. Our paper on DPDP and append-only logs covers this in detail.

An audit trail that can only be read inside the vendor's dashboard asks the auditor to trust the vendor. A better design lets the auditor take an export and test it independently. A typical test plan looks like this:

• Obtain the full export for the period, including refused and held actions, with the published field definitions.
• Recompute every record's digest and confirm each link to the previous record. Any mismatch is an exception.
• Where records are signed, verify each signature against the published public key, and check outside timestamps against the anchor.
• Sample actions and trace them to the system of record: every committed change should appear there, and nothing should appear there without a record.
• Sample held actions and confirm the approver was named, independent of the requester and acted within the time limit.
• Re-run a sample of decisions against the rules version recorded, and confirm the same outcome.

The ISO/IEC 42001 control on event logging (Annex A, A.6.2.8) and the logging duties in Article 12 of the EU AI Act both assume that logs can be reviewed by someone other than the operator. For a field-by-field reading, see our paper on evidence for auditors.

An agent at a fictional manufacturer, Kolam Components*, prepares the month-end accrual for an unbilled freight invoice. The rules say accruals above ₹2,00,000 need the finance controller. Here is what the record should show.

Three gaps appear often when teams first review trails like this: the approver's identity is a shared mailbox rather than a person; the rules version is missing, so nobody can say which threshold applied that day; and the entry number in the books is not recorded, so tracing a record to the ledger takes guesswork. Each is a one-line fix in the record, and each saves hours in an audit.

Notice what an auditor can do with this: confirm the rule existed in that version, that the threshold triggered correctly, that the approver was independent, and that the entry in the books matches the intent. Notice too what is absent: no customer names or personal data, only references.

elan1 writes a 16-field proof record for every action an agent proposes, allowed or refused. The field set is fixed and published in the proof record specification, with the method used to compute each SHA-256 digest, so anyone can recompute a record and check the chain. Refused actions are recorded in the same chain and metered at 0.4 of a governed action.

At L1 Guarded, records are hash-chained and tamper-evident: changes are detectable, not impossible. From L2 Attested, each record is also signed with the residency domain's key and anchored with an outside timestamp, giving signed records for auditors and a free offline verifier. You can verify a proof record yourself, without asking us.