Originally published on the Dromeas blog.
AI-generated code has 2.74x more vulnerabilities than human-written code. Copilot adoption is near-universal in the Fortune 100. And the EU AI Act's high-risk obligations now land on 2 December 2027. Here is the checklist that actually matters.
The security conversation about AI-generated code has moved past "should we allow it" — your engineers already use it, and most of them use it daily. The question now is operational: how do you govern a codebase whose authorship is increasingly non-human, at a pace no review board can match?
Three numbers frame the problem. AI-generated code carries roughly 2.74x more vulnerabilities than human-written code (Veracode 2025). GitHub Copilot is used by around 90% of the Fortune 100 (GitHub), before you count Claude Code, Cursor, and the rest. And the EU AI Act's obligations for high-risk AI systems now apply from 2 December 2027 — pushed back from August 2026 by the AI Omnibus, which entered into force on 27 July 2026 (systems embedded in regulated products get until 2 August 2028). The extra runway does not change the expectation: documented provenance, an AI Bill of Materials, and evidence of how AI-assisted code was checked. If your governance plan is still "we'll review the PRs carefully," it is already behind the reality on your main branch.
Where the risk actually concentrates
Not all generated code carries the same risk. In practice the exposure clusters in three places, and each one has a different mitigation shape:
Dependency and secret drift. Agents reach for packages and patterns from training data — outdated versions, deprecated libraries, and occasionally hardcoded credentials in example-shaped code. Static dependency scanning catches the known-CVE slice; it misses the "correct-looking but wrong" slice, like an auth helper that works and is subtly unsafe.
The review blind spot. Human reviewers read generated code more charitably than human-written code — it looks confident and idiomatic, so it gets skimmed. That is precisely the code the 2.74x number is describing. The blind spot isn't negligence; it's a predictable cognitive effect, which means it needs a systemic fix, not a reminder.
The provenance gap. When an auditor (or your own incident review) asks "what wrote this line, under which policy, with which model," most teams today have no answer. That gap is what the AI Act's AI-BOM expectation is aimed at: not knowing the answer is becoming a compliance finding, not just an inconvenience.
What a workable governance layer looks like
The teams that get ahead of this do three things, and none of them involve slowing developers down:
- One bar, no detection step. Apply the same security and quality checks to every change regardless of authorship. Architectures that first "detect AI code" and then route it somewhere stricter add a failure mode (the detection) and a governance seam (the routing). Sonar is already retiring the auto-detection half of its own feature — we wrote up why that's the wrong default. A single uniform gate can't be skipped by mislabeling.
- Post-merge coverage, not just PR gates. Agents increasingly commit directly to trunk. If your security review only exists on the PR, a growing share of your production code passes no gate at all. Every commit — PR or trunk — should get the same automated pass.
- Provenance as a byproduct, not a project. Every review run should record what was checked, by which models, against which standard, with which verdict. Do that and the AI-BOM, the SOC 2 evidence, and the EU AI Act documentation all fall out of normal operation instead of becoming a quarterly scramble.
The questions to put in front of your team this quarter
If you do nothing else, get concrete answers to these:
- Which agents and assistants are committing code today, to which repos?
- What percentage of merges in the last 90 days had no human review?
- If an auditor asked for a bill of materials of the AI systems that touched production last month, could you produce one?
- Which checks run on trunk commits after merge — and who reads the results?
- When a generated-code incident happens, what is the provenance trail you would walk?
Most organizations can answer one or two of these today. December 2027 sounds far away; the codebase you will be audited on is being written this quarter.
Top comments (1)
Your insights into the vulnerabilities associated with AI-generated code are spot on, especially regarding the cognitive biases that can lead to overlooking critical issues in reviews. The shift towards uniform security checks regardless of authorship is a crucial step, and it really emphasizes the need for robust automation in post-merge processes. I wonder if you've considered incorporating AI models that specialize in vulnerability detection as part of your governance strategy—this might help bridge the provenance gap effectively while maintaining developer speed. If you're exploring ways to enhance the governance layer further, I’d be interested in discussing a paid collaboration to tackle this challenge together.