An audit trail for AI-generated code is what a regulated team reaches for when an auditor asks a simple question that git history cannot answer: who approved this AI-built feature, and against which plan? An AI coding agent will produce a clean, passing pull request whether or not a human ever verified its approach. The commit records who merged the diff, not whether anyone accountable agreed to what the agent decided to build.
For teams operating under SOC 2, ISO 27001, or the EU AI Act, that gap is a control failure, not a paperwork detail. Standard version control proves authorship and timing. It does not prove human oversight of an autonomous system, which is exactly the evidence regulated AI development is now expected to produce.
Key Takeaways
- Git history is not an audit trail: A commit SHA proves who pushed code, not that an accountable human reviewed and approved the agent's plan before it was built.
- Evidence lives at the plan layer: The auditable decision happens when someone signs off on a specification, not when the pull request merges. Capture it there.
- Capture at decision time, not reconstruction: Evidence rebuilt after an audit request is weak and expensive. A durable audit trail for AI-generated code records approvals as they happen.
- Four linked artifacts form the chain: Ticket, approved specification, agent handoff, and resulting commit SHA, bound into one tamper-evident record.
- Frameworks already cover this: SOC 2 change management (CC8.1) and EU AI Act logging duties (Articles 12 and 19) map cleanly onto AI-assisted work once the plan-layer approval exists.
The failure scenario: an audit request git cannot answer
Consider an illustrative scenario common across engineering teams adopting coding agents without governance:
A fintech team ships a feature that recalculates customer interest accruals. A developer handed the ticket to a coding agent, the agent produced a plan, generated roughly 900 lines across 11 files, and opened a pull request. Review looked clean: passing tests, tidy structure. It merged.
Four months later, a SOC 2 Type II auditor samples the change and asks for three things: evidence that a person authorized the approach before code was written, the exact plan they approved, and proof the component was tested against that plan. The team can produce the Jira ticket and the commit, but nothing in between. There is no record of a human approving the agent's design, because that approval never happened as a recorded event.
The code was not defective. The failure was evidentiary. Nobody captured the one artifact an auditor cares about: a named human signing off on the agent's plan, at the moment it mattered, before the agent built anything. Reconstructing that after the fact is both unconvincing and, in a Type II window that examines controls over six months, often impossible.
What is an audit trail for AI-generated code?
An audit trail for AI-generated code is the connected record proving who authorized each AI-built change, what plan they approved, which agent executed it, and which commit resulted. It converts informal agent sessions into compliance evidence, letting regulated teams demonstrate human oversight of autonomous code generation whenever an auditor, or a regulator, asks.
The distinction that matters is where the auditable decision sits. When humans write software, authorization is spread across design docs, tickets, and pull request reviews, and auditors have decades of practice reading it. When an agent resolves hundreds of architectural choices in seconds, the pull request arrives fully formed and the real decision, whether to let the agent proceed on that plan, either happened as a reviewable gate or did not happen at all. An audit trail for AI-assisted development has to anchor to that gate.
Why git history is not compliance evidence
Teams reasonably assume their existing controls already cover this. A protected branch, required reviewers, and a signed commit feel like an audit trail. For human-authored changes they largely are. For AI coding agents they fall short in three specific ways.
First, provenance disappears. Once merged, AI-generated code is indistinguishable from human-written code in the diff. Without a tag applied at the source, there is no way to answer "which components contain AI-generated code" - a question auditors increasingly ask first.
Second, the review target is wrong. A pull request review of a 900-line agent diff tests syntax and style under time pressure. It rarely surfaces whether the agent's underlying approach was ever a good idea, and it produces no record of an architectural decision being approved, only of a diff being merged. This is the same reason reviewing an AI coding agent's plan belongs before the code, not after it.
Third, approvals go stale silently. If the agent discovers an unmapped edge case mid-build and quietly changes course, the earlier human nod no longer describes what shipped. Nothing invalidates it. Preventing that drift is a governance problem in its own right, covered in our guide on keeping specs in sync when agents work the same codebase.
What auditors actually ask for
Across SOC 2, ISO 27001, and the EU AI Act, the specific evidence requests converge on the same elements. The frameworks differ in wording, not in substance.
| Framework | What it requires | Evidence for AI-generated code |
|---|---|---|
| SOC 2 (CC8.1, change management) | Changes to software are authorized, designed, tested, approved, and implemented | A recorded approval of the agent's plan by a named owner, linked to the test results and the resulting commit |
| EU AI Act (Articles 12 and 19) | High-risk systems automatically log events over their lifetime; logs are retained for at least six months | Immutable, retained logs of each plan approval and agent handoff, under the organization's control |
| ISO 27001:2022 (8.32, change management) | Changes to information processing facilities and systems follow a controlled process | A documented approval workflow with evidence that each AI-assisted change passed it |
The AICPA's change-management criterion (CC8.1) asks for changes that are authorized and approved before implementation - the ordinary reading of that control. The EU AI Act's record-keeping duty requires high-risk systems to log events automatically across their lifetime, and its log-retention rule sets a six-month floor, longer where sector rules such as financial-services record-keeping apply. None of these were written for coding agents, but all of them land on the same missing artifact: a durable record that a human approved the plan.
The four-layer evidence chain
A workable audit trail binds four artifacts into one record. Each layer answers a question the one before it cannot.
Workflow summary: An audit trail for AI-generated code links the originating ticket to an approved specification with a named sign-off, to the frozen plan handed to the coding agent over MCP, to the resulting commit SHA, all recorded in an immutable, retained audit log.
- Ticket establishes business intent and the person who requested the work.
- Approved specification is the load-bearing layer. It captures the exact plan a named owner signed off on, in text, before any code existed. This is the artifact auditors ask for and the one most teams lack. Formalizing who signs off on what is the subject of our spec approval workflow guide.
- Agent handoff records that the frozen, approved plan - not an ad-hoc prompt - was the boundary the agent executed within. Serving the approved spec over the Model Context Protocol (MCP), an open standard for feeding structured context to coding agents, makes the handoff itself a logged event.
- Commit SHA ties the shipped change back to the approved plan, closing the loop from intent to implementation.
Capture at decision time, not after the auditor calls
The single most common reason an audit trail fails is that it was reconstructed. When the evidence request arrives, the team reverse-engineers approvals from Slack threads and memory. Auditors have learned to distinguish manufactured evidence from contemporaneous records, and reconstructed trails invite deeper scrutiny rather than closing the finding.
Evidence is only trustworthy when it is recorded as the decision happens. That means the approval gate has to be part of the workflow, not a report generated afterward. Three properties make a decision-time record durable:
- Attributable identity. Each approval is tied to a named person, not a shared service account. A single agent identity used by the whole team makes the trail unreviewable - the auditor cannot tell who agreed to what.
- Version locking. Once a plan is approved, editing it invalidates the approval automatically, mirroring how GitHub dismisses stale pull request approvals when new commits are pushed. An approval that no longer matches what shipped is worse than none.
- Immutable retention. Records are written to tamper-evident storage and kept for the required window - six months under the EU AI Act, frequently longer for financial-services teams. For the enterprise and CISO view of this, see our enterprise AI SDLC playbook.
Common failure modes and how to close them
| Symptom | Root cause | Mitigation |
|---|---|---|
| Auditor rejects the evidence as reconstructed | Approvals rebuilt from memory after the request | Capture sign-offs as events at the moment of approval, not in a post-hoc report |
| "Who approved this?" is unanswerable | Agent runs under a shared service account | Record approvals and agent actions against named, per-person identities |
| AI-generated code cannot be located | No provenance tag applied at the source | Tag AI-assisted changes at the spec layer so provenance survives into the commit |
| Approval no longer matches what shipped | Plan changed after sign-off, with no re-approval | Version-lock the approved spec so any edit invalidates the prior approval |
The AI code audit evidence checklist
Before an AI coding agent ships to a regulated production codebase, confirm each item produces a durable, contemporaneous record:
- Provenance tagging: Every AI-assisted change is marked as such, so you can answer which components contain AI-generated code.
- Named approver: A specific person, not a shared account, is recorded as approving the agent's plan.
- Reviewed artifact captured: The exact specification text that was approved is stored, not just a link that may later change.
- Decision-time capture: The approval is recorded when it happens, not reconstructed on request.
- Version lock: Editing the approved plan invalidates the approval and requires re-sign-off.
- End-to-end linkage: Ticket, approved spec, approver identity, and commit SHA are bound into one chain.
- Tamper-evident retention: Logs are immutable and retained for at least the regulatory window that applies to your sector.
- Test evidence tied to the plan: Test results are linked to the AI-built component and the plan it was built against.
Teams can estimate what unaddressed rework and failed-audit remediation cost them today using our rework ROI calculator. The evidence discipline above is cheaper than the findings it prevents.
Where the audit trail comes from
The recurring theme is that compliance evidence for AI coding agents is a byproduct of a governed planning layer, not a logging tool bolted on afterward. If the approval gate exists as a real step in the workflow - a named owner signing off on a frozen specification before the agent builds - the audit trail writes itself: the ticket, the approved plan, the handoff, and the commit are already linked, already attributed, and already timestamped. If that gate does not exist, no amount of post-hoc log aggregation reconstructs the human decision an auditor is actually asking about. Regulated AI development is less about recording what agents did and more about proving what humans approved.
See audit-ready approval built into the plan
Bring a real spec and a compliance requirement. We will show how Enact gates the plan, records who approved it, and links it to the commit.
Book a call →