Cyber Insurance Renewal: The AI-Written Code Question Your Broker Will Send
Your cyber insurance application says AI-written code is reviewed. Here is how to find out whether that is true and keep a record before your policy renewal.
Cyber Insurance Renewal: The AI-Written Code Question Your Broker Will Send
Your application says every change is reviewed. Your underwriter wants to know which ones, and by whom. A signed paragraph won't answer that. A record will.
Part of our AI Code Governance: A 2026 Field Guide series: the operating model for attributing, classifying, deciding, and proving AI-written code.
Picture the renewal packet landing six weeks before your policy expires. Between the usual questions on MFA and backups sits a new line: describe how AI-generated code is reviewed before it reaches production.
Someone drafts the obvious answer: all code is peer reviewed before merge. Then someone pulls the merge history for the payments repo. Three changes show an AI agent as the author and an empty reviewer field. The sentence an officer is about to sign is one nobody can support.
What is an insurer really asking about AI-written code?
An underwriter prices the chance that a weakness in your software becomes a claim. AI coding agents change how that software gets written, so the questions follow. Which AI tools do your developers use? Who reviews what they produce? How would you know if something slipped through?
The wording differs by carrier and by year. Ask your broker for the current application and read every question about software development, change management and AI.
The shape stays the same. A declaration is easy to give. Evidence is what you want in hand if anyone ever tests it.
Why AI-written code makes the honest answer hard
Before agents, "peer reviewed" was true by construction. A human wrote the change, a human approved it, and the pull request held both names.
Agents loosened that:
• Authorship blurs. The commit carries a developer's name, but an agent wrote most of it. Or the agent is the author and no human typed a line.
• Approval thins. Changes merge on a green check, an auto-approve setting or a review that lasted seconds. The approver field is filled, but not necessarily by anyone who read the diff.
• Context detaches. Why the change was made lives in a chat transcript that isn't attached to the pull request.
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. A control you can't see is a control you can't describe accurately on an application.
Why your existing tools can't answer it
The scanner lists findings. CI shows the tests passed. Branch protection shows a rule exists. Each is evidence of something.
None of them records whether an AI wrote the change, or whether the approver was anyone other than the author's own agent.
Say the rule requires one approving review. An agent opens the pull request, a teammate clicks approve in a few seconds, and the rule is satisfied. The record shows an approval. It does not show that anyone read the change.
The scanners were never the problem. The missing layer was.
Declared is not the same as derived
An application answer is declared. Someone believes it, writes it and signs it. Evidence is derived: read from signals your estate already emits, such as merge history, review records and the agents' own settings files.
For each AI-authored change, two questions have deterministic answers. Was a human review recorded? Was the reviewer someone other than the author?
Reading a value is not the same as asking a model for an opinion. "Auto-approve is enabled in a repository that touches production" is a fact anyone can reproduce. "This looks low risk" is an opinion nobody can sample.
A declared control is a promise. A derived record is the proof.
Evidence has edges, and you should name them. A review that happened in a hallway and was never recorded shows up as a gap, not a pass.
What to do before your next renewal
Four steps. None needs a new tool to start.
- Read the application early. Ask your broker for the current one and mark every question that touches AI tools, code review or change management. Do it before the packet lands, not after.
- Pull your own sample. Take 25 merged changes from your most sensitive repositories last quarter, and mark which ones an AI tool authored. The number 25 is a working sample size, not a standard.
- Count the empty reviewer fields. If the count is zero, you have your answer. If it isn't, you have a number for your CISO and your broker before anyone asks, and you can answer with a named owner and a date to close the gap.
- Write the control, then evidence it. Require a recorded human approver on AI-authored merges in repos that touch payments, customer data or production access. Low-risk repos don't need the same bar. Evidence it continuously, not in the weeks before renewal.
Do the first three this week. It takes an afternoon and tells you whether the application answer is a lookup or a negotiation.
Where Provenance fits
Diwo Provenance is the governance layer above the scanners and pipeline tools you already run. It reads signals your estate already emits (merge and review history, the agents' own settings files), derives which changes AI wrote and whether a human reviewed them, and turns the gaps into decisions: fix, waive or accept, each with a named owner.
On a real 52-repo engineering org, the first connection surfaced 25 AI-authored pull requests merged with zero recorded human review. That is the kind of number you want to find before the application does.
The evidence is sealed into a record you can hand to a broker, an auditor or a board, and its exports map to SOC 2, ISO 27001, the EU AI Act and NIST AI RMF. That is evidence readiness, not a legal determination. Your counsel makes the legal call, and your carrier decides what satisfies its underwriters.
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 with a free, read-only connection: connect your estate free and count the AI-authored changes with no recorded approval.
Your application declares the control. Provenance shows it operated.
Related reading
• The pillar: AI Code Governance: A 2026 Field Guide: the full operating model and the three risks to govern first.
• Who's Accountable When AI Writes the Code?
• Your AI Agent Has Your Production Keys: Here's How to Find Out
Frequently Asked Questions
Do cyber insurers require a human to review every AI-written change?
Not as a single rule we can point to. Carriers differ, and your application and policy wording set the bar. Scaling the requirement to repo sensitivity, and writing it down, is a defensible design. Confirm the specifics with your broker.
Do I need to give a governance tool access to my source code?
No. Provenance reads signals such as merge and review history and the agents' settings files. It reads code signals, never your source.
Will this lower my premium?
Pricing and coverage are the carrier's decision, and no tool can promise an outcome there. What Provenance gives you is a sealed record of which AI-authored changes were reviewed, so your answers on the application are ones you can support.
---
See it in action
Your scanners detect. Provenance decides.