We spent two years celebrating AI productivity gains. Faster shipping. More features. Smaller teams. The numbers were real and the demos were compelling and everyone had a story about how their team 10x'd their output.
Nobody put a number on the security debt we were accumulating in the process.
Here it is: 92%.
A 2026 security audit by Sherlock Forensics found that 92% of AI-built applications contain critical security vulnerabilities. Not minor issues. Not things you fix in the next sprint. Critical flaws. In nine out of ten apps your team shipped with AI assistance.
Congrats on the velocity. You also shipped the bugs.
What's Actually in the Codebase
The specific numbers are worse than the headline.
78% of AI-generated applications stored secrets in plaintext. Not in poorly chosen locations — in plain text. The kind of thing that gets you on the front page of TechCrunch when a researcher finds your API keys in a public GitHub repo.
73% of AI systems showed exposure to prompt injection vulnerabilities — attacks where malicious input hijacks the AI component's behavior. This is the new XSS. Most developers building AI-integrated apps aren't thinking about it at all.
41% of AI-generated backend code includes overly broad permission settings — often default admin-level access — because the model doesn't know to restrict permissions and the developer didn't check. The AI generated something that works. It generates something that works with root access to everything because that's the path of least friction in the training data.
And in March 2026 alone, 35 new CVEs were disclosed that directly resulted from AI-generated code. One of them — CVE-2025-53773, CVSS score 9.6 — was a hidden prompt injection in a PR description that enabled remote code execution through GitHub Copilot. Not in the production code. In the PR description. The attack surface got bigger in a direction nobody was guarding.
The Review Bottleneck Nobody Planned For
Here's the systemic problem underneath the statistics.
When AI coding tools hit, the pitch was: you write faster, you ship faster, you win. The McKinsey 2026 study found a 46% reduction in time spent on routine coding tasks. That number is real. Your team is generating more code than ever.
Your security team is not 4x larger.
ProjectDiscovery's 2026 AI Coding Impact Report framed it cleanly: AI-generated code is outpacing security teams' ability to keep up. 69% of mid-sized organizations report growing difficulty reviewing the volume of code AI is generating. You went from reviewing 10 PRs a day to 40. The same two people are doing it.
And the problem compounds because AI-generated code isn't safer by default — it's the opposite. IBM found that AI-generated code carries 1.7x more bugs than human-written code. It doesn't have decades of security intuition baked into it. It doesn't know your specific threat model. It generates what works in the general case, and the general case often doesn't have your production environment's constraints, permission requirements, or attack surface in mind.
You sped up the writing phase and created a crisis in the reviewing phase. The bottleneck didn't disappear. It moved — and the new bottleneck is sitting on top of code that's harder to trust.
The Cognitive Dissonance
Here's the number I find most interesting: only 24% of developers say they trust AI-generated code "a lot."
Nearly half of all merged code is AI-generated. Only one in four developers trusts it highly. Those two facts are living inside the same codebases right now.
What that tells you is that teams are merging code they're not confident in, at a volume they can't fully review, with a security track record that's actively getting worse. Not because developers are irresponsible — because the process hasn't caught up to the pace. Everyone knows the review is inadequate. Everyone keeps merging anyway because the sprint doesn't stop.
This is how you build a debt bomb. Not through negligence. Through a lag between capability and process.
What You Can Actually Do About It
The answer isn't slowing down AI. You're not going to win that argument with your team or your leadership, and frankly you shouldn't have to — the productivity gains are real and you'd be throwing them away. The answer is redesigning the pipeline so that AI-generated code gets treated as what it actually is: untrusted external input that needs verification before it's production code.
A few things the teams navigating this well are doing:
- Automated security scanning on every AI-generated PR, before human review. Not instead of human review — before it. Secrets detection, SAST tools, permission scope analysis. If the automation catches it, it doesn't consume a human's attention.
- Tight permission defaults as a lint rule. If AI-generated code requests admin-level access and the feature doesn't need it, CI fails. This one change would have caught a significant portion of that 41% overly-broad-permission statistic.
- Prompt injection testing for anything AI-integrated. If your application takes external input and passes it to an LLM, you need to test it the same way you test for XSS or SQL injection. It's the same attack class with a new name.
- Code provenance tagging. Some teams are starting to distinguish AI-generated code from human-written code in their review queues — different review requirements, different automated gate thresholds. It's early, but it's the right instinct. The developers who look smart in 18 months aren't the ones who shipped the most code with AI. They're the ones who built verification into the loop from the start — and kept their security debt from compounding while everyone else was celebrating velocity metrics.
Security debt announces itself differently than financial debt. It doesn't show up in a quarterly report. It shows up at 3am, and it's a much worse meeting.
Sources: 92% of AI Code Has Critical Vulnerabilities | Sherlock Forensics | ProjectDiscovery's 2026 AI Coding Impact Report | AI Coding Security Vulnerability Statistics 2026 | SQ Magazine | 2026: The Year of AI-Assisted Attacks | The Hacker News