What is an audit log?

An audit log is a record of consequential actions taken in a system: who did it, what they did it to, when, from where, and what the thing looked like before and after. It exists to answer a question asked after the fact, usually by somebody who was not there and is not inclined to take your word for it.

Almost every system has logs. Very few have an audit log, and the difference is not volume.

What separates it from application logging

It is append-only. Entries are written once and never updated or deleted. A log whose rows can be edited by the same code path that writes them answers nothing, because the first thing an attacker or a careless migration does is tidy it.

It records the actor, not just the event. "Permission changed" is a log line. "Dana changed the Finance team's grants from read-only to include posting, at 14:12 UTC, from this address" is an audit entry. The actor, the target, the time, the origin and the before-and-after are all load-bearing, and the last is the field most often missing.

It is tamper-evident. Append-only by convention is weak; enforced by the storage layer is better; hash-chained entries, or a periodic digest written somewhere the application cannot reach, is what lets you claim nothing was removed rather than that nothing appears to have been.

Its retention runs the other way. Application logs are expensive and get swept in days or weeks. An audit log answers "who changed this" a year later, so a retention policy that shortens it has removed the only reason it was kept.

It has its own access control. Reading an audit log is a privileged action, and in a well-built system it is itself audited. It should also hold as little content as it can get away with — a verb, an actor, a target and a diff, not credentials and not the body of what was written — or it becomes a second copy of your most sensitive data with a longer retention period than the original.

Auditing an AI action

This is the part that is newly urgent and badly served. When a model calls a tool, the action is real: a message posted, a record updated, a refund issued. An audit entry for it needs four things, and most systems record one.

Which tool ran, with which arguments. The resolved arguments, after whatever the application filled in, not the model's request.

Whose authority it ran with. A tool call runs on a key, and that key belongs to a person or to a service identity carrying a set of grants. The entry has to name that identity, because "the assistant did it" is not an answer to who authorised it. This is where role-based access control and agent auditing meet: if write tools are granted by name rather than inherited from read access, the log of a write is also the record of a deliberate grant.

What it read. Which records were retrieved and placed in front of the model.

What it changed. The before and after, on the system that holds the record.

Logging the prompt is the easy half

Most AI observability stops at the prompt and the completion. That pair tells you what the model was asked and what it said, which is enough to debug a refusal and not nearly enough to explain an answer.

The explanatory half is the retrieval. An answer is a function of the question and of whatever context was assembled for it, and without the second you cannot distinguish a model that reasoned badly from a model that was handed the wrong three records. Six months later the stores have moved on, so the retrieval cannot be re-run to find out — unless the underlying store keeps its history and can be read as it stood on that date. Logging which records were in front of the model is what makes an answer explicable rather than merely reproducible.

Where an audit log stops

An audit log records what happened. It does not establish that what happened was authorised, only that somebody with a credential did it, which makes a compromised credential invisible to it. It is evidence of action rather than of intent, and it cannot capture a decision taken in a conversation and executed by hand.

Two practical failures are more common than tampering. The first is a log nobody can query: every event, no schema, no way to ask "what changed about this team in March", which in an incident is the same as having nothing. The second is the collision with erasure — a person's right to have their data deleted sits directly against an append-only record of what was done to it, and the only sane resolution is to hold so little personal content in the log that there is nothing much to erase.

Memtro's audit log records administrative changes with who made them and when: members added, removed and promoted, teams and what each team grants, API keys created and revoked, routing, allowances and retention windows, connection access, identity providers, and every erasure. It holds no prompts, no answers and no credentials, and it is not shortened by the retention sweep. Separately, each request is recorded by user, team and model with its token counts, and answers carry the records they drew on. What Memtro records lists the lot.