--- title: "Audit trail for AI agent decisions" description: "An AI audit trail records what an agent knew when it acted: facts, sources, dates. What to log, and how to reconstruct a past knowledge state." canonical: https://past.dev/guides/ai-audit-trail last-updated: 2026-09-02 --- # Audit trail for AI agent decisions Source: https://past.dev/guides/ai-audit-trail An AI audit trail is the record of what an agent knew when it acted: the facts it held, the sources behind them, and their dates. Logging requests alone does not produce one, because the answer to "why did it do that" lives in the knowledge state at that moment. An audit trail therefore requires event time, provenance, and supersession, so any past decision can be explained from the facts that were current when it was made. ## What an audit trail must record Most systems already log the surface of an agent's activity: the request, the response, the tool calls. An audit asks a different question: what information produced this action? Answering it requires four records per fact the agent relied on. - **The fact itself**, as stored at the time, with the value that was current then. - **Its sources.** The record that supports the fact: the email, the transcript, the ticket. See [data provenance](/guides/data-provenance). - **Its dates.** When the fact became true (event time) and when the system learned it (ingestion time). See [event time vs ingestion time](/guides/event-time-vs-ingestion-time). - **Its history.** Whether the fact was later superseded, and by what. See [facts that change over time](/guides/facts-that-change-over-time). A recall response that returns ranked evidence with dates, sources and a status value is itself an auditable record. Storing it alongside the agent's action captures the knowledge state at the moment of the decision. ## Why overwriting memory destroys the trail A memory layer that overwrites a fact on update keeps only the newest value. Six weeks later, the question "what did the agent believe on March 12" has no answer: the March value is gone. Append-only storage fails differently. Both values exist, but nothing marks which one was current on a given date, so reconstruction becomes guesswork. Supersession keeps the trail intact. When a fact changes, the previous fact's validity window closes and the new fact records what it replaced. Both remain queryable with their dates. This is the property auditors use, and it must be built into ingestion: retrieval cannot reconstruct a value that storage destroyed. The [fact supersession](/glossary/fact-supersession) and [validity window](/glossary/validity-window) glossary entries define the mechanics. ## Reconstructing a past knowledge state The reconstruction question has a precise form: as of a given date, which facts were current, and what evidence supported them? With validity windows this is a filter rather than an investigation: select the facts whose windows covered that date. See [point-in-time recall](/glossary/point-in-time-recall). Reconstruction has uses beyond formal audit. Debugging a wrong answer starts with the same query: what did the agent know when it answered? A support escalation, an incident review and a compliance request all reduce to the same point-in-time question. ## Designing the trail 1. Store every recall response the agent acted on: the evidence, its dates and sources, and the status value (`Supported`, `Conflicted`, `NoKnownSupport`, or `UnknownBecauseDegraded`). 2. Record event time and ingestion time separately for every stored fact. 3. Keep superseded facts with closed validity windows instead of deleting them on update. 4. Keep source records addressable by a stable identifier, so evidence links stay resolvable. 5. Record deletions: when a source is erased, the erasure event belongs in the operational record even though the content is gone. 6. Test reconstruction quarterly: pick a past date, reconstruct the knowledge state, and check it against a decision made that day. Retention rules for the trail itself belong in the same policy as everything else the system stores. [Data retention policies for AI memory](/guides/ai-data-retention) covers the mechanics, and [EU AI Act record-keeping](/guides/eu-ai-act-record-keeping) covers the regulation that makes trail retention a legal duty for some deployments. ## How past.dev supports audit past.dev stores each fact with event time taken from the source's own timestamp, a validity window, a supersession link to the fact it replaced, and the sources that support it. [Recall](/docs/memory-api/quickstart) returns ranked, dated evidence with one of the four status values, so the response an agent acted on can be stored as its audit record. Recall evaluation on changing facts is documented on the [benchmarks](/benchmarks) page. ## Frequently asked questions ### What is the difference between logging and an audit trail? A log records that something happened: a request arrived, a response was sent. An audit trail can additionally explain the action, which requires the knowledge state behind it: the facts that were current, their sources, and their dates. ### Can you audit an AI agent's decision after the fact? Yes, if the memory layer kept history. The requirement is that facts carry validity windows and provenance, so the set of facts current on the decision date can be reconstructed and each one traced to its source. ### Does an audit trail conflict with the right to be forgotten? They can coexist. Erasure removes a person's data and what only it supported; the operational record keeps the fact that an erasure happened, without the erased content. The retention policy states how long each record class is kept. ## Related - [Data provenance for AI agents](https://past.dev/guides/data-provenance) - [How to handle facts that change over time](https://past.dev/guides/facts-that-change-over-time) - [EU AI Act record-keeping](https://past.dev/guides/eu-ai-act-record-keeping) - [The right to be forgotten in agent memory](https://past.dev/guides/gdpr-memory-deletion) - [How we evaluate recall](https://past.dev/benchmarks/methodology)