What should an AI audit log contain?

An AI audit log is useful when it helps someone reconstruct a consequential decision. A large pile of prompts rarely does that on its own. The reviewer needs to know which system acted, under whose authority, according to which rule, and with what result.

Those four questions give you a design target. Each field you record should help answer one of them.

A colleague who was not present should be able to explain a specific action from the evidence, including the limits of what was observed.

Start with stable identifiers

Give the AI system, the agent, the session, and the policy version consistent IDs. Link the agent to the person or service that delegated the work when that information is available. Prefer identifiers that survive renames, so an agent that changes its display name keeps its history.

A log line that says an agent called a tool tells a reviewer little until it also names the system, the delegating user, and the rule that applied. Without those relationships, a sequence of technically detailed events can still be hard to explain. For more on delegation, see giving AI agents identities you can revoke.

Record the decision and its basis

Useful fields include the action requested, the relevant resource, the control that evaluated it, the outcome, and the timestamp. Keep the outcomes distinct, and avoid collapsing them into a single success counter.

A control error deserves its own row. If it is counted as an allow or a deny, the totals mislead everyone who reads them.

A hypothetical sample record

The record below describes a refund request. It shows how the fields fit together.

A reviewer holding this record can answer the four questions without calling the engineer who built the agent.

Keep change history

A record should still make sense after a model, a tool, or a policy has been updated. Store references to the version that actually applied, and preserve the context needed to interpret it.

An export assembled later should not silently substitute today's configuration for yesterday's decision. If a policy changed on Tuesday, a Monday decision should point to Monday's version.

Collect payloads deliberately

Prompts and responses can contain sensitive business or personal information. Settle four questions before you capture content.

• Need. Which investigations require the actual text?
• Form. Can the content be redacted, hashed, or summarized?
• Access. Who can read it, and how is that access logged?
• Retention. How long does it stay, and who approves a longer hold?

Document what is missing when minimization limits a later investigation. A reviewer who knows the log holds metadata only can plan around that limit. A reviewer who assumes full capture may draw the wrong conclusion.

Check integrity and completeness separately

Protecting a stored record from alteration does not prove that each relevant event reached the store. Integrity and completeness are two separate checks.

Monitor dropped events, collection failures, and periods when a control was disconnected. Evidence should expose those gaps and avoid suggesting uninterrupted coverage. Our post on what happens when an AI control goes offline covers how to label a period with no complete record.

Know who will read it

Different readers bring different questions to the same record.

• Security responders. They ask what the agent did, in what order, and what it touched.
• Governance reviewers. They ask which rule applied and who approved an exception.
• Finance and operations. They ask which agent and model generated a cost.
• Internal audit. They ask whether the record is complete for the period under review.

Design the export so each reader can filter to their own question without asking an administrator for help. For a framework view, see our post on NIST AI RMF, from framework to runtime evidence.

Make the record usable outside the product

A reviewer may need a scoped export, a link into an incident system, or an explanation that does not require administrator access. Include the provenance and the field definitions needed to interpret the data.

During an incident, the first reader is often an engineer or a manager who has never opened the governance console. Plan for that reader. For the response itself, see how to respond to an AI agent incident.

Run the colleague test

Try one question. Can a colleague who was not present explain a specific action from the evidence, including the limits of what was observed? If the answer is no, add context before adding more volume.

Pick three real actions to test. Choose one that was allowed, one that was blocked, and one that needed approval. Ask someone outside the team to explain each from the export alone.

A failed test points to one of three gaps.

• Identity gap. The reader cannot tell who delegated the work.
• Basis gap. The reader cannot tell which rule or version applied.
• Coverage gap. The reader cannot tell whether events are missing.

Fix the gap first, and add volume only if a specific question still needs more detail.

How Halo helps

Halo records decisions, approvals, denials, costs, and configuration changes. Audit logs and gateway decisions export as CSV and JSON, and dashboards show audit statistics and decision timeseries. In the standard configuration, Halo Browser leaves content inspection off because it requires expanded permissions that the customer approves, and Halo Endpoint's standard collection is metadata-first and excludes prompts, responses, documents, clipboard content, and credentials. Explore audit and evidence, the AI audit trail definition, and AI compliance evidence.