How to Govern AI-Written Code Without Buying Another Scanner
You already run 4–8 scanners and carry 50,000 open findings. Governance isn't more detection — it's the decision layer above the detection you already own. A practical operating model.

Somewhere in your security stack right now: GitHub Advanced Security, Dependabot, maybe Snyk, maybe Wiz, maybe GitGuardian. Four to eight scanners is normal for an enterprise estate. So is what they produce together — tens of thousands of open findings, each one screaming at the same volume, with no owner and no order.
And yet when the board asks its new favorite question — "AI is writing our code now. Is that governed?" — none of those tools can answer it. Not because they're bad tools. Because it isn't a detection question.
The reflex, when a new risk shows up, is to buy a new scanner for it. This is the case for not doing that.
A smoke detector tells you about one room
Every scanner you own watches one room of the building. Code scanning watches source patterns. Secret scanning watches credentials. Dependency scanning watches your supply chain. Each does its job well — and each raises its alarm independently, in its own console, in its own severity language.
Nobody watches the building.
That's why 50,000 findings coexist with real uncertainty. The problem was never too little detection. It's that detection output never becomes a small number of owned decisions about the places that can actually hurt you. Adding a ninth smoke detector doesn't fix that. It adds a ninth alarm.
What AI-written code changed
Coding assistants and agents didn't just add volume — they added a new class of question that no scanner is built to see:
• Which of these changes did AI write?
• Did a human actually review them before they merged?
• Is AI-written, unreviewed code sitting in payment-critical systems?
These are provenance questions — chain-of-custody questions about how the software came to be. A scanner examines what the code says. Provenance examines what the history shows: authorship, review, merge paths, the evidence around every change. When one real estate was first examined this way, the week-one finding wasn't a vulnerability — it was 25 AI-authored pull requests merged with zero human reviews. No scanner had flagged it, because nothing was "wrong" with the code. Something was wrong with the custody.
The operating model: govern above your scanners
Here's the how-to. None of it requires ripping anything out — your scanners are the sensors in this model, and they stay.
1. Keep every scanner you own. Their findings are the raw evidence. The waste isn't in the tools; it's in treating each tool's queue as its own to-do list.
2. Correlate into one picture, weighted by what the code does. A secret finding, a code finding, and a dependency finding on the same payment service are not three items — they're one hotspot. Classify your repositories by business criticality (internal → public-facing → customer-data → regulated → payment-critical) and let that weighting, not raw severity counts, set the order. Fifty thousand findings usually collapse into a handful of hotspots that matter this week.
3. Derive provenance from the evidence — never from a survey. Who wrote each change, whether a human reviewed it, and where AI-authored code concentrates can be read from the estate's own history. Derived posture survives an audit. Declared posture — the annual questionnaire — is one hard question away from being a liability.
4. Decide, on the record. For each hotspot: fix, waive, or accept — with a named owner, a rationale, an SLA, and the evidence snapshotted at the moment of decision. This is the step that turns security work into governance. Findings are what happened to you; decisions are what you did about it, and decisions are what boards, auditors, and insurers actually evaluate.
5. Report upward in one number. Executives don't consume finding counts. Give them a single, defensible posture score for the estate, its trend, and the shortlist of what's unwatched in critical places. When the number moves, the reason is a decision on the record — which means the story is always tellable.
The litmus test
You're governing — not just detecting — when you can answer, from evidence, in minutes:
1. Which of our code did AI write?
2. Was a human in the loop when it merged?
3. Which findings matter this week, and who owns each decision?
4. Can we show a regulator, auditor, or insurer the record?
If any of those takes a meeting to answer, the gap isn't detection. It's the layer above it.
Where Provenance fits
Diwo Provenance is that layer — AI code governance, above all your scanners. It consumes what your scanners already find, derives provenance from your estate's own history, weights everything by business criticality, records every decision with its evidence frozen, and keeps a board-grade score current continuously. It is not a scanner — never will be — and it reads code signals, never your source: your code never leaves your estate.
Seeing your own estate through this lens takes about 15 minutes with a free, read-only connection: Connect your estate free — your score, your blind spots, and the questions you can't currently answer, from your own evidence.
The scanners were never the problem. The missing layer was.
Your scanners detect. Provenance decides.
