Guide

An audit trail for AI agents

The moment an agent acts for a client, someone will ask the question every team dreads: why did it do that? This guide covers what an agent audit trail actually has to contain, why a request log does not qualify, and how to record one you can hand to a compliance reviewer, with working code you can run locally.

What must an AI agent audit trail contain?

A defensible audit trail answers four questions about any action the agent took, after the fact and under scrutiny:

What did the agent believe at the moment it acted, not what the database says now.
Where did each belief come from: the source, the time, and the evidence chain behind it.
What disagreed: if two sources conflicted, both sides, and which one was believed and why.
Who authorised the action: a named approver for anything risky, recorded with the decision.

If any of the four is missing, the trail collapses under the first real question. Most teams discover this during a client’s security review, which is the most expensive possible time.

Why is a request log not an audit trail?

Logs record what the system did. An audit trail for an agent must also record what the system believed, because the belief is the reason for the action. Three failures make ordinary logging insufficient:

Overwritten state. Most memory stores keep only the current value. When a fact changes, the old value, the one the agent actually acted on, is gone. You cannot reconstruct the decision.
Silent conflict resolution. When two facts disagree, last-write-wins picks a winner and leaves no trace that there was ever a disagreement.
Mutable history. A trail the system can rewrite later is not evidence. Reviewers know this, which is why financial systems use append-only ledgers.

Record beliefs, not just events

pip install omem-infrastructure

omem-server

# every belief is recorded with source, time, and evidence

from omem import Memory

mem = Memory(api_key="omem_sk_...", project="proj_...",

base_url="http://127.0.0.1:8787")

a = mem.remember("agent:support", "customer:alice",

"prefers_annual_billing")

mem.why(a["id"])

# -> who asserted it, when, its evidence chain,

# and anything on record that contradicts it

why() is the core of the trail: for any belief, the full chain of assertions and evidence that led there. When a client asks why the agent believed something, this is the artifact you export and send.

Keep the disagreement, not just the winner

mem.remember("agent:sales", "customer:alice",

"not:prefers_annual_billing")

mem.conflicts()

# -> both claims, each with its agent, source, and recency.

# Nothing was overwritten; the disagreement is part of

# the record, which is exactly what an auditor wants.

Ask what was believed at the time, not what is believed now

# the agent acted on Tuesday; reconstruct Tuesday

mem.recall(about="customer:alice", as_of="2026-08-25T14:00:00Z")

# -> the beliefs as they stood then, not as they stand today

This is the capability request logs cannot fake. If the memory overwrote the past, the honest answer to “what did it know when it acted” is “we no longer know”.

Record who approved the risky actions

Belief provenance covers why it thought that. The other half is who let it act: risky actions should wait for a named approver, and both the approval and any refusal should land in the same record. That pattern has its own guide: human-in-the-loop approvals for AI agents.

Can the trail itself be trusted?

A trail is only as good as its resistance to revision. In OMEM the record is an append-only operations log, and the engine that interprets it is frozen: it replays byte-identically, verified on every commit, so a software upgrade can never rewrite what was believed. Retraction exists, but as a new recorded operation that withdraws a belief and cascades to its conclusions, never as an edit to history.

Run it locally in a minute The accountability overview