An AI audit trail is a chronological record of an AI system’s actions and decisions, maintained so that its behavior can be reviewed and attributed later. Its evidentiary value depends on the coverage, integrity and provenance of the recorded events.
Audit trails are old technology. Banks, hospitals and operating systems have kept them for decades, so that someone can later reconstruct who did what, when and with what authority. Agents make the old question harder in a specific way: the actor is software that chooses its own steps, often acting on a person’s behalf, across several systems at once. When something goes wrong, the trail is what the investigation starts from. Whether it can answer the questions asked of it depends less on how much it records than on three properties most discussions skip.
What changes when the actor is an agent
A conventional audit log records what a known user or service did inside one system. An agent’s activity breaks three of those assumptions.
- The actor is delegated. An agent usually acts for someone: a user who started it, a team that deployed it, another agent that called it. “The service account did it” is no longer an answer.
- The run spans systems. One task can touch a repository, a ticketing system and a cloud account. Each keeps its own log, and none shows the run.
- Attempts and effects come apart. An agent can attempt an action that is denied, fails, or succeeds partially. Knowing that an action was attempted is different from knowing what changed.
What an agent audit trail records
For each action, a useful trail answers a short set of questions:
- Who acted, and for whom. The agent’s identity, and the person or system it acted on behalf of.
- What it was asked to do. The task or declared intent the action belongs to.
- What it attempted. The tool or operation, its target and its arguments, summarized where sensitive.
- What decided. Which control evaluated the action, under which policy, and with what result: allowed, denied, approved by a named person, or flagged.
- What happened. The result reported, and, where it can be confirmed, the effect on the target system.
- When, and recorded by whom. A timestamp, and the component that wrote the event.
The last question is the one most often missing, and it leads to the three properties that decide what a trail is worth.
Coverage, integrity, provenance
Coverage: what the trail can see. A trail records only the actions that pass through the points where it is captured. An agent that calls an API directly, a shell command that bypasses a gateway, or an agent nobody registered leaves no event. The difficulty is that a gap in coverage is invisible from inside the trail. The absence of an event proves only that nothing was recorded on the paths being watched.
Integrity: whether it can be changed. A trail that can be edited after the fact cannot settle a dispute. Write-once storage prevents changes where it is enforced. A hash chain, in which each event includes a hash of the one before, makes altering or removing an earlier event detectable. Signing events with a key the agent cannot reach, or periodically recording the latest hash somewhere independent, makes it hard to rewrite the chain wholesale or quietly drop its most recent events. These measures make a trail tamper-evident rather than tamper-proof: they show that something was changed, not what was there before.
Provenance: who wrote each record. A record written by the agent about itself is a claim. A record written by an independent component that observed the action is evidence of a different kind. Provenance also covers the chain of delegation: whether an approval in the trail names a person whose identity was verified, or only a name that was typed in.
What a trail can prove
| The trail shows | It establishes | It does not establish |
|---|---|---|
| An action was attempted | The attempt reached a point where it was recorded | That the action took effect |
| The action was allowed | A control evaluated it and did not deny it | That a person reviewed it |
| ”Approved by” a named person | An approval claim was recorded | That the named person approved, unless identity was verified |
| No event for an action | Nothing was recorded on the instrumented paths | That the action did not happen |
Reading a trail correctly means reading it with these limits in mind. Most disputes about agents turn on exactly these four distinctions.
Regulation
The EU AI Act makes logging a requirement for the high-risk AI systems it defines, not for every agent. Article 12 requires that high-risk systems technically allow for the automatic recording of events over their lifetime. Article 19 requires providers to keep those automatically generated logs, to the extent the logs are under their control, for a period appropriate to the system’s intended purpose and of at least six months, unless applicable Union or national law, in particular data-protection law, provides otherwise. Article 26 places the same retention duty on deployers for the logs under their control. Standards for what those logs must contain are still being written, so the law sets the obligation more clearly than the format.
An example
The following is illustrative.
A customer disputes a refund. The support agent’s trail shows that, while working on the customer’s ticket, it attempted a refund of the full order amount; that the refund tool’s policy allowed refunds up to that amount; and that the payment system returned success. The trail also records that the agent was acting for a named support representative.
That settles less than it seems. The trail shows the attempt, the policy decision and the reported result. It does not show that the representative reviewed the refund, because no approval was recorded. And when the finance team finds a second refund to the same customer, there is no event for it at all. That refund was issued by hand in the payment dashboard, a path the agent’s trail never covered. The investigation needs the payment system’s own log to close the gap.
How Sentience Governor relates
Sentience Governor records each attempted action at the execution boundary of the integrations it instruments, together with the session’s declared intent and scope and the findings from evaluating the action, in the Sentience Agent Execution Record. That record is one source of governance evidence for an audit trail. It covers only the integrations it is installed in, it records attempts rather than confirmed effects, and the open-source release keeps it as a local record that is not tamper-evident.
Often confused with
Audit log. An audit log usually records events inside one system, such as a database or an identity provider. An AI audit trail follows the agent’s activity across systems and ties each action to a task, a decision and a principal.
Observability traces. Traces are built for debugging and performance: they are often sampled, short-lived and mutable. An audit trail is built to be complete for what it covers, retained, and trustworthy later.
Governance evidence. Governance evidence is the record of how actions related to their declared purpose and policy. It is part of what an agent audit trail contains, not the whole of it.
Where the concept stops
An AI audit trail establishes what was recorded, by whom and when. It does not establish what it never saw, it does not prove that an attempted action took effect, and it does not make a claim true by recording it. Its value is bounded by its coverage, its integrity and its provenance, and an honest trail says which of those it can vouch for.