Learn/Governance · 7 min · updated 2026-08-03

An immutable audit log for AI-written code

What to record when an agent writes code, how to make the record tamper-evident with hash chaining and signatures, and which questions an auditor actually asks.

An immutable audit log for agent work records who or what changed each piece of code, under which instruction, and makes later edits to that record detectable. Git history is a start and is not enough on its own: it records the author of a commit, and the author field says the name of whoever ran the agent.

What to record

FieldWhy it is asked for
Human operatorAccountability sits with a person, always
Agent and model version"Which model wrote this" becomes answerable when a model turns out to have a systematic flaw
Instruction givenThe goal or prompt the session was working to
Stated intentWhat the session said it did, before the commit
Symbols changedThe structural delta, not the line diff
Verification resultWhether the change was checked against the goal, and the verdict
Timestamp and commitThe anchor into ordinary history

Making it tamper-evident

Immutable in practice means tamper-evident: entries are hash-chained, so each record includes the hash of the previous one, and rewriting an old entry invalidates every hash after it. Signing the chain head with a key the writer controls adds authenticity, so a record cannot be forged by someone with write access to the file. This is the same construction as a Merkle graph, applied to a sequence rather than a tree.

What it does not give you is prevention. Anyone with repository access can delete the log; the property is that they cannot alter it and leave it looking intact. For most purposes, detectability is the requirement.

Where to keep it

Inside the repository, in an append-only file, so it clones with the code and survives without a server. A hosted log has an owner and an outage; a file in the repository has neither. If a central copy is needed for reporting, replicate from the repository rather than making the server the source of truth.

Aura writes the intent ledger and the goal ledger as append-only files under .aura/, anchored to commits, so the record travels with the clone.

The questions it has to answer

  • Which changes in this release were written by an agent, and which by a person?
  • Who approved the ones that touched the payment path?
  • This function was deleted between March and June. By whom, under what instruction, and was it reviewed?
  • Was the change that shipped the one that was described?

A log that cannot answer the last one is a log of claims. That is the gap intent checking closes.

Questions

What is an audit trail for AI-generated code?

A durable record of who or what changed the code, on whose instruction, and what the change was checked against. For agent work it has to hold the session, the model, the instruction given and the outcome — the commit alone does not identify the author.

What should you log when an AI agent writes code?

The instruction it was given, the session and model that ran, the commits it produced, what was removed, and the result of whatever check decided it was done. Anything a reviewer would otherwise have to reconstruct by reading a transcript.

How do you make an audit log tamper-evident?

Chain it: each entry includes the hash of the previous one, so altering an old record invalidates everything after it. Sign the entries if the threat model includes someone who can rewrite the file, and store the chain where the code lives.

Is git history enough of an audit trail for AI code?

It records what changed and when, and it can be rewritten. What it never held is why — the instruction, the reasoning, the check that passed. With a person you could ask them. With a session that ended last month, if it was not recorded it is gone.