Every audit I’ve ever sat through eventually arrives at the same question: “Show me the code that produced this number.”
At a bank, that question has a well-worn answer. There’s a release record, a change ticket, a tag in source control. Somebody pulls up the commit and the room moves on. Boring, effective, and paid for with decades of incidents.
Now try asking it about code an agent wrote.
Where agent code actually lives
Most AI-generated code is actually fine on this score. When a developer writes code with an assistant in their IDE, the output is committed to a repo, gets a pull request, gets reviewed. Same pipeline as always; the author just got faster.
The problem is code generated inside a platform — a workflow tool lets an agent write a transformation, or a data platform generates a validation script from a plain-English rule. That code never passes through anyone’s IDE, so it gets stored wherever the platform stores everything else: a TEXT column called something like script_body, a JSON config blob, an object store bucket with a UUID for a name. In the worst case it lives nowhere at all — generated at run time, executed, discarded.
I understand how this happens because I’ve made the same decision. The database is right there, serialization is one line, ship it. But look at what you’ve stored: executable code, written by a probabilistic system, running against production data, sitting in a column with no history. Someone edits the script and the previous version is gone. If last Tuesday’s run produced a number that this Tuesday’s run doesn’t, you can’t diff the two scripts, because one of them no longer exists.
Nobody would accept this for human-written code. We stopped accepting it somewhere around 1995.
We already solved this problem
The temptation, and I’ve watched vendors give in to it, is to build something new: an “AI code registry,” a provenance layer, some governance product with its own dashboard and login. You don’t need any of it. The tool that solves this problem is thirty years old, every engineer on your team already knows it, and your auditors already accept it as evidence. It’s git.
State what git gives you in audit terms and it reads like a compliance wish list: immutable history, attribution on every change, diffs between any two versions in seconds, and a permanent name — the SHA — for every version of every file. That last one matters most. “The script that ran on Tuesday” is a claim; “commit a3f19c2 ran on Tuesday” is a checkable statement about exactly which bytes executed. When the auditor asks, that’s the difference between an answer and a shrug.
There’s an irony in here that I enjoy. Version control was built for humans, and humans are mediocre at it — we write “fix stuff” and “wip” and push on Friday at 5. An agent doesn’t get tired. Wire its output through git and you get one commit per change, every change, forever. And once agent code lives in a repo, the review machinery your organization already has — pull requests, protected branches, required reviewers, CI — applies to it for free.
The reviewed thing must be the running thing
One trap left. Getting the code into git is necessary but not sufficient. Most platforms execute whatever is at the head of main, and with branch protection that’s defensible — everything on main was reviewed. But the branch can still move between the review and the run, whether by a well-meaning colleague, another agent, or someone with stolen credentials, and after the fact you can’t prove which commit a given run actually used.
The fix is to pin. Every run executes a specific commit’s bytes and no others, so a moving branch can’t touch a run even in principle. And the pin never comes from resolving a branch at run start — that would just faithfully record that you ran the wrong thing. It moves only through a recorded step: a save inside the platform, or an explicit adoption of a change that arrived from outside, a pull request into main included. Now the audit trail closes into a loop: this run executed this SHA, and the pin advanced to that SHA through this save or this approved merge, by this person. Drift detection comes almost free too: if the branch has moved past the pin, the platform flags it, and taking the change is a recorded decision instead of a silent one.
The bar shouldn’t move because the author did
None of this is exotic, which is really the point. The provenance problem for agent-written code feels new, but the requirements — history, attribution, review, proof of what ran — are the ones we’ve had for human code all along. They didn’t change when the author did. If anything they got stricter, because agents write more code faster than any human team ever managed.
This is the road we went down with Datris recently: agent-generated pipeline scripts in the customer’s own GitHub, one commit per change, every run pinned to the exact commit it executed and immune to drift, external edits flagged for explicit adoption. But the argument doesn’t depend on any one product. Go look at where agent-written code lives in your shop. If the answer is a database column, you already know how the auditor’s question is going to feel.
Todd Fearn is the founder of Datris.ai, an open-source, agent-native data platform built on the Model Context Protocol, and he runs IData Corporation, a data engineering consultancy for financial services firms. He has spent about thirty years building production data infrastructure inside institutions like Goldman Sachs, Bridgewater Associates, Deutsche Bank, and Freddie Mac.