WhylineBlog ·
What an audit trail for AI-written code should record
Sooner or later someone asks why a piece of code exists: during an incident, a security review or an audit. If an agent wrote it, part of the answer is a prompt that git never saw.
Start from the questions
An audit trail is only useful if it answers the questions people actually ask. For AI-assisted code they are usually:
- Which changes did an AI agent make, and which agent?
- Who asked for them, and what did they ask?
- What else changed in the same session?
- Who reviewed the change before it shipped?
The minimum record
| Field | Why it matters |
|---|---|
| Agent | Whose behaviour to look at, and a way to compare agents. |
| Prompt, or that there was one | The intent behind the change. Without it you are guessing from the diff. |
| Files | How far one request reached. |
| Commit | Joins the record to git history, so it can be found from any line with git blame. |
| Author | The person who ran the agent and committed the result. |
| Time | When it happened, taken on the developer's machine so work done offline keeps its real time. |
Review is the one question this list leaves to your code host: pull request approvals already record who reviewed what.
Where to keep it
- In the repository (commit trailers, git notes, a separate branch): travels with the code. Anyone who can read the code can read the record, and rewriting history can rewrite the record too.
- Outside the repository (a service): searchable across repositories, with its own access control, and unaffected by a force push. It is one more system to run and to trust.
The two combine well: a trailer in the commit as a quick signal anyone can see, and a separate store for the prompts.
Prompts are sensitive data
Prompts can contain an API key pasted in while debugging, customer data, or plans that are not public yet. Decide three things before you start recording them:
- Full text or not. Recording that a prompt happened, without its text, still shows that a change was AI-assisted. In Whyline that is
--no-prompts. - Who can read them. In Whyline, anyone with the workspace key can read everything in the workspace, so share the key as you would a password.
- How long to keep them. Whyline keeps events until you delete the workspace with
whyline delete-workspace; there is no setting yet that removes old events on a schedule.
The data and privacy page lists exactly what the CLI sends and keeps.
What regulation says
Much of what is written about “AI audit trail requirements” comes from vendors, this blog included, so read it with care. The text most often cited is Article 12 of the EU AI Act, which requires high-risk AI systems to allow the automatic recording of events (logs) over their lifetime. It applies to those systems themselves and says nothing specific about prompts or about code written with an assistant. Whether it, or any other rule, applies to how you build software is a question for your counsel.
The practical case does not depend on regulation: when an AI-written change causes an incident, the record of what was asked is what lets you find the cause.
How Whyline covers it
Each Whyline event records the agent, prompt, files, commit, author and time. whyline blame goes from a line to its record, the dashboard filters the timeline by file, prompt, agent, author or commit, and Export CSV hands over the full history. Its limits, stated plainly:
- A workspace has a single API key, with no per-person accounts or permissions. If it leaks,
whyline rotate-keyreplaces it. - Single events cannot be changed or deleted through the API, only a whole workspace. Records are not tamper-evident: anyone with access to the database can change them.
- Prompts are linked for agents with a hook (Claude Code, Cursor, Codex CLI, Gemini CLI); other agents are recorded from their commit trailers.