The AI Code Audit: Five Questions Your Auditor Will Ask
Auditors ask who approved AI-written code. Learn the five questions they ask and how to answer with a record, not a recollection. Start today.
An auditor doesn't ask whether your scanners are good. She asks who approved the change. Here's how to answer for code an agent wrote, with a record instead of a recollection.
This post is part of our AI Code Governance series. Start with the pillar: AI Code Governance: A 2026 Field Guide.
The auditor picks ten merged changes from last quarter. She chooses the sample herself, so you can't prepare for it. For each change she asks the same thing: who approved this, and where is the record?
For eight of them, the answer is a name and a timestamp. For two, the author field shows an AI agent and the reviewer field is empty. (Ten and two are an illustration, not a statistic.) The room goes quiet. Nobody lied. Nobody wrote it down.
That is not a thought experiment. In a real 52-repo engineering org, the first Provenance connection surfaced 25 AI-authored pull requests merged with zero recorded human review.
What is an AI code audit?
An AI code audit is an auditor, customer or insurer asking you to show how AI-written code was controlled: which changes an AI tool wrote, who reviewed and approved them, and which rules applied.
The request rarely says "AI". It arrives as a SOC 2 evidence list, a customer security questionnaire or a cyber insurance renewal, and the word "AI" shows up in the follow-up question. Auditors, enterprise customers and insurers are all asking, which is why one record has to serve all three.
It is not a code-quality review. It isn't a penetration test. It is a request for evidence about decisions.
Cycode's 2026 survey of more than 400 CISOs found that 100% of enterprises have AI-generated code in production and 81% of security teams can't see it. You can't evidence what you can't see.
Why the usual audit evidence breaks
Audit evidence for software change used to be simple. A person wrote the change, a person reviewed it, and the pull request held both names. The author was accountable by default.
An agent breaks that assumption in three places:
• Authorship. The name on the commit is a tool, or a developer's account that an agent was running under. The record doesn't say which. • Review. A green test run written by the agent itself is not a human decision. A pull request merged without an approval leaves nothing to sample. • Policy. An "AI use policy" states a rule. It doesn't show that anyone followed it on a given change.
Your scanners can't close the gap. They read what the code says, not who decided it could ship. Nobody watches the building.
More findings on top of a missing record give you a longer report and the same silence in the room.
The five questions an auditor will ask
Whatever framework sits behind the request (SOC 2, ISO 27001 or a customer questionnaire), the questions converge:
Which of these changes did AI write? Not "do you use AI tools". Which changes, by name.
Who approved each one? A named human, a timestamp, and a review that happened before the merge.
What could the agent do on its own? The auto-approve switch and the allow-list in the agent's settings file define how much power it was given.
Which rule applied, and was it met? A control, the evidence against it, and an owner for every gap.
Can you show me the same answer tomorrow? Evidence that was sealed when it was gathered, not rebuilt from memory when the request arrives.
If you can answer all five from a system, the audit is a lookup. If you answer them from interviews, it is a negotiation, and the answers shift depending on who you ask.
Evidence is derived, not declared
The tempting shortcut is a questionnaire: ask every team lead whether AI-written changes get reviewed. The answers will be sincere. They will also be declarations, and a declaration is one deposition away from being a liability.
The alternative is to read the facts your estate already emits. "This pull request merged with no recorded reviewer" is an observed fact. "Auto-approve is on in a repository that reaches production" is an observed fact. What can't be observed is marked as a gap for a person to attest, not filled in with a guess.
That is also how evidence maps to the frameworks you answer to. Provenance grades evidence readiness against the EU AI Act and the NIST AI RMF, and its audit exports map to SOC 2 and ISO 27001. It is evidence readiness, not a legal determination. Your counsel and your auditor make the call.
What to do this quarter
Four steps, none of which needs a purchase order or a change to how engineers work:
Draw your own sample. Pull ten merged pull requests from last quarter, chosen at random, before the auditor does. Mark each one: author, reviewer, date.
Count the empty reviewer fields. Filter for changes where an agent is the author or co-author and no human approved before the merge. That number is your starting exposure.
Read the switches. Open each coding agent's settings file in your repositories and note where auto-approve or bypass mode is on.
Write one control and evidence it. "No AI-authored change merges to a sensitive repository without a recorded human approval." Put it in your control matrix as a row that is checked continuously. If your auditor has a framework of their own, ask for it and map the row to it. See how in custom controls.
Do it once, by hand, and you will know within an afternoon whether the answer is a lookup or a negotiation. If the count is zero, you have your evidence. If it isn't, you have a number to put in front of the CISO, with names attached, before anyone outside the company asks for it.
Where Provenance fits
Diwo Provenance is the governance layer above the scanners you already run. It reads signals your estate already emits: merge and review history, and the agents' own settings files. From them it derives which changes AI wrote, who reviewed them and which controls they meet. It turns the result into decisions (fix, waive, accept) with a named owner, and seals the evidence for boards, auditors and insurers. It is not a scanner, and it reads code signals, never your source. A coach, not a blocker.
Seeing your own estate takes about 15 minutes, free and read-only: Connect your estate free at https://provenance.diwo.ai/provenance/signup
The auditor will ask who signed it. Have the record ready before she does.
Related reading
• AI Code Governance: A 2026 Field Guide: the pillar and the full operating model. • Who's Accountable When AI Writes the Code? • Your AI Agent Has Your Production Keys: Here's How to Find Out • What is AI code governance?
Frequently Asked Questions
What do auditors look for in AI-generated code?
Evidence of decisions, not opinions on quality: which changes AI wrote, who approved each one before it merged, what permissions the agent held and which control applied.
Do I need to give a governance tool access to my source code?
No. Provenance reads signals such as commit metadata, review history and agent settings. It is read-only, works retroactively from history already in your repositories and never needs your source.
Will this make us pass the audit?
No tool can promise that. Provenance shows where your evidence is ready and where there are gaps, mapped to the frameworks you answer to. Your auditor and counsel decide.
See it in action Your scanners detect. Provenance decides. Book a working demo →