What auditors will start asking about AI-written code
The questions are not new. What is new is that the answers your change-management process has given for a decade quietly stopped being true, and nobody has told the auditor yet.
Two people from an external firm sit at one end of a long table. One of them has a laptop and a spreadsheet of controls. The other has a notebook and asks most of the questions. They have four hours and they will spend the first thirty minutes on something that sounds like small talk and is not.
“Walk me through how a change gets from someone having an idea to running in production.”
An engineering manager does this from memory, and it is a good answer. Ticket, branch, pull request, review, CI, approval, merge, deploy pipeline, release ticket. The auditor writes it down. Then she picks four changes from the last quarter, apparently at random, and asks to see each one follow that path.
Three of the four do. The fourth is a pull request with eighty-two files, authored by something called svc-agent-prod, approved in four minutes, with a description that reads “as per spec”. The auditor does not react. She writes it down and asks a question that the room has never had to answer before: “Who reviewed this, and what does reviewing eighty-two files in four minutes mean?”
That question is the whole subject of this piece.
The controls did not change. The facts did.
Here is what I want to establish before anything else, because it reframes the entire conversation and teams keep getting it backwards.
Auditors are not going to invent a new category of AI controls and spring it on you. Almost every question that is coming is a question they already ask, applied to a set of facts that has changed underneath the existing answer. Change management, access management, segregation of duties, evidence of review, completeness of populations: these are the same headings they have used for twenty years.
What has changed is that a handful of assumptions those controls quietly relied on are no longer true:
- that the person named on a change understood it
- that review time is a proxy for review depth
- that the number of changes in a period is small enough to sample meaningfully
- that a change has one author with one intent
- that access is held by people, so managing people manages access
Every awkward question in the next few years is downstream of one of those five. If you want to prepare, do not go looking for an AI audit checklist. Go and check which of your existing control descriptions depend on an assumption that has stopped holding, and rewrite them before somebody else notices.
What the control narrative says
- "All changes are peer reviewed before merge"
- "Developers cannot deploy to production"
- "Access is granted to named individuals"
- "Changes are traceable to an approved ticket"
- "We sample five changes per quarter"
What the auditor now has to ask
- Reviewed by whom, against what, in how long
- Can an agent running as a service deploy
- Who holds the service credentials, and their scope
- Traceable to a ticket saying what, exactly
- Five out of how many, and how were they picked
The eight questions
Here is my working list. It comes from watching this conversation happen, not from any published standard, and I would expect it to be wrong at the edges. It has been directionally right so far.
1. Who or what authored this change, and is that distinguishable in your records?
The first thing an auditor wants is to be able to separate human-authored from agent-authored changes in the population, because those may need different testing. If your commits all come from one shared service identity, or worse, from a human’s account with an agent using their token, you cannot make that split, and the inability to make it is itself a finding. Distinguishability is cheap to build and expensive to retrofit.
2. What did the reviewer review?
This is the four-minute question. Nobody is going to claim review is meaningless, but “a human clicked approve” is now a much weaker statement than it was, because the volume and size of changes have moved. The strongest answers I have seen do not defend the depth of human reading. They shift the claim: the change was gated on criteria that were mechanically checked, the reviewer’s job was to judge the residue, and here is the record of both parts. That is a defensible control. “Our engineers are diligent” is not, and never really was.
3. What was it checked against, and was that written down before or after?
Acceptance criteria written after the code exists are documentation of the code, not a control over it. Auditors are alert to this pattern in every domain and will be here. Timestamps on your criteria matter more than their prose quality.
4. Could this change have gone to production without passing the gates?
The bypass question. Every pipeline has a break-glass path, and having one is fine. Not being able to enumerate its uses is not. Expect to be asked how many times the gate was overridden in the period, by whom, and what the follow-up was. Teams that can answer with a number are in good shape. Teams that answer “it basically never happens” get a sampling exercise instead.
5. What is the complete population of automated changes?
Sampling requires a population. If agents can act through several paths, some of them instrumented and some not, your population is a subset of unknown size and every conclusion drawn from a sample of it is unsound. This is the single most technically demanding question on the list, and the one where I see the most hand-waving.
6. What permissions do your agents hold, and who reviews them?
Access reviews were built for people. They have joiner, mover, leaver processes and quarterly recertification with a manager attesting that Priya still needs access to the payments console. Non-human identities usually skipped that process entirely because they were rare and boring. They are neither now. Expect questions about who owns each service identity, what scope it holds, when it was last reviewed, and how it gets revoked.
7. Is segregation of duties preserved?
The classic control says the person who writes a change cannot be the person who approves it and deploys it. Now consider a pipeline where an agent writes the change, a second agent reviews it, and the merge triggers an automatic deploy. Formally there are three actors. Substantively there may be one system, configured by one person, with one set of credentials. Auditors will look through the formal separation to the effective one, and the honest answer is usually that a human somewhere has to hold a distinct role that the automation cannot assume.
8. If this change was wrong, how would you know, and how fast could you undo it?
Detection and reversibility. Increasingly asked together, and reasonably so, because the speed of change has made “we would catch it in the next release cycle” an inadequate answer.
The answer that works, and the three that do not
Three answers I have watched fail in the room.
“Agents are just tools, like a compiler.” This sounds principled and it collapses under one follow-up: does your compiler choose which files to change and open a pull request describing its own intent. The tool framing is doing work it cannot support. Drop it.
“A human approved every change.” True and hollow, for the reasons above. Worse, it invites the four-minute question, and once that question has been asked your strongest available answer has already been spent.
“We have an audit log.” Volume without structure. An auditor does not want a log, they want to test a control. A log is evidence in support of a control’s operation. If you cannot say what the control is, the log is just a very long file.
The answer that works has a particular shape, and it is worth stating explicitly because it is not obvious:
The control is not that a human read the change. The control is that the change could not merge unless a written, pre-existing definition of done was satisfied, that satisfaction was evaluated mechanically where possible, the residue was judged by a person holding an appropriate role, every step produced a record, and the population of such records is complete by construction.
That is a control an auditor can test. They can ask for the definition of done, check it predates the change, ask what happens when it fails, force a failure in a test environment, sample the records, and reconcile the population. Every one of those is a thing they know how to do. You have given them a job rather than an argument.
The subtext, and it is worth being direct about it, is that human review has quietly stopped being the primary control over correctness and become a secondary control over judgement. Most control narratives have not caught up with that, and rewriting yours before an auditor rewrites it for you is a couple of days of work with a very good return.
What to do in the next quarter
Concretely, in rough order of value:
Make agent-authored changes identifiable in your source control history, with a distinct identity per agent rather than one shared account.
Write down what your gates actually are, in the order they run, and what happens when each fails. Most teams discover during this exercise that at least one gate is advisory and everyone believed it was blocking.
Count your overrides. Just count them. The number is usually not zero and is usually much smaller than people fear, which makes it a good number to have.
Put non-human identities into your access review. Give each one a named human owner. Ownerless service credentials are the most reliable finding in this entire area.
Timestamp your acceptance criteria and keep the history. If criteria are edited after work starts, that should be visible rather than silently overwritten.
None of that requires a purchase. It is mostly housekeeping, and it is the housekeeping that determines whether the four-hour meeting is uncomfortable or routine.
Where this breaks down
I should be careful about how confidently I am predicting other people’s behaviour.
The honest position is that audit practice around agent-authored code is genuinely unsettled. Different firms are landing in different places, sector expectations vary, and the same organisation can get two different sets of questions from two different reviewers a year apart. Treat the list above as a well-informed guess about direction, not as a checklist you can complete and be finished with. Anyone offering you a definitive list of what auditors will require is telling you something they cannot know, and that includes me.
The second limit is that preparing for audit questions is not the same as being safe. It is entirely possible to build a control environment that tests beautifully and produces bad software, and there is a real failure mode where teams optimise for evidence and let judgement atrophy because judgement is not what gets sampled. The controls are a floor, not a goal.
Third, the advice to make everything mechanically gated has a cost that falls unevenly. Work that decomposes into checkable criteria gets easier to ship. Exploratory work, refactoring, and anything where the value is learning rather than delivery gets harder, because it fails a gate designed for a different kind of change. If you are not careful you will build an environment that is excellent at governing routine work and quietly hostile to everything else, and nobody will notice for a year.
Fourth, small teams. Segregation of duties is close to impossible with four engineers, and the standard mitigations (compensating controls, detective rather than preventive measures, external review) are more expensive per head than they are at scale. If you are small and regulated, most of this article is aspirational, and the pragmatic move is to be explicit about what you cannot separate and strong about what you detect after the fact.
Finally, and this matters legally: nothing here describes what any specific framework requires, and no tool, ours included, makes an organisation compliant. Compliance is a programme with owners, scope, testing and remediation. Software can produce evidence that a programme relies on. That is a genuinely useful thing and a much smaller thing than the word compliant.
The takeaway
The questions coming at you about AI-written code are your existing change-management questions applied to facts that changed. Author identity, what review actually consisted of, whether criteria predate the code, whether gates can be bypassed and how often, whether your population is complete, who owns your non-human identities, whether duties are effectively separated, and how fast you could undo a bad change.
Rewrite the control narrative before someone rewrites it for you. Move the claim from “a person read it” to “it could not pass without satisfying something written down first, and here is the record”.
The next piece steps back from evidence to prevention, and argues that reviewing the diff has become the wrong place to look for the risks that matter most, because the expensive mistakes are now being made a level up, in the design.