What an audit log for AI agents has to contain
When an agent acts on production systems, the audit log is the only artefact that lets you answer “what happened?” without trusting anyone’s memory. Most logs record the action. That is a quarter of the story.
Five things per action
- The question. What the person actually asked, verbatim.
- The proposal. What the agent said it would do — operation, inputs, scope — before anything ran.
- The decision. Allowed, held for approval, or refused, and by which policy.
- The approval, if any. Who, when, what they saw.
- The receipt. What ran, against which system, when it finished, and what changed.
Append-only, enforced by the database
An audit log the application can edit is a diary. Withhold update and delete from the application’s database role, add a trigger that refuses them anyway, and the log becomes evidence. GlowForm’s is built this way: the api and worker connect as a role that cannot bypass row-level security and cannot alter audit rows, and the entry is written in the same transaction as the change it records, so there is never a change without its entry or an entry without its change.
Readable by the people it is about
A log only administrators can see is a log that gets read after the incident. Give managers the audit view for their workspace and the tickets stop: “did anyone retry that?” becomes a search, not a Slack thread.
One tenant, one log
In a multi-tenant product, the audit log is the first place isolation failures show up and the last place you want them. Tenant scope on the log should be enforced by the same row-level policy as every other table, and tested with a query that has no WHERE clause at all — it should return nothing from anyone else.