Audit Trail for AI-Generated Code: What to Record and How to Verify It
By Shiva Mangal, Grail Computer Labs. Shiva previously built Nurture Labs, where one product passed $2M in lifetime revenue. Published 28 October 2026.
An audit trail for AI-generated code is a tamper-evident record that links each code change to the agent, model version, prompt, tests and human reviewer behind it, so anyone can verify what changed and why. AI already accounts for 42% of committed code, and developers expect 65% by 2027 (Sonar, 2026). Git alone does not hold the record. A commit shows an author and a message. It does not show which model wrote the diff, what it was asked, or which test suite accepted it. This post specifies the fields to record, the single key that joins them, and where financial-workflow code needs more than product code.
Key Takeaways
An audit trail for AI-generated code must tie seven records (agent, model version, prompt, tool actions, tests, reviewer, merge) to one diff through a shared join key.
Git history records an author and a committer only, so model, prompt and test evidence must be stored alongside it.
Agent traces show what an agent did, not who authorised it, so an approval record is a separate requirement.
Treasury and financial-workflow code needs a second reviewer who did not prompt the change, plus money-path tests.
An audit trail proves process, not correctness; tests and engineer review still decide quality.
What audit trail does AI-generated code leave, and how do we verify what changed and why?
AI-generated code leaves only the trail the tooling records: usually a commit, an author field and a pull request approval. By our reading of git's commit format, git stores an author and a committer, and nothing about the model, prompt or tests. Sonar's 2026 survey of 1,100+ developers found 96% do not fully trust AI output, yet only 48% always verify it (Sonar, 2026).
Close view of a printed commit history with one line highlighted in blue ink
Why code review and audit logs fall short
The share of AI code is large and rising. Developers report that AI accounts for 42% of committed code today and expect 65% by 2027 (Sonar, 2026). That figure is self-reported, but the direction is clear.
Reviewers also need to know which diffs came from an agent. CodeRabbit's analysis of 470 open-source GitHub pull requests (320 AI-co-authored, 150 human-only) found AI-generated PRs contained about 1.7× more issues overall, and logic and correctness issues were 75% more common (CodeRabbit, 2025). It is vendor research with stated limits, yet it supports one rule: an AI-authored diff should be marked as one.
Standard audit logs record that a person approved a pull request. They do not record what the approval was based on. Traditional code review assumes the author can explain the change. An agent cannot be asked later, so the explanation must be captured when the change is made.
Where verification happens today
Developers mostly check AI output by hand. In Stack Overflow's 2026 survey, 76% run it locally, 64% compare it with the codebase and 53% check tests or security, while only 10% use answers as-is (Stack Overflow, 2026).
Horizontal Bar chart: How developers validate AI output. Highest: Run it locally at 76%.
Those checks are sensible. They are also invisible. Nothing in the repository shows that someone ran the code or compared it with the codebase. Stack Overflow's CEO says "that skepticism now acts as a critical safeguard" (Stack Overflow, 2026). A safeguard that leaves no record cannot be audited.
What must an audit trail for AI-generated code record?
An audit trail for AI-generated code must record seven things against one diff: the agent identity, model version, prompt and context, tool actions, the test suite with its results, the human reviewer's decision, and the merge. Stack Overflow's 2026 survey found 78.7% of developers say source attribution is important or very important (Stack Overflow, 2026).
A single diff printout connected by coloured string to five paper record cards
Stack Overflow's CEO puts the need plainly: "developers need to know where an answer came from, what context informed the information that was produced or a decision that was made" (Stack Overflow, 2026). The table below turns the seven records into fields.
Record
What to store
Why an auditor asks
Agent identity
Agent ID, version of the agent software, named human sponsor
Who or what made the change
Model version
Pinned model identifier, not an alias such as "latest"
Behaviour changes between versions
Prompt and context
Task text, files and instructions supplied
Why the change took this shape
Tool actions
Commands run, files read and written, secrets masked
What the agent actually touched
Test evidence
Suite version, results, rejected or incomplete attempts
What accepted the change
Human review
Reviewer ID, decision, comments, time
Who approved it
Merge and release
Commit SHA, PR ID, release ID
What reached production
Link the records with one join key
A join key is an identifier that appears in every record so they can be linked to one diff. The commit SHA or pull request ID works well, with a trace ID stored beside it. A worked example, with illustrative values:
The agent starts a run and receives trace ID tr-7f21. The task is stored against it.
The agent commits. The commit message carries the trailer Trace-Id: tr-7f21, and the commit gets SHA a3f9c21.
The test run stores its result under a3f9c21: suite version, 214 passed, one earlier attempt rejected as incomplete.
The reviewer approves PR 482. The approval record stores reviewer ID, time and the SHA approved.
The merge stores release ID and the same SHA.
The commit SHA now retrieves all five records, and the trace ID reaches the same set.
Treat tests as evidence, not as a rubber stamp
A test suite is acceptance evidence only if it is independent of the change. When the same model writes the implementation and its tests, the tests mostly confirm the model's own reading of the task. Record who owns test intent, which suite version ran, and every rejected attempt. A rejected attempt shows the gate worked.
What does 'agent traces recorded' mean in practice?
Agent traces recorded means every agent run emits a structured log of its steps: each model call, each tool call, the inputs and outputs, and timing, all keyed to one run ID. In Stack Overflow's 2026 survey, 76% of developers validate AI output by running it locally, a check that leaves no record unless a trace captures it (Stack Overflow, 2026).
Fibre-optic cables glowing blue entering a server patch panel
OpenTelemetry is an open standard for emitting traces and metrics, with GenAI semantic conventions for agent runs. Its conventions describe spans such as invoke_agent, chat and execute_tool, but remain at Development stability as of October 2026 (Agentailor, 2026).
An agent trace is the structured log of one agent run. At minimum, a useful trace holds:
the trace and run ID, and the agent ID
the pinned model identifier for every model call
each tool call, with arguments, result summary and duration
the files read and written
the final outcome: diff produced, tests run, errors raised
Two limits matter. First, attribute names in the OpenTelemetry conventions can still change, and message content capture is opt-in. Teams should pin the convention version in use. Second, a trace shows what the agent did, not which rule or person authorised it. We recommend a separate authorisation record: the approved task, the permissions granted and the sponsor.
Choose how to attach attribution to git
Three mechanisms exist, and they answer different questions.
Mechanism
What it records
Limit
Commit trailers (Co-authored-by, Assisted-by)
Agent or tool name on the commit
Inconsistent across tools; Co-authored-by implies a person
Line-level link to agent, model and session under refs/notes/ai
Needs tooling; notes must be pushed with the repository
OpenTelemetry traces
Full run path and tool calls
Lives outside git; needs a join key back to the SHA
A sound default is a trailer carrying the trace ID, with the trace store holding the detail. Privacy needs care: traces can contain prompts and tool results, so teams should mask likely secrets before they reach the agent, restrict access to traces, and set a retention period an auditor can read.
How does treasury and financial-workflow code differ from product code?
Treasury and financial-workflow code moves or records money, so its audit trail needs stricter approval than product code: a second reviewer who did not prompt the change, tests for money-path behaviour, and an evidence record that survives an audit. CodeRabbit found logic and correctness issues 75% more common in AI pull requests (CodeRabbit, 2025). Public treasury guidance is thin, so these controls are engineering recommendations.
Two brass keys on a ledger book representing two required approvers
Three terms frame the difference. Maker-checker is a control where one person proposes a change and a different person approves it. Segregation of duties is the wider principle that no single person can both create and release a risky change. Idempotency is the property that repeating the same payment request has the same effect as sending it once.
Control
Product code
Treasury and financial-workflow code
Reviewer
One engineer, may be the prompter
Second reviewer who did not prompt the agent
Tests
Feature behaviour
Rounding, idempotency, reconciliation, failure and retry paths
Paths touched
Any
Payment and ledger paths flagged and routed to extra review
Evidence kept
Commit and PR
Full seven-record set, tamper-evident, retained for the audit period
Change control
Team convention
Documented change approval, as financial-controls audits expect
Regulators are moving in the same direction. The Monetary Authority of Singapore (MAS) published a consultation on AI risk management guidelines on 13 November 2025 (MAS, 2025). A secondary summary reports that MAS issued the final guidelines on 7 October 2026 (RegReportingDesk, 2026). We have not checked the primary text, so teams in Singapore should confirm the wording and effective dates on mas.gov.sg before mapping controls to it.
How does SOC 2 CC8.1 change management apply to AI coding agents?
SOC 2 criterion CC8.1 covers change management; in our reading, changes to systems must be authorised, tested and approved before release. For AI coding agents, an audit trail supplies that evidence for each diff. Stack Overflow's 2026 survey found 53% of developers check tests or security on AI output (Stack Overflow, 2026), and the trail records that check.
The mapping below is our engineering reading, not auditor guidance. An auditor decides what satisfies the criterion.
Change-management element
Record that supports it
Change is authorised
Task record and named sponsor
Change is tested
Test suite version, results, rejected attempts
Change is approved
Reviewer ID, decision and approved SHA
Change is released
Release ID and merge SHA
Two points are specific to agents. The approver must be identifiable as a human, so an agent's own approval does not count. The record must also show that an agent wrote the change, so the reviewer knows the diff needs closer review: AI-authored pull requests carried about 1.7× more issues in CodeRabbit's 2025 sample (CodeRabbit, 2025).
How does the Software Factory release loop produce this record?
The Software Factory, the AI software factory of Grail Computer Labs (GC Labs), runs each change through Triage, Specify, Implement, Review, Verify and Release, with engineers reviewing every change, tests rejecting incomplete work and agent traces recorded. Each stage leaves an artefact for the diff, which matters because 78.7% of developers rate source attribution important (Stack Overflow, 2026).
A six-stage conveyor of small blocks passing through a checkpoint gate
Stage
What happens
Artefact to attach to the diff
Triage
The request is classified and scoped
Task record and sponsor
Specify
The expected behaviour is written down
Acceptance criteria
Implement
The agent writes the change
Agent trace, model version
Review
A GC Labs engineer reviews every change
Reviewer ID and decision
Verify
Tests reject incomplete work
Suite version, results, rejected attempts
Release
The change ships
Release ID and SHA
The principle is short: agents execute, humans decide, customers see progress. Likely secrets are masked before they reach an agent, and access can begin read-only.
Our data: For a Singapore-based neobank, GC Labs built a human-reviewed know-your-transaction (KYT) workflow in one week that raised automated approvals from approximately 44% to approximately 90% in testing. GC Labs also put eight transaction checks live for the same neobank in under 30 days.
Those are outcome figures, not audit-trail measurements. They show that human review and automation can coexist in financial workflows.
Who is this audit approach not for?
An audit trail for AI-generated code proves process, not correctness, so it is not a substitute for good tests or a certification. A record of unverified work is still unverified, and AI-generated pull requests carried about 1.7× more issues in CodeRabbit's 2025 sample (CodeRabbit, 2025). Teams shipping throwaway prototypes may find the full record too heavy. GC Labs holds no SOC 2, ISO 27001 or HIPAA certification.
The record has clear limits:
It does not make code correct. The trail shows where to look. It does not fix the diff.
It does not replace a standard. The fields above support a SOC 2 change-management review. They do not satisfy one on their own.
It is only as good as capture time. Detecting AI code after the fact is weaker than recording authorship when the agent writes it.
It adds storage and privacy duties. Traces can hold sensitive prompts, so retention and access rules apply.
The tooling is moving. OpenTelemetry's GenAI conventions are still at Development stability (Agentailor, 2026).
Frequently Asked Questions
How to create an audit trail for treasury AI?
Create an audit trail for treasury AI by recording, against each change, the agent, pinned model version, prompt, test results and two distinct humans: a maker and a checker. Add records for money-path tests such as idempotency and reconciliation, keep them tamper-evident, and retain them for the audit period. Public guidance specific to treasury is thin, so treat these as engineering recommendations.
How do I ensure AI agents are fully revoked and logged when an employee leaves?
Give every agent a named human sponsor, then revoke its credentials as part of that sponsor's exit checklist and log each step. Record the agent ID, the credential IDs revoked, the departing sponsor, the time and a verification test. The Cloud Security Alliance reports only 20% of organisations have formal processes for offboarding and revoking API keys (Cloud Security Alliance, 2026).
Donut chart: How fast can teams revoke an AI agent's access? (share of 100 respondents). Highest: Within hours at 44.
A VentureBeat survey of 100 respondents found 14 could revoke an agent's access within minutes and 44 within hours (VentureBeat, 2026). Agent revocation is separate from staff account removal, which the Grail Computer Labs employee offboarding workflow page covers.
What are AI agents and how are they different from earlier automation tools?
AI agents are software systems that use a language model to plan steps and call tools to reach a goal. Earlier automation tools, such as scripts and rule-based workflows, follow fixed paths written in advance. An agent chooses its own steps at run time, which is why its actions need traces and approvals rather than only a script review.
Can the engineer who prompted the agent also approve the merge?
For product code, a team may allow it. For payment, ledger and treasury paths, the engineer who prompted the agent should not be the approver, because the prompter shaped the change and the tests. Require a second reviewer, record both identities on the diff, and block merge if they match.
How can teams add an audit trail for AI-generated code in five stages?
An audit trail for AI-generated code can be added in five stages, starting with the join key. Stack Overflow's 2026 survey found 64% of developers compare AI output with the codebase (Stack Overflow, 2026), and each stage turns one such informal check into a record on the diff. Every stage works alone, and teams can complete the first this week.
Pin model versions and stop using aliases such as "latest".
Add a trace ID trailer to every agent commit.
Store test suite version, results and rejected attempts under the commit SHA.
Record reviewer identity and the SHA approved, and block self-approval on payment and ledger paths.
Give every agent a named sponsor and add agent revocation to the exit checklist.
Conclusion
An audit trail for AI-generated code answers four questions for every diff: what changed, which agent and model made it, which tests accepted it and which human approved it.
Use one join key, such as the commit SHA, across all seven records.
Treat agent traces as a record of what happened, and keep a separate record of who authorised it.
Require a second reviewer on payment and ledger paths.
Read the trail as proof of process, never as proof of correctness.
Teams that want engineers reviewing every change and tests rejecting incomplete work on their own codebase can Book a call ↗.
