An AI audit trail is a record of how AI is actually used inside an institution: who used which AI tool or agent, what was sent and what came back, when it happened, and whether policy held. A trustworthy one is a tamper-evident audit log, built so that any alteration after capture is visible, rather than a text file that anyone with access could quietly edit. As AI tools and agents take on regulated work, this record has become the substance of AI accountability: the difference between telling an auditor what you believe happened and showing what did.
The question arrives sooner than most institutions expect. A regulator asks what data staff sent to an outside provider. A court asks what an agent did on a specific afternoon. An internal review asks whether a policy that exists on paper was enforced in practice. An institution with no record cannot answer. An institution with ordinary logs can offer an assertion. An institution with a verifiable record can offer evidence.
The four questions an AI audit trail must answer
Strip away the terminology and an audit trail exists to answer four questions about any AI interaction, months or years after it happened:
- Who. Which person or agent, on which device, used which AI tool. Attribution that stops at a service account or a shared credential does not answer this.
- What. The substance of the interaction: what was sent to the provider and what came back, including anything policy redacted or blocked before it left.
- When. A trustworthy timestamp, ordered against every other captured interaction, so a timeline can be reconstructed and defended.
- Whether policy held. What the applicable policy was at that moment, what it decided (ALLOW, REDACT, or BLOCK), and that the decision was enforced rather than merely written down.
Most environments can partially answer some of these from scattered sources: application logs, provider dashboards, browser history. None of those were designed as evidence, and under scrutiny they behave like what they are: operational byproducts, editable, incomplete, and often held by someone else.
What separates a trustworthy record from a text file of logs
Any system can write logs. Four properties turn a log into a record a reviewer can rely on, and each one closes a specific way records fail under scrutiny.
Signed at capture, on the originating device
Each chain entry is signed the moment it is captured, on the device where the interaction happened, with a signing key that never leaves that device. This is what non-repudiation means in practice: the entry could only have been produced by that device, for that user, at that time. A server can verify the signature but cannot forge it, and neither can an administrator after the fact. NIST SP 800-53 rev 5 treats this as its own control, AU-10, inside the audit and accountability family that regulated frameworks increasingly map to.
An append-only hash chain
Every entry carries a cryptographic hash of the entry before it. Change one record, insert one, or delete one, and every hash after it stops matching. The alteration is not prevented; it is made visible, which is exactly what tamper-evident means. Because verification is arithmetic rather than trust, it can be re-run at any time, on any copy of the chain, entry by entry.
Keys the institution holds
Custody decides who the record actually belongs to. In a trustworthy design, audit content is encrypted under keys the institution holds, and the server that stores the chain stores only ciphertext. The maker of the audit system cannot read the interactions, and neither can anyone who compromises its servers. When a reviewer asks for the record, the institution produces it, and can show it was never readable by anyone else.
Per-user attribution
A record that shows an interaction happened is observability. A record that shows who did it is accountability. Per-user, per-device attribution, established cryptographically at capture, is what lets an institution answer the who question years later. It also keeps oversight proportionate: aggregate numbers for leadership, per-user evidence only when there is cause to look.
| Property | A text file of logs | A tamper-evident audit log |
|---|---|---|
| Alteration | Editable by anyone with access, without a trace | Any change breaks the chain, visibly |
| Attribution | Often a service account or an IP address | Signed per user and per device at capture |
| Custody | Held by whoever operates the logging system | Held by the institution, under its own keys |
| Standing in review | An assertion to take on trust | Evidence a reviewer can verify independently |
What the cryptography proves, and what it does not
Precision matters here, because this is where marketing tends to outrun mathematics. Signatures and hash chains make captured records tamper-evident: any alteration after the moment of capture is detectable. They prove nothing about interactions that were never captured. A chain that verifies perfectly is silent about the prompt that went through a tool nothing was recording.
Completeness, in other words, is a property of capture, not of cryptography, and no math applied afterward can restore a record that was never made. That is why where capture happens is the design decision that determines what the record can ever show. Capture inside one sanctioned tool records that tool and nothing else. Capture at the device where the traffic originates, before a request leaves for the provider, covers whatever tools and agents are actually in use on that device, sanctioned or not. A system can also be designed to fail closed, so that when it cannot record AI traffic it stops that traffic rather than letting it pass unrecorded.
Cryptography makes captured records tamper-evident. It does not make the record complete. Completeness comes from where capture happens, which is why capture belongs on the device where the traffic originates.
The honest vocabulary follows from this. A trustworthy system speaks of every captured interaction, and treats coverage, meaning which devices and which tools are under capture, as a separate question with a measurable answer. Any product claiming a complete record of AI use is making a promise cryptography cannot keep.
AI record keeping, mapped to the framework
How long the record must survive is not one number; it is set by the framework you answer to. Under CJIS Security Policy v6.0, in force since December 2024 and mapped to NIST SP 800-53 rev 5, audit obligations live in the AU control family, and agencies retain audit records for at least one year, then keep them for as long as they remain needed for administrative, legal, or audit purposes. HIPAA sets a longer horizon: 45 CFR 164.316(b)(2)(i) requires documentation of required actions and assessments to be retained for six years from creation or from when it was last in effect, whichever is later. State law is adding its own horizons: Colorado’s SB 26-189 carries a three-year record-keeping duty for covered AI decisions when it takes effect on January 1, 2027.
Two design consequences follow. Retention has to be configurable per framework rather than set as one global default, because most institutions answer to more than one. And the record has to remain verifiable across the whole period: a chain you can check in year six is worth more than a backup you can only hope was never touched. Our compliance mappings show how these obligations line up control by control.
The record Verillian produces
Verillian produces exactly the record this post describes. A sentinel on each device intercepts AI traffic where it originates, decides per policy before anything leaves for the provider, and signs every captured interaction into an append-only, hash-chained record. Signing keys never leave the device. Audit content is encrypted under keys the institution holds, using X25519 and AES-256-GCM, so the admin server stores only ciphertext and Verillian cannot read your interactions. Retention aligns to the governing framework, at least one year under CJIS Security Policy v6.0 or six years for HIPAA documentation, and the chain can be verified at any time, per device and fleet-wide.
Verillian is aligned to CJIS Security Policy v6.0 and built for HIPAA-regulated environments. Aligned, not certified: CJIS compliance is validated through state-agency audit, and HIPAA offers no product certification at all. Governance is a meeting; enforcement is what Verillian does. If your institution needs to answer the four questions above, start with how the record works and the security architecture behind it.