AI agent audit trails: why logs can't explain what your agent did

Every log was there. The explanation wasn't.

A global manufacturer uses an AI agent to review supplier invoices before payment. One invoice is put on hold because the agent detects a possible supplier-identity mismatch.

The agent retrieved the invoice, the supplier master record, contract amendments and correspondence. A model classified the case as identity_mismatch with a score of 0.91. A policy required manual review. An analyst reviewed a summary and approved a temporary hold. Hours later, a background worker set the hold in the ERP.

The supplier challenges the decision. The incident team collects every record:

• Retrieval logged that it considered fourteen candidates and returned five, but not the document text, for privacy reasons.
• The model gateway logged the model version, latency, tokens and the classification, but not the prompt or context.
• The policy service logged REVIEW_REQUIRED and a policy version, but identified the worker service rather than the analyst, and not how model output became policy facts.
• The approval system logged approved = true and the summary shown, but not a fingerprint of the exact proposal the worker later committed.
• Tracing showed successful spans, but the human wait started a new trace, and the original had already aged out.
• The ERP logged that a valid service account set the hold.

Every record is accurate. Together they give a timeline. They can't answer the questions that matter: which evidence influenced the score, whether a stale or unauthorized document shaped the ranking, whether the reviewer saw the same proposal the worker committed, which policy obligations were enforced, and whether the ERP change matched what was authorized.

The problem isn't missing logs. It's the absence of a shared evidence model that gives those logs meaning. EY's 2026 survey found that 72% of senior leaders worry they can't trace the data lineage and inputs behind critical AI decisions. This is why.

Logs are local observations

A log line is written by one component, from its own point of view: what it knew, what it tried, what it saw. That's valuable, and incomplete by design. Retrieval doesn't know which policy decision its results will feed. The model gateway doesn't know whether its output becomes a note or a payment. The policy engine doesn't know whether its obligations were enforced.

Different signals answer different questions. Collecting more of one doesn't produce the answer another was meant to give.

Why isn't a trace ID enough?

Because agent work outlives a trace. Tracing links operations across services into one technical path, and that's essential. But agent workflows wait for people, receive events, fan out to models and tools, retry, reconcile and continue hours or days later. A queue consumer starts a new trace. A human approval sits outside tracing altogether. An external API returns a receipt with no trace context. And traces are sampled.

Even a perfect trace answers a technical question: which operation followed which. Explaining a business outcome needs several distinct identifiers that shouldn't be collapsed into one:

The trace ID still matters. It's one member of this set, not the identity of the outcome.

A timeline is not a cause

A timeline shows that one event came before another. It can't show that the earlier event justified, authorized or influenced the later one. That needs explicit, recorded links:

• Context c-88 supplied the evidence for proposal pr-12.
• Proposal pr-12 was mapped into the facts policy decision d-73 evaluated.
• Decision d-73 required approval a-09, with obligations that had to hold.
• Approval a-09 was bound to pr-12's exact fingerprint and authorized operation o-61.
• Operation o-61 produced confirmation e-14 once the ERP changed state.

Without links like these, investigators infer cause from timestamps, log wording and proximity. That gets unreliable fast when work is concurrent, event-driven, retried or long-running.

What should an AI agent audit trail record?

Evidence at every consequential step, tied together by shared IDs: the context used, the proposal, the policy decision, the approval, the action and the confirmed result. The fix starts with the workflow definition. If the consequential steps (context selection, proposals, policy decisions, approvals, actions, confirmations) are explicit in the definition, the runtime can emit a typed evidence event at each one, tied to the version and execution:

An evidence event isn't a verbose log line. It marks a defined change in meaning or authority, and it can carry a snapshot, a fingerprint, a reference to protected storage, or a mix, depending on consequence and privacy.

Make evidence a condition of publishing

Ad hoc logging asks each team to guess what might be useful later. Governed evidence is declared up front: the workflow states which evidence each consequential step must produce, and a workflow that can't produce it doesn't publish.

That also defines what happens at runtime when evidence can't be produced. Instead of continuing silently and leaving an unexplained action behind, the step stops, captures a protected snapshot, routes to a person, or proceeds under an explicit, recorded exception.

Sampling is fine for telemetry, not for evidence

Observability tools sample and expire data to control cost. That's right for telemetry. It's wrong for evidence. The trace you sampled away may be the execution someone challenges next quarter. Keep two separate guarantees:

• Operational observability: statistically useful signals about system behavior. Sample it.
• Execution evidence: the minimum record needed to explain one specific outcome. Never sample it.

The answer isn't to log everything

The naive fix (keep every prompt, document, payload and output forever) creates a second high-value store full of personal data, credentials, trade secrets and restricted documents. Complete evidence and data minimization aren't opposites:

Explainability is not universal visibility. An auditor may need to verify that a restricted source influenced a decision without reading it. A developer may need the failing mapping without seeing customer data.

One record, many questions

The same execution shouldn't force every stakeholder to build their own version of the truth from different dashboards. One evidence model can serve them all:

Replay needs evidence, not log playback

Replaying log lines reproduces a story. It doesn't rebuild the state, versions, context, authority, policy or approvals behind a decision. With an evidence model you can inspect a past run without executing anything, reconstruct its path, or simulate the same case under a proposed change, all without touching live systems. When a historical model or document is gone, you can still tell an honest reconstruction from a present-day rerun.

Common anti-patterns

Ten rules for explainable agent execution

1. Treat logs as local observations, not the full record.
2. Tie every consequential record to the workflow version, execution and step.
3. Keep distinct identifiers for context, proposals, decisions, approvals, operations and confirmations.
4. Record causal links instead of inferring them.
5. Emit typed evidence at context selection, proposal, policy, approval, action and confirmation.
6. Make evidence completeness part of publishing.
7. Never sample mandatory evidence.
8. Minimize sensitive content; keep references, fingerprints and provenance.
9. End the chain with the target system's confirmation, not a successful request.
10. Serve operations, audit, business and replay from one permission-aware record.

The result: explainable by construction

Logs, metrics, traces and audit records all remain essential. Their limit isn't that they're weak. It's that each one is written by a component whose job is smaller than the whole outcome. An evidence model supplies the missing layer and lets you answer the question that matters after a challenge: why did the agent produce this outcome, and can we prove it was the outcome we allowed?