Disclosure: BlueBear sells a platform that records agent authorisation evidence, so we have a commercial interest. The timing argument below is independent of tooling, and the gap calculation works against whatever you run today.
Evidence is the one control you cannot improve retroactively
Most findings can be addressed before an assessment. Weak access control gets tightened, missing policy gets written, an unowned process gets an owner. The assessor sees the improved state.
Evidence does not work that way. An obligation looks back over a period, and asks what happened during it. If nothing was recording, that period is undocumented, and no amount of work now changes it. This is the one place where a decision made months ago is not recoverable by effort.
Why an agent makes this sharper than ordinary software
Conventional software does what it was written to do, so the code is a reasonable account of what happened. An agent chooses its path at runtime. The code tells you what it could have done. Only the record tells you what it did.
That shifts the burden entirely onto the record. It also means the interesting question is rarely whether an action occurred - the logs usually show that - but whether it was authorised, on whose behalf, and against which system. Those facts exist at the moment of the call and are not observable afterwards.
The four facts that have to be captured at the time
Everything else can be derived. These cannot:
- The acting identity, and who it acted for. If the agent used a shared application credential, this is gone, and attribution becomes inference from timing.
- The system and the operation. Which target, which action, with what scope.
- The authorisation decision and its basis. Not that it happened - that it was permitted, and why. This is the field most often missing, because logging frameworks record events rather than decisions.
- The outcome. Including failure, since a refused action is evidence the control worked.
Deliberately absent: the payload. Storing request bodies makes the record a second copy of the data without improving what it proves.
Working out what you have already lost
This takes an afternoon and is worth doing before someone asks:
Find the date recording actually started. Not when the policy was approved - when the first record with an authorisation decision was written. These are usually months apart.
Compare it to the start of your current assessment period. The difference is the gap. If recording started inside the window, part of the period is unevidenced.
Then check what the covered portion actually contains. A period with logs but no authorisation decisions is only partly covered. You can show actions occurred; you cannot show they were permitted.
The output is a number: how many months of your lookback are genuinely evidenced. Most teams have never calculated it, and it is almost always smaller than assumed.
What to do about a gap you cannot close
Say so, early, in writing, with the date recording began and what changed. A known and dated gap with a remediation date is a manageable finding. The same gap discovered by an assessor is a different conversation, because the question stops being about evidence and starts being about whether you knew.
The asymmetry worth acting on
Turning on recording costs a few days. Not having done it costs a period you cannot recover. Those are not comparable magnitudes, which is why this is worth doing before the obligation is confirmed rather than after - the clock on your next lookback window is already running.
What an assessor actually asks for
The request is rarely "show me your audit logs". It is narrower and harder: pick a specific action, from a specific date, and show who authorised it.
That framing is what separates a record that survives from one that does not. A log of everything that happened is not the same as evidence for one thing that happened, and the difference only becomes visible under a pointed question. Teams with terabytes of telemetry routinely cannot answer it, because the volume was never the constraint - the authorisation decision was, and it was never written down.
The follow-up is usually harder still: how do you know this record was not altered? You do not need cryptographic proof for most obligations, but you do need to be able to describe who can write to the store, who can delete from it, and whether either action would itself be recorded. If the answer is that engineers with production access can do both silently, the record is an account rather than evidence.
Three things that look like evidence and are not
Application logs. They show that a call happened. They rarely show that it was permitted, on whose behalf, or against which system, because logging frameworks record events rather than decisions.
Traces. Sampled by design, expired on an operational schedule, and optimised for latency debugging. A sampled record cannot support a claim about a specific action, because the specific action may not be in the sample.
The agent transcript. Appealing because it reads like a narrative, but it is the model's account of its own behaviour rather than the system's record of what it was allowed to do. It is useful context and it is not authority.
The order to fix things in
If you find a gap, resist the urge to improve everything. Start recording the authorisation decision today, because the clock on your next lookback window is already running and every day without it is a day you cannot evidence later.
Backfilling the surrounding metadata, tightening retention, and improving the query path can all happen afterwards without losing anything. The only irreversible loss is the period that runs unrecorded while the better system is being designed.
The one sentence worth being able to say
All of this reduces to whether you can finish a sentence: on this date, this identity, acting for this person, was permitted to do this against this system, and here is the record written at the time.
If you can say that for an action from six months ago, the rest is detail. If you cannot, no amount of dashboarding, retention policy or tooling procurement changes the answer, because the missing part is not stored anywhere and never was.
Audit Trail Requirements for Every Consequential Agent Action
A compliant-looking log is not enough. A reviewer should be able to reconstruct identity, delegated authority, policy, proposal, approval, execution, side effect, and accepted outcome without inferring missing joins.
| Evidence group | Minimum fields |
|---|---|
| Context | Tenant, workspace, human/service subject, agent and workflow version, session. |
| Authorization | Requested action/resource, effective policy, decision, reason, approval and expiry. |
| Execution | Model route, MCP connection, tool/action, credential reference, attempt and result. |
| Side effect | Idempotency key, downstream receipt, before/after reference and reconciliation state. |
| Outcome | Terminal state, accepted result, rejection, retry, review effort and cost. |
Protect integrity with append-only corrections, stable time sources, ingestion-gap monitoring, exportable schemas, content-level privacy controls, and retention by data class and jurisdiction.
Questions people actually search for
- can you create ai audit evidence retrospectively
No. You can reconstruct a narrative from logs and timestamps, and that is an argument rather than evidence. An audit record has to be written at the moment of the action, because it captures the authorisation decision and the context that existed then. Once the action is past, the facts that made it authorised are no longer observable. Any period that ran without recording stays undocumented permanently.
- how far back do ai compliance obligations look
It varies, and the number matters more than most teams realise. Assessment periods commonly cover the preceding several months to a year of operation, meaning the records you need were generated long before anyone asked. If instrumentation went live after the window opened, part of the period is unevidenced no matter how good the current controls are.
- what has to be recorded at the time of an agent action
The acting identity and who it acted for, the system and operation, the authorisation decision and its basis, and the outcome. Those four are not derivable afterwards. Payload content is deliberately excluded - it makes the record a copy of the data without improving what it proves.
- how do you work out if your ai audit evidence has gaps
Take the date your recording actually started, not the date the policy was written, and compare it to the start of your current assessment period. The difference is your gap. Then check whether the records in the covered portion contain the authorisation decision or only the action, because a log of what happened without why it was permitted does not close the gap either.