What belongs in an AI agent audit trail

An AI agent audit trail should let another person reconstruct a consequential request: who asked, what the system authorized, what actually ran and what happened afterward. A chat transcript can explain the surrounding conversation, but it rarely contains enough evidence to answer those questions on its own.

Begin with one operation. Follow it from request creation to the target system and back. At every step, decide which facts belong in the record and which component can reliably supply them.

Record decisions and outcomes separately

A request can be valid but denied by policy. It can receive approval and then expire before execution. An operation can start successfully and later fail. Preserve those differences.

Event	Useful fields
Request received	Request ID, agent identity, action, target, time
Policy evaluated	Decision, policy version, reason code
Approval recorded	Reviewer identity, approved request, expiry
Execution started	Operation ID, executor identity, start time
Execution completed	Result state, completion time, output reference
Recovery checked	Prior operation, observed state, next decision

These are example fields for designing a record, not a mandatory standard. A system may combine some events while preserving their meaning.

A timeout should leave an uncertain outcome visible until the system can reconcile it. Recording “failed” solely because the client stopped waiting can lead someone to repeat an operation that already happened.

Use identifiers to connect the record

Give each request an identifier and carry it across the components involved. If a request creates several operations, keep the parent relationship. Include a separate identifier for each retry attempt when the implementation distinguishes attempts.

OWASP’s logging guidance recommends interaction identifiers so related events can be connected. For an agent workflow, that connection helps distinguish one task from several unrelated requests using the same credential.

Record timestamps with an explicit time zone and monitor clock synchronization. Keep the event time separate from the collection time when records can arrive late.

Keep sensitive content out of routine events

A diagnostic result may contain credentials, customer information or internal topology. Logging every input and output by default copies that exposure into another system with its own readers and retention rules.

Choose the fields needed for investigation. Store a reference to protected evidence when the content must remain available, with separate access control. Do not put an access token into the event merely to identify the caller; use the validated identity or a suitable nonsecret identifier.

OWASP lists passwords, access tokens and other sensitive values among information that should usually be excluded or protected. Decide how your system handles those fields before connecting a real data source.

Preserve evidence from the executor

The agent may report that it restarted a service. Investigators need to know whether the receiving system accepted the request and whether execution completed. Prefer records generated by the components responsible for those events.

A human-readable explanation is still useful, especially when it links observations to a proposed action. Keep it visibly separate from the result state. The model’s account of success should not overwrite an executor’s timeout or error.

The following is an illustrative record. It contains fictional identifiers and is not a product schema.

Request: diagnostic-042
Agent: checkout-investigator
Action: service.health.read
Target: checkout-production
Decision: allowed
Policy: checkout-diagnostics-v3
Operation: operation-117
Outcome: completed
Output: protected evidence reference

A denied request would retain the request details and decision reason while having no execution outcome.

Protect the audit system itself

Limit who can read, change or delete records. Separate routine investigation access from administrative retention changes. Keep evidence of access to sensitive records.

Consider how the system detects missing events, collection failures or modifications. Calling a log “immutable” requires a mechanism that supports the claim and a clear account of who can bypass it.

NIST’s incident response guidance addresses protecting incident records and preserving their integrity and provenance. Apply your organization’s retention rules to both ordinary audit events and evidence preserved for an incident.

Run a reconstruction exercise

Ask an engineer who did not build the integration to investigate a completed test request using only retained records. Have them identify the requester, approved scope, actual target and final state.

Repeat the exercise with a denied action and a connection loss after dispatch. If they must ask the original operator what happened, add the missing evidence or document why that fact cannot be recovered. Test that redaction still removes sensitive values from error paths and exported records.