Disclosure: BlueBear builds a platform that produces this kind of evidence, so we have a commercial interest. The specification below is written to be handed to any vendor, including ours, and the last section is explicit about the difference between a system having a field and a system populating it — because we have that gap ourselves and it is the right thing to test for.
The short answer: seven links, and three of them cannot be back-filled
A trail survives review when a person who was not present can reconstruct one action end to end. That requires seven links, each written at a specific moment. Three of them — identity, the policy decision, and the business outcome — have no other source, so if they are not captured as the run happens they do not exist. Those three are where a specification should start.
| Link | Written when | Recoverable later? |
|---|---|---|
| 1. Identity | At request admission | No — an invoice knows a key, not a person or a customer |
| 2. Policy decision | At evaluation, before the step | No — exists for a moment and nothing downstream keeps it |
| 3. Plan | When the agent forms it | Partly, from model call history, unreliably |
| 4. Approval | When the human decides | Partly, from a ticketing system, without the context shown |
| 5. Execution | At the boundary, as it happens | Mostly, from logs, expensively, successes better than failures |
| 6. Artefact | When it is produced | Mostly, if the target system retains versions |
| 7. Outcome | When the business judges it | No — never exists in infrastructure at all |
Link 1 — Identity
Fields: run identifier; timestamp; the human or system that initiated the request; the agent acting; the tenant or workspace boundary; a reference to the credential used, never the credential itself.
The requirement that matters: the boundary must be established from the credential presented at admission, never from a value in the request payload. A request that can nominate its own tenant is a request that can nominate someone else's. This is the single most important sentence in the whole specification and it is worth writing verbatim into an RFP.
The run identifier deserves particular attention because it is cheap and disproportionately valuable. One user action becomes many model and tool calls; without a shared identifier tying them together, reconstruction means correlating timestamps across systems. Attaching one is a day of work and it converts the hardest link into the easiest.
Link 2 — Policy
Fields: which policy was evaluated, identified by name and version; the inputs it was evaluated against; the decision; the reason.
The requirement that matters: the reason, not just the decision. A recorded "denied" with no reason is nearly as unhelpful as no record — the reason is what turns an incident into a fix, and what lets a reviewer distinguish a control working as designed from a control misfiring.
Where it must be evaluated: at the boundary that will execute the step. A constraint stated in a system prompt produces no record because nothing evaluated anything; it is a request to the agent, not a control over it. This is covered properly in how to make AI actions auditable.
Link 3 — Plan
Fields: the steps intended; the constraints applied; the alternatives considered where the system considers alternatives; a version for the planning contract itself.
The requirement that matters: the plan must be a separate record from the execution, because the two diverge and the divergence is diagnostic. A model can be unavailable; a planner can exceed its time budget; a fallback can fire.
Our own model routing is a worked example of this being taken seriously. Routing runs in one of three modes — off, shadow or active. In shadow, a plan is produced and recorded while execution is unchanged. In active, the planned model becomes the model the runtime is told to run. Because plan and execution are distinct events, the system records whether the plan was honoured, and a planner that exceeds its default 750 ms budget produces a named reason on the record rather than a silent fall-through. That is what "plan recorded separately" looks like as machinery. The plan-honoured gap is the detailed treatment.
Link 4 — Approval
Fields: whether approval was required and why; the approver; the time; what the approver was shown; the decision and any conditions.
The requirement that matters: what was shown. An approval record that says "Jane approved at 14:32" establishes very little. An approval record that says what Jane was looking at when she approved establishes whether the control was meaningful. This is the difference between an approval being a record and being an assertion, and it is the field most often missing. Human-in-the-loop approval patterns is the existing guide to designing the approval itself.
Link 5 — Execution
Fields: what actually ran; against which connection or system; the operation invoked; the credential reference; latency; the result; and whether the execution matched the plan.
The requirement that matters: failures recorded as fully as successes. This is where most systems are weakest, and it is where reviews concentrate. A trail that is complete for successful runs and thin for failed ones is worse than useless, because it produces a confident and wrong picture.
It is worth being concrete about how ordinary this failure is, including in our own system. Our session records carry a field for the error that ended a failed session, and in our production database it is populated in none of the error rows — the sessions are marked failed and the field that would say why is empty. The schema is right; the producer never writes it. When you evaluate any system, that is the specific gap to test for.
Link 6 — Artefact
Fields: what was produced or changed; where it went; a content hash; a version or revision reference in the target system.
The requirement that matters: a hash rather than the content, by default. It lets you prove that a specific output is the one the run produced without turning the evidence store into a second copy of your customer data. Retain the content itself only where an obligation requires it and a retention period bounds it.
Link 7 — Outcome
Fields: accepted, corrected, rejected or abandoned; who judged it; when; and the correction where one was made.
The requirement that matters: there must be a producer. This link is different from all the others because it does not exist in infrastructure — it exists in the business, so something in the product has to report it back when a person accepts or corrects the work.
This is the link we will be most candid about, because it is where a schema most easily flatters a system. In our own gateway the ingestion path and the storage for action outcomes are built, tested and mounted, and at the time of writing no producer calls them, so the outcome store is empty. We are saying so because it is precisely the thing a buyer should test rather than accept: a pipeline being built is not the same as an outcome being recorded. Ask to see a stored row, not a schema.
Cross-cutting requirements
| Requirement | Why | How to test it in an evaluation |
|---|---|---|
| Typed and versioned records | A record with a contract can be validated at write time and migrated later; free text can only be read by someone who already knows the format | Ask for the schema and its version field. Ask what happens to old records when it changes. |
| Append-only, tamper-evident | A record the owning team can edit establishes little | Ask whether there is an update or delete path, and who can reach the store directly. |
| Complete, not sampled | Sampling is correct for telemetry and fatal for evidence | Ask explicitly. Sampling is often a default nobody mentions. |
| Tenant-scoped end to end | A shared store is fine; a shared store any query can read across is a contractual problem | Ask to see the read path and what enforces the filter. |
| Retention by obligation | Log platforms default to weeks; obligations run for years | Ask where the record lives and what its retention is, separately from logs. |
| Exportable | A reviewer will want a file, not a login | Ask for a sample export of one run, end to end. |
If you operate in a regulated industry
Turn the seven links into rows of a procurement table with a column for how each vendor supplies it, and require an example record per row rather than a capability statement. Vendors answer capability questions optimistically and field questions precisely. Audit trails for AI agent activity in financial services covers the sector-specific additions, and the existing compliance design guide goes deeper on control mapping.
If you are a platform or engineering lead
Sequence the build by recoverability, not by difficulty: run identifier and identity first, policy decision second, outcome third, and everything else after. The first three are the ones where every day of delay is history you permanently cannot produce. The control plane architecture walkthrough covers where each is written.
If you resell this to customers
Add an eighth requirement: per-customer export. Your customers inherit your obligations and will eventually want their own records in their own hands. Designing for export from the start is cheap; adding it to a store that was never tenant-partitioned is not. Multi-tenant isolation for buyers covers the boundary guarantees.
Do this next
Take the seven-link table and mark each row present, partial or absent for your current system — this is a two-hour exercise with an engineer who knows the stack. Send the "absent" rows to any vendor you are evaluating and ask for a real stored record for each. Then read how to evaluate audit trail software for the buying process, or the evidence chain explained for how the seven links join up.
Questions people actually search for
- ai audit trail requirements
Seven links, each with its own field list: identity of the requester and the agent plus the boundary they belong to; the policy evaluated with its inputs and result; the plan and the constraints applied; any human approval with who, when and on what information; the execution including what actually ran and whether it matched the plan; the artefact produced and where it went; and the business outcome. Three of those - identity, policy and outcome - cannot be back-filled, which makes them the ones to specify first.
- ai agent audit requirements checklist
Ask ten questions of any candidate system. Is the actor established from the credential rather than the payload? Is the policy decision recorded with its reason? Is the plan recorded separately from the execution? Is a human approval a record or an assertion? Are failures recorded as fully as successes? Is there a run identifier tying every call to one business action? Is the record typed and versioned? Is the store append-only? Is retention set by obligation? And can you show me a real stored record, including a failed one?
- what fields should an ai audit record have
At minimum: a run identifier, a timestamp, the actor and the tenant or workspace boundary, the capability requested, the policy identifier with the inputs evaluated and the decision and reason, the plan and its version, the approval with approver and time, what actually executed with a credential reference rather than the credential, the result including failures, an artefact reference, and the business outcome. Record a credential reference, never the credential, and prefer content hashes to content wherever an obligation does not require the content itself.
- do ai audit trails need to be immutable
They need to be append-only and tamper-evident, which is not quite the same as immutable. Practically: no update or delete path in the application, the write path separate from the read path, schema changes controlled and versioned rather than applied in place, and enough integrity checking that alteration would be detectable. Full cryptographic immutability is sometimes required by a specific regulation and is otherwise a heavier commitment than most obligations need.
- what cannot be added to an audit trail later
Three things. Identity, because it is only known at request admission and a provider invoice knows an API key rather than a person or a customer. The policy decision, because it exists for a moment at evaluation and nothing downstream retains it. And the business outcome, because it never exists in infrastructure at all - it exists in a person judgement or a downstream approval. Everything else can be reconstructed with effort. These three cannot be reconstructed at any price.