Free Guide · 18 Pages · 2026 EditionA Guide to AI Code Governance in the Agentic Era.
Why detecting AI-written code stops short of governing it — and what a provable accountability layer actually does. The four jobs (attribute, classify, decide, prove), the code + agent surfaces, and what the board, CISO, and engineering each get.
Scanner finding → AI-authorship signal → Provable evidence pack
Detection was never the real problem.
For thirty years, software security has been a detection industry. Find the vulnerability. Flag the secret. Scan the dependency. The better the scanner, the safer you were supposed to be.
The tooling got very good. And it answered a question that is no longer the one the board is asking.
AI now writes a large and growing share of the code shipping to production. The question a scanner answers — “is there a bug in this line?”— still matters. But it sits underneath a bigger one that no scanner was built to answer:
Whodecided to ship AI-written code into a system that matters — and can you prove a human was in the loop?
That’s not a detection question. It’s an accountability question. And it’s the one an auditor, a regulator, and your own board will ask first.
A scanner can tell you a finding exists. It cannot tell you who owns the decision to accept it, when they made it, on what evidence, or produce that record months later when someone asks. That record — not the finding — is what governance is.
The scan-and-move-on trap
The classic AppSec promise is coverage: point the scanner at the repo, get a list of findings. But a finding is an input, not an outcome. Whether to ship the AI-written change to a payment service this week, hold it, or require a second reviewer — that’s the decision. The scan informs it. It doesn’t make it, own it, or record it.
The evidence you can’t reconstruct
Six months later, an auditor asks a simple question: “This AI-generated change to a Tier-1 system — who reviewed it, and what did they decide?” In most organizations the honest answer is a search through pull-request comments, a Slack thread, and someone’s memory. The decision happened. The record of it didn’t — not in a form anyone can produce on demand.
Governance-in-spreadsheets
So teams reach for the same tool they always do: a spreadsheet. A tab of repos, a column of owners, a column of “reviewed? y/n”, updated by hand, stale by Friday. The real work lives in an .xlsx file that nobody else can see — except here the stakes are regulatory.
Three things changed in the last 18 months.
The “AI writes code now” story is real, but it has threeparts — and the third is where governance pulls ahead of detection.
01AI became the majority author.
Copilots and coding agents moved from novelty to default. Gartner projects that 75% of enterprise software engineers will use AI code assistants by 2028, up from under 10% in 2023. And the code itself is increasingly AI-written — a quarter to a third of new code at Microsoft and Google now is.
02Governance frameworks became the yardstick.
Enterprises are increasingly measured against a common set of AI-governance frameworks — the EU AI Act, NIST’s AI Risk Management Framework, ISO/IEC 42001. We won’t parse the fine print here. The through-line across all of them is simple and universal: be able to show your work — which system did what, who was accountable, and the evidence behind the decision. Detection produces none of that on its own.
03The frontier labs started watermarking their own output.
The AI vendors began marking what their models produce — an admission, from the source, that attribution matters. But watermarks stop at words and images. Enterprises don’t ship words. They ship code, and the agents that run it. That is the gap watermarking leaves wide open — and it is exactly the surface Provenance governs.
The first two shifts get you to detectAI’s work. The third is a signal that detection isn’t enough — the market is reaching for accountability. That’s the loop detection never had.
The four jobs of an AI-code governance layer.
A governance layer — versus a scanner, versus an AI-code detector, versus a spreadsheet — does four things, in sequence, on a loop.
Fig 1.1 — Every provable claim runs through the shared record of the estate and its accumulated decisions.
01Attribute — which code did AI write
Not a guess. Tie the change to its origin: the commit, the pull request, the authorship signal. AI:TRUE is a fact about the artifact — derived, not declared.
02Classify — by what the code governs
A vulnerability in a payment system and the same vulnerability in a throwaway prototype are not the same risk. Classification maps each repository to its business-criticality, so governance can be proportional— strict where it matters, light where it doesn’t.
03Decide — and record the judgment
When AI-written code meets a system that matters, a human decides: ship, hold, require another reviewer. Governance’s job is to capture that decision — who, when, on what evidence — as a first-class record, not a comment that scrolls away.
04Prove — freeze the evidence
Turn the identity, the decision, and the context into a board-ready evidence pack — a downloadable briefing, mapped to the frameworks (EU AI Act · NIST AI RMF · ISO 42001), reproducible on demand. That pack — not the finding — is the deliverable.
What “layer” actually means here
You can approximate any one of those four jobs with a point tool. A scanner attributes (loosely). A detector flags AI authorship (sometimes). A ticket system records a decision (if someone remembers to write it). A framework PDF maps to the regulation (statically). None of them close the loop, because closing it requires all four jobs to share one record of the estate — the same repositories, the same criticality definitions, the same decisions, the same evidence.
That shared record is the layer. The four jobs are surfaces on top of it. And crucially, the layer sits abovethe security tools you already run — it doesn’t replace your scanners, it makes their signal accountable.
| Capability | Code scanner GHAS · Snyk · ADO | AI-code detector Watermarks / classifiers | Governance layer Diwo Provenance |
|---|---|---|---|
| Attribute AI authorship | Out of scope | Words / code | Commit → PR → AI:TRUE |
| Business-criticality classify | Out of scope | Out of scope | Per-repo, drives treatment |
| Recorded human decision | Out of scope | Out of scope | Who / when / why, first-class |
| Provable, framework-mapped evidence | Finding list only | Out of scope | Frozen board briefing |
| Governs agent runtime behavior | Out of scope | Out of scope | Signal + boundary guard |
| Compounding institutional judgment | No | No | Every decision sharpens the next |
Classification is the leverage point.
Here’s the part that matters most, and it’s less glamorous than the “detect AI code” headlines suggest.
The single biggest determinant of whether governance is useful— versus noise — isn’t the detector, the model, or the framework mapping. It’s whether the layer knows what each repository actually is.
Treat every repo the same and you get one of two failures: you govern the scratch repo as strictly as the payment system (and teams route around you), or you govern the payment system as loosely as the scratch repo (and the one that mattered slips through). Proportional governance is the whole game, and proportion comes from classification.
This is why the class isn’t a label — it’s the input to the policy. A payment-critical or AI-agent repository automatically earns stricter treatment and the right governance mapping. A prototype earns a light touch. Same layer, different rigor, because the layer knows the difference.
Get the estate right first
Before any of the four jobs pays off, the estate has to be real:
- Every repository accounted for— and honest about what isn’t covered (coverage honesty, below).
- Criticality assigned— which systems are Tier-1, which are experiments.
- Ownership known— who decides for each business unit.
Mislabeling a repository’s criticality is itself a risk. The class doesn’t describe the repo — it governs it.
The honesty that builds trust: coverage
A governance layer that overstates its reach is worse than none — it manufactures false confidence. So the layer has to be honest about its own blind spots.
Provenance reports coverage the boring, defensible way: “code-scanning coverage — X of Y repositories · Z blind spots,” with dependency coverage reported separately, because they are different guarantees. The score reflects what is actually analyzed, not the whole estate wearing a green badge.
This sounds like a limitation. It is the opposite — it is the thing that lets a CISO put the number in front of an auditor without flinching.
The next wave: auto-classification
Today, classification is assisted— you confirm what each repository is. On purpose: mislabeling criticality is a risk, so a human confirms. The next wave, already in design, reads your READMEs, dependency manifests, code ownership, and repository metadata to auto-classifyevery repo, confidence-banded — auto-apply what it’s certain of, surface the rest for one-click confirm. Auto-classify → auto-govern → auto-evidence.
Fig 1.2 — Provenance sits aboveyour scanners — not beside them.
Code at build time, agents at runtime.
Governing AI-written code is half the problem. The other half is governing what AI does once it runs— the agents now taking actions in production.
Fig 1.3 — Same governance layer, both ends of the spectrum. Defined once. Consumed by both.
Most enterprises will need both, because they are the same accountability question asked at two moments: did AI act inside its bounds, and can you prove it?
Governs the code AI writes — attribution, criticality, the recorded decision to ship, the frozen evidence.
Governs the agents AI runs — a behavior signal when an agent acts, a deterministic boundary guard when it steps out of line, and the same kind of recorded, provable event.
Defined once, consumed by both. That isn’t a feature — it’s the architecture. Two halves that share one record behave coherently. Two that don’t, drift.
Attribution is only half of it
Attribution tells you AI wrote it. Governance is what happens next: a human decides, and the decision becomes a record.
When AI-written code lands on a system that matters, the owner decides — ship, hold, require review — and Provenance captures who decided, when, and on what evidence. The decision is first-class: it stands even against a later automated “recovery,” because a recorded human judgment is exactly what a regulator is asking for.
Then it freezes the proof.
What a frozen evidence pack looks like
The real artifact is a board-addressed briefing, headed “TO THE BOARD OF DIRECTORS · FROM PROVENANCE, AI RISK OFFICER · CONFIDENTIAL · Generated <timestamp>,” downloadable as PDF, with the executive summary, the Standing decisions (who / when / why), and the framework map (EU AI Act · NIST · ISO 42001) footnoted with “evidence readiness, not a legal determination.”
The key feature is that the evidence is frozen and reproducible— a point-in-time, downloadable record that says the same thing in six months as it does today. A recommendation without evidence is a guess. A decision without a frozen record is a memory. Provenance produces the thing you can put in front of an auditor.
A spreadsheet isn’t evidence. This is a versioned system of record — provable, not plausible.
Provenance governs Provenance.
The hardest test of a governance claim is whether the vendor lives by it. We do — in production.
Provenance’s own AI is governed by the same loop it sells. Ask its assistant to do something out of bounds — leak a secret, step outside its role — and a deterministic boundary guard blocks it every time (no model, no probability) and records it as a governed behavior signal: metadata only, never the secret itself. That signal flows into the same observability stack an enterprise already runs (Datadog), where a monitor fires the moment an AI steps out of line. The blocked event becomes an evidence pack, mapped to the same governance frameworks.
This is the difference between a governance pitch and a governance practice. Most tools in this space govern your systems and exempt themselves. Provenance eats its own dog food, on production, and the evidence is the same shape we’d hand you.
If a governance layer won’t govern itself, ask why.
What this means for the board and the CISO.
The shift to AI-written software isn’t a rip-and-replace of your security stack. It’s a new layer of accountability on top of it— and the leaders who stand it up now have a real head start.
What the board gets
An answer to the question it will be asked — by an auditor, a regulator, a customer’s security team: which of our code did AI write, was a human in the loop, and can we prove it? Not a dashboard of bugs. A provable record, framework-mapped, on demand.
What the CISO gets
A governance layer that rides the existing signal (GHAS, ADO, Datadog) instead of replacing it — no rip-out, no new scanner to run — and turns that signal into something accountable. Coverage stated honestly enough to defend. Evidence frozen enough to hand over. A posture number that means something because it’s scoped to what’s actually analyzed.
What engineering keeps
Velocity. Proportional governance means the scratch repos stay light and only the systems that matter earn the friction — so the accountability layer doesn’t become the thing developers route around.
Stop trying to scan your way to confidence. Build the accountabilitylayer that turns every scanner’s signal into a record you can defend.
What it takes to begin.
The bar to start is deliberately low, and the architecture is built for enterprise reality.
One repository, read-only
A code repository. GitHub installs read-only in about ten minutes; Azure DevOps connects with even less. That alone lights the core loop — attribution, classification, the decision queue, and the point-in-time evidence pack. The runtime/agent-behavior layer is an optional add that rides your existing observability. Read-only, metadata-only, no rip-out.
Container-first, so nothing leaves your boundary
Every external dependency an enterprise takes on is a liability to approve. Provenance is built container-first: the whole product can run self-contained inside your own boundary(BYOC) — code and data never leave. Fewer approvals, faster go-live, and a governance tool that doesn’t itself become an exfiltration path. (A blocked “leak the DB password” request stores that it was blocked — never the secret.)
Built for the estate, not the demo
Multi-account estates, business-unit scoping, per-role visibility, honest coverage. Governance that only works on a five-repo demo isn’t governance — so Provenance runs today across real estates of dozens of repositories spanning multiple accounts and business units, with enterprise-scale coverage (into the thousands) as the active engineering focus.
Five changes, written down.
The governance equivalent of a self-audit is sharp, because a regulator may one day ask you to produce it.
Pick the five most consequential AI-written changes that shipped to your critical systems this quarter. For each one, answer, on the record:
01Attribution
Can you show AI wrote it (commit → PR → AI:TRUE), not just assert it?
02Criticality
Was the system’s business-criticality classified before the change, so governance was proportional?
03Decision
Who decided to ship it, when, and on what evidence?
04Proof
Can you produce a frozen, framework-mapped evidence pack for it in under a minute?
05Runtime
If that change put an agent into production, can you prove it acted within its bounds?
If you can answer all five for all five, you have a governance practice. If you can’t, you don’t have a scanning problem — you have an accountabilityproblem. That document — five changes, fully specified — is the input to a governance layer. Fix the accountability gap first; the tooling follows.
The absence of a record is not a small gap. To a regulator, it is the finding.
The promise, finally provable.
AI was supposed to make software teams faster. It did. But speed without accountability is just risk arriving sooner.
Every previous security “revolution” was about finding more, faster — more findings, more scanners, more coverage. This moment is different, because the thing that changed isn’t the volume of what to detect. It’s who wrote it and whether anyone can prove a human stood behind the decision to ship it.
Detection tells you something happened. Governance tells you it was owned— attributed, classified, decided, and proved. And because every decision sharpens the next, the record compounds into something a scanner never produces: institutional judgment you can defend.
Fig 1.4 — Each decision sharpens the next. The record compounds.
That’s the original promise of trustworthy software — not “we scanned it,” but “we can prove who was accountable.”The technology to do it at the speed AI now ships code wasn’t ready. Now it is.
The question for the board isn’t whether AI will write your software. It already does. It’s whether you can prove it was governed when someone asks.
The scanner was always a means to an end. The end was always a defensible decision.
See what a governance layer for AI-written code actually does.
Connect one repository, read-only, and watch Provenance attribute, classify, and produce a provable evidence pack — on your own estate, in about ten minutes.
Or read the companion guide at /research/agentic-era-guide
The questions readers ask.
What is AI code governance?
AI code governance is the practice of turning AI-written code from a scanner finding into an accountable record: which code AI wrote, how critical the system is, who decided to ship it, and provable, framework-mapped evidence of the decision. A scanner tells you a vulnerability exists. A governance layer tells you who owned the decision to accept it, when, and on what evidence — the record a regulator or an auditor is actually asking for.
How is a governance layer different from an AI-code detector or watermark?
Detectors and watermarks answer 'did AI write this?' — a signal, not a decision. A governance layer sits above your scanners and detectors and does four things: attributes AI authorship, classifies each repository by business-criticality, captures the human decision (who / when / why) as a first-class record, and freezes the evidence into a downloadable, framework-mapped briefing. The detector is an input; the governance layer is the loop that produces something you can put in front of an auditor.
Which regulatory frameworks does an AI code governance layer map to?
Provenance maps its evidence to the widely referenced AI-governance frameworks — the EU AI Act, NIST AI Risk Management Framework, and ISO/IEC 42001. This is evidence readiness, not a legal determination: the layer produces the record the frameworks all converge on — show your work: which system did what, who was accountable, and the evidence behind the decision.
Does a governance layer replace my code scanners?
No. Provenance sits above your scanners (GitHub Advanced Security, Snyk, Azure DevOps) and observability tools — it doesn't replace them. Your existing security signal is the input; the governance layer turns that signal into an accountable, framework-mapped record. Nothing rips out; nothing extra runs on your production path.
What does 'build time and runtime' mean for AI code governance?
AI-written code is half the problem — the other half is what AI does once it runs. Build-time governance covers the code AI writes: attribution, criticality, the recorded decision to ship, the frozen evidence. Runtime governance covers the agents AI runs: a behavior signal when an agent acts, a deterministic boundary guard when it steps out of line, and the same kind of recorded, provable event. Both surfaces feed one estate and one record of accountability.
What does it take to start with Diwo Provenance?
One repository, read-only. GitHub installs in about ten minutes; Azure DevOps connects with even less. That alone lights the core loop — attribution, classification, the decision queue, and a point-in-time evidence pack. The runtime layer is an optional add that rides your existing observability. Nothing leaves your boundary — Provenance is container-first and can run entirely inside your own environment (BYOC).