Agent audit trail: what it has to record
Stefan-Iulian Tesoi · · 6 min read
Three things: attribution on every change, the commit that caused a status to move, and the criteria the work was accepted against. The first two are what most systems already record. Without the third, the trail says that something happened without saying whether it should have.
That gap is what makes an agent audit trail different from ordinary logging. Volume is not the problem — agents produce more records than people ever did. NIST's guide to log management made the same point about ordinary systems two decades ago: producing records was never the hard part, keeping them usable was. The records answer "what" and leave "on what basis" to memory.
What does an agent audit trail have to contain?
Three fields, and each one answers a question the other two cannot.
| The record | The question it answers | Without it |
|---|---|---|
| Who acted | Which person or credential did this | Every change belongs to "the system" |
| What caused the change | Which commit or call moved the status | Status is an assertion with no cause |
| What it was judged against | Which acceptance criteria applied | You know it was accepted, not whether it should have been |
The third row is the one that gets skipped, and the reason is ordinary: acceptance criteria live on the item, the audit log lives somewhere else, and nobody thinks of them as the same record. Then the criteria get edited — legitimately, because requirements move — and the trail now shows an item accepted against text that no longer exists.
An audit trail that records only the transition is a receipt. One that records what the transition was judged against is evidence. The difference only matters on the day somebody disputes the decision, which is the day it is too late to add.
Why does a shared credential destroy attribution?
Because it replaces a person with a project, and the substitution cannot be undone afterwards.
A per-person sign-in binds a session to a human being, so a milestone the agent creates is owned by that person and a blocker it reports says whose agent hit it. A project API key identifies a project instead: work lands on the project owner regardless of who was driving. Both are legitimate — a key is the right answer for CI, cron and scripts, where there is no person to bind to.
What makes it irreversible is that the information was never captured. You cannot reconstruct who was at the keyboard from a log that recorded the project. AI accountability logging fails here quietly and permanently, and the failure is invisible until the first time someone asks who changed this ticket and the honest answer is "the project owner, and probably not them".
Two practical consequences worth planning for:
- A key rotation breaks every configured client at once, immediately and by design, so a team standardised on one key discovers on rotation day how many clients that is.
- A leaver's sign-in keeps working until access is revoked, which means a still-running agent can attribute work to someone who no longer works there. The MCP page shows when a credential was last used, which is the cheapest way to find the connections nobody owns.
Recording the reason, not only the change
A trail that records decisions but not their reasons is one you can read and still not understand. The fix is unglamorous: capture the reason at the moment of the decision, in the same record, because it will not be reconstructable later.
Laimonade does two specific things here. Reversing a completion requires a stated reason, recorded on the item — the argument for undoing a decision is not something a log can infer afterwards, so it is asked for at the point where somebody still knows it. And when a commit rather than a person moves an item, that is recorded as such, naming the commit, its author and how confidently it was matched, so a status that looks wrong can be traced to what caused it instead of guessed at.
That second one is more useful than it sounds. Two items behind this cluster of posts were closed last week; neither carried a commit-inference record, which said plainly that a person had moved them rather than an automated match. It is a small thing to be able to establish rather than assume, and it is precisely the class of question traceability coding agents raise more often than human teams did, because the volume makes "I remember" stop working.
What do you do when the trail and the repository disagree?
Trust the repository and fix the trail, then find out which of them was wrong to begin with. The order matters, because the instinct is to correct the board and move on, which destroys the evidence of how far it had drifted.
The divergence itself — how a ticket ends up done while the code is not, and how to detect it without reading every diff — is the subject of why done and the repository disagree. What belongs here is narrower: the disagreement is information about your trail, not only about your board.
A trail that disagreed with the repository and nobody noticed for a month is telling you something about its retention, its attribution or its detection that a corrected status will hide. Record the correction as a correction, with a reason and a date. The privacy policy states what is stored and for how long, which is the other half of what a compliance owner needs before relying on any of it. Whether the connection is worth trusting at all is the subject of coding agent security.
Frequently asked questions
Is a commit history an audit trail?
Half of one, and the better half. Git records what changed, when and by whom, and it is tamper-evident in a way most application logs are not. What it does not record is intent: which item a change was meant to satisfy, which criteria it was judged against, and who accepted it. A commit history plus an item history is an audit trail; either alone is a fragment.
How long should agent activity be retained?
Long enough to answer the questions you will actually be asked, which for most teams is the current financial year plus the last one. Regulated work sets its own floor and it is usually longer. The cost is rarely storage; it is that a trail nobody has queried in two years is a trail nobody has noticed is broken, so retention and a periodic read belong together.
Can an agent be made to explain a decision after the fact?
It can produce an explanation, which is not the same thing. An account generated later is reconstruction from the same context that produced the work, not a record of what happened, and it will be fluent whether or not it is right. Capture the reason at the time — on the item, in the commit, in the review note — or accept that it is gone.
Does any of this apply to a team of three?
Yes, and it is cheaper to start with than to retrofit. The reason is not compliance, it is that attribution and criteria cannot be added to records that were written without them. A team of three that used one shared key for a year has a year of work attributed to one account, and no amount of later diligence recovers it.