An AI agent audit trail is the durable record of what an autonomous agent did: which identity acted, what it changed, what the work cost, who approved it, and when each of those happened. It is written by the system as the work runs, and it is readable afterwards by someone who was not there.
The last clause is the whole requirement. A record you have to be present to interpret is a log. A record that answers an outsider’s question months later is an audit trail.
The distinction
A log is not an audit trail.
Most systems reaching for an audit trail already have logs, and reasonably assume the hard part is done. It is not. The two artifacts are built for different readers, and almost every property that makes a log useful makes it inadmissible.
Written for the engineer
What a log is
Emitted at whatever points a developer thought would help them debug. Unstructured, frequently sampled under load, rotated on a retention window nobody chose deliberately, and free to change shape in the next release. It is a diagnostic byproduct, and it is excellent at being one.
Written for the reviewer
What an audit trail is
Emitted because the action happened, not because someone instrumented it. Every entry carries an actor, a subject, a time, and an outcome, in a shape a query can rely on. It is not enabled after an incident, because the entries you need were the ones that would have been missing.
The failure mode is specific: an incident review that opens by turning on verbose logging captures everything from that moment forward, and the window that mattered is already behind it.
The fields
What an entry has to carry.
Autonomous work adds two fields a conventional audit trail never carried: the identity of a non-human actor, and what the action cost. Everything else is the familiar list, made harder by the fact that the actor does not remember and cannot be asked.
Actor
Which identity acted
For a non-human actor this is the hard one. If every agent shares one service account, the trail records the account and loses the actor, and separation of duties becomes unprovable after the fact. Each seat needs an identity of its own.
Action
What it did, and to what
A verb and a subject, both from a known set rather than free text. Free text is searchable by a human and useless to a query.
State
The before and the after
For anything that mutates configuration, policy, or a roster, a verb is not enough. An auditor asked to review a permission change needs the permission as it was and as it became.
Cost
What the work spent
The field a conventional audit trail has never needed and an agent audit trail cannot omit. Model, tokens in each direction, and money, attached to the run that spent it.
Approval
Who cleared it
The gate, the position in the chain, the role that decided, and whether the decision was to approve or reject. A rejection is evidence too, and a trail that only records approvals is a trail that has been curated.
Time
When each of those happened
Stored in UTC, on every row, including the failures. A record that drops failed and cancelled work is describing a system that never goes wrong.
In practice
What SpeyAI writes, and where.
SpeyAI runs inside your infrastructure and stores its state in a Postgres database you own. The record below is written as the work happens, into tables you can query directly.
A page about the record should show one. Every action lands against the role that took it: who acted, what changed, what it cost, and who approved.
The record · newest first
One shipped change, walked back to the brief a human ratified.
Run
Every model call opens a row
The seat that made the call, the task it was working, the model, the tokens in and out, the cached tokens, how long it took, the provider’s own request identifier, the final status, and the estimated cost carried at micro-dollar precision. Failed, timed-out and circuit-broken runs are rows like any other.
Action
Every operator action lands against its task
The identity that acted, the task, the verb from a constrained set, and the payload. Merge, block, comment, route, cancel, acknowledge, reset, reopen: the database refuses a verb outside the list, so the trail cannot quietly grow a category nobody can query for.
Diff
State-changing operations carry a before and an after
An operational action that mutates configuration, a roster, or the kill switch records the affected fields as they were and as they became. Actions that carry no snapshot leave those columns empty rather than fabricate one, so an auditor can tell the difference between no change and no capture.
Signature
Approvals record the decision, including the refusals
Which gate, which position in the approval chain, the role that decided, approve or reject, the note, and the time. A rejected change leaves the same evidence as an approved one.
Scope
Every tenant query is scoped, and the database backs it
Scoping is explicit at the application layer and row-level security enforces it underneath, using one canonical policy pattern applied across the tenant-scoped tables. The console reads the record through a paginated read-only window over the same rows.
The policy pattern is printed in full on the security page, alongside the rest of the isolation story.
What we will not tell you is that the trail is tamper-proof. It is as protected as the database you put it in. Immutability, retention, and backup are set by your own database administrator, because it is your own database, and a vendor claiming otherwise about a deployment it does not operate is claiming something it cannot see.
The test
One question decides whether it works.
Show me every change this system made last quarter, who approved each one, and what it cost. Nobody asks it in a demo. Everybody asks it in an audit, in a board review, and on the worst morning of the year.
A log answers it with a search and a shrug. A trail with the fields above answers it with a query, and the answer includes the work that failed, the work that was rejected, and the money spent on both.
What is the difference between an AI agent audit trail and a log?
A log is written for the engineer who will debug the system later: unstructured, sampled, and retained by whatever policy the log shipper happens to have. An audit trail is written for someone who was not there and has to reconstruct what happened: every entry names an actor, a subject, a time, and an outcome, and no entry is optional. A log answers what the code did. An audit trail answers who did what to what, and who allowed it.
What has to be in an AI agent audit trail?
The identity that acted, and for a non-human actor that means the agent itself rather than the service account it borrowed. The action and its subject. The state before and after, where the action changed state. The cost, because a model call spends money. The approval: who cleared it, at which gate, and whether they approved or rejected. And a time on every one of those.
Where does SpeyAI store the audit trail?
In your own Postgres. SpeyAI runs inside your infrastructure and takes no custody of your operational data, so the rows are written to a database you own, on your retention policy, queryable with ordinary SQL by your own people. The console reads the same rows through a paginated read-only window; it is a view over your data, not a copy held somewhere else.
Is the audit trail tamper-proof?
It is as protected as the database you put it in, and we would rather say that than imply a control we do not ship. SpeyAI writes the record as the work happens and never as an opt-in debug mode, and the rows carry row-level security with every tenant query scoped explicitly at the application layer. Immutability, retention, and backup are your database administrator’s to set, because it is your database.
