Traditional application logs answer technical questions: did the request fail, how long did it take, and which service returned an error?
An AI agent audit trail has to answer a harder set of questions. Who asked the agent to act? What did it know at the time? Which tools were available? Why was the action allowed? What changed outside the agent?
If those answers live across prompt logs, identity systems, model-provider dashboards, workflow engines, and SaaS audit logs, an investigation becomes engineering archaeology.
The minimum viable run record
Treat a run as the envelope that connects every decision and effect. At minimum, capture:
- —a stable run identifier and timestamps;
- —the initiating person or system;
- —the agent identity, version, owner, and operating environment;
- —the trigger or user request;
- —model and provider identifiers;
- —retrieved sources and relevant context references;
- —tools offered to the agent;
- —tool calls, arguments, results, and retries;
- —policy checks and their allow, deny, or require-approval outcomes;
- —human approvals, rejections, edits, and rationale;
- —external effects such as a changed record or sent message;
- —token usage, provider cost, latency, and final status.
Not every field should be visible to every reviewer. The record still needs to exist under an appropriate access and retention policy.
Capture facts, not hidden reasoning
An audit trail does not need a model's private chain of thought. It needs the operational evidence around the decision.
Store the instructions the system supplied, the context the agent received, the tools it could call, the action it proposed, the policy result, and the observed effect. These are inspectable facts. They let a reviewer reconstruct the path without claiming access to an authoritative internal explanation from the model.
Keep identity attached across systems
One run can cross several trust boundaries. A user starts a workflow, an agent calls a connector, the connector invokes a vendor API, and the vendor changes a record.
Correlation breaks when each system assigns an unrelated identifier. Carry a stable run or effect key through logs and connector metadata wherever the provider supports it. Record both the human initiator and the agent actor. Preserve parent-child links when one agent delegates to another.
The goal is a chain of custody for the action.
Make the evidence tamper-resistant
An audit record that the acting system can silently rewrite is weak evidence. Prefer append-only event storage, restricted write paths, explicit correction events, retention controls, and integrity checks on exports.
When evidence is packaged for review, freeze the included event set and record a manifest. A later reviewer should be able to tell what was included, when it was produced, and whether the package changed.
Observability and audit serve different readers
Engineers need detailed traces to debug behavior and build evaluations. Risk and compliance teams need a concise account of authority, policy, evidence, and outcome. Finance needs cost attribution. An approver needs the few facts required to decide.
Use the same underlying run record, then present role-specific views. Duplicating separate “compliance logs” and “engineering logs” creates gaps precisely when an investigation needs them to agree.
Test the reconstruction
The best audit-trail test is not “did we emit logs?” Pick a completed action and ask a reviewer who did not build the system to reconstruct it.
Can they identify the request, agent, data sources, policy decision, approval, tool effect, and cost without opening five consoles? Can they distinguish a denied action from a failed one? Can they see whether the evidence is complete?
If not, the system has telemetry. It does not yet have an audit trail.