What Should an AI Agent Audit Trail Capture?

A trace is useful, but it isn't automatically an audit trail

Engineering traces help diagnose prompts, model calls, latency, tokens, and tool execution. An accountable run record has a wider audience and purpose. Security needs to investigate access and attempted violations. Operations needs to understand failures and recovery. Risk needs to see which approved control applied. The business owner needs to connect the run to a customer or process outcome. The evidence model should relate these views without requiring every reviewer to read raw chain-of-thought or join unrelated logs.

Capture the evidence chain from request to outcome

Begin with the request and actor, then preserve each consequential transition. Record the agent and version, owner, use case, delegated context from the person it acts for, relevant policy and permission versions, input references, retrieved sources where needed, tool and system calls, resolved action arguments, policy results, blocks, approvals, fallback steps, target-system responses, and final run outcome. Business-outcome evidence comes from the enterprise system of record, not from this record alone. Include correlation identifiers so records can be reconciled with systems of record without copying every source field into the evidence store.

• Who: person, agent, owner, service, and delegated context
• Why: assigned job, use case, purpose, and initiating event
• What informed the action: relevant context and source references
• What was attempted: tool, system, resource, action, and arguments
• What controlled it: permission state, policy version, result, and reason
• What happened: block, approval, system response, fallback, and outcome

Record denied and transformed actions

The most important evidence may describe what the agent was prevented from doing. A denied refund, redacted identifier, narrowed query, or blocked outbound connection shows where the control changed the run. Record the attempted action and policy result without retaining protected content that the policy was designed to remove. Repeated blocks can reveal a permission mismatch, agent defect, prompt-injection attempt, or changing business requirement.

Connect evidence to the system of record

The audit trail shouldn't replace the CRM, ticketing, payment, identity, or workflow system. It should link the governed run to the records those systems already own. Capture stable references, timestamps, relevant before-and-after state, and the target system response. This makes the evidence defensible while preserving established ownership. It also helps operations distinguish an action the agent requested from a change the target system actually committed.

Protect the evidence itself

Evidence can contain sensitive data, security context, business rules, and internal system details. Apply access controls, retention, encryption, redaction, regional requirements, and integrity measures appropriate to the workload. Avoid logging secrets, full credentials, or unnecessary personal data. Define who may view raw technical events, who receives a summarised review record, and how evidence is exported or deleted. A complete log that creates a new data exposure isn't good governance.

Make the record understandable to an independent reviewer

Test the audit trail with someone who did not build the agent. Give them one run and ask which agent acted, what authority applied, which action was attempted, whether sensitive data was changed, why the policy returned its decision, what reached the target system, and how the workflow ended. If the answers require tribal knowledge or manual correlation across several dashboards, the evidence model is incomplete. Preserve raw events where needed, but provide a coherent run-level view.

Minimum run-evidence event

Store raw technical events where operationally necessary, but make the accountable event stable enough to export and review. Sensitive values can remain in the authorised system of record while the evidence uses protected references.

• Run ID, parent run ID, event ID, timestamp, and sequence number
• Use-case ID, owner, requesting principal, agent ID, and version
• Authority grant, policy version, decision, reason code, and decision point
• Target system, protected resource reference, tool, operation, and validated argument summary
• Data classes detected, transformation applied, and approved destination
• Attempted, blocked, completed, retried, reversed, or unknown action state
• Human reviewer, decision, conditions, and expiry where applicable
• Target-system response reference, fallback, and final run outcome
• Integrity, retention, access, export, and deletion metadata