The Security Pass Rate on AI Generated Code Has Not Moved in a Year, and Better Models Did Not Help
Veracode’s 2026 GenAI Code Security Report found that roughly 44% of AI code generation tasks introduced a risky security vulnerability, with the average security pass rate across models sitting at about 56%. The comparable figure in their first report was 55%.
Read those two numbers next to each other, because the interesting thing is not the level. It is that the level did not move. Across the same period, coding benchmarks improved steadily. Their spring 2026 update, drawn from more than 150 models evaluated to date, found the pass rate flat, larger models not outperforming smaller ones, and vendor claims about security aware training not corresponding to measured outcomes.
A capability that stays flat while adjacent capabilities improve is telling you the bottleneck sits somewhere other than the model.
The rest of the picture, briefly
The independent data all points the same direction, and the numbers are worth having to hand.
An AppSec study tested 534 code samples across six major models against the OWASP Top 10 and found roughly one in four contained a confirmed vulnerability, with injection class weaknesses accounting for about a third of confirmed findings. A broader Veracode analysis found 86% of generated samples failed to defend against cross site scripting and 88% were vulnerable to log injection, with Java the worst language at a 72% failure rate.
Black Duck’s 2026 report audited 947 codebases and found mean vulnerabilities per codebase at 581, up 107% year on year, with 87% of codebases carrying high or critical severity issues. Software Improvement Group analysis of 30,000 enterprise systems found AI generated code showed roughly twice as many security risk violations as human written code, with more than half containing vulnerabilities.
On the enterprise side, Veracode’s State of Software Security shows security debt affecting 82% of organisations, up 11 points, with critical security debt at 60%. Only 24% of organisations perform comprehensive evaluation of AI generated code. As one industry summary put it, software is now being created faster than most organisations can secure it.
Why the model is not the variable
The mechanism here is the same one that shows up in every other failure mode of agentic coding.
A model producing a function has to work out what the surrounding system requires before it can decide anything. Whether this path enforces authorisation, whether input is already validated upstream, whether the logging call escapes user data, whether this service is multi tenant and the tenant identifier is always present in the request context. None of that is in the function it is writing, and most of it is not in the file either.
So the model infers the rest. A model whose training data is full of correct security patterns will produce a correct pattern in the abstract and still miss the one your system actually depends on, because the requirement was specific to your architecture and was never visible to it.
That is why a bigger model does not help. It is better at inference, and this is not a failure of inference. It is a failure of information.
The security researchers have a related finding on the same theme. Developers using AI assistants wrote significantly less secure code while exhibiting a false sense of security, often rating insecure solutions as secure. The output looks responsible right up until somebody with real context spends real attention on it.
Scanning after the fact is not the same operation
The obvious answer is a scanner, and scanners are worth having. They also arrive at the wrong moment and answer a different question.
A static analyser matches patterns against a rule set built from known vulnerability classes. It is very good at finding a hardcoded credential or an unparameterised query. It holds no representation of what your code was supposed to do, so it cannot tell you that this change removed an authorisation check the reporting service was relying on, because there is no CWE for breaking an assumption another team made.
The volume problem compounds it. AI generated code is now producing more than 10,000 new security findings monthly at some organisations, up roughly tenfold from late 2024. A queue of findings nobody can triage is not a control, whatever it looks like on a dashboard.
What we check instead
ByteBell is a verification layer generated on top of a codebase of any size below 10 million files, and it changes both when the check happens and what it is checking against.
Cheap open source models read every file once at indexing time. An agent detects the boundaries of each language element, stores them separately, then analyses each one in the context of its file, its module, its repository and across every repository. For each file the layer stores what it does, why it exists in business terms, what users lose if it fails, the capabilities it provides, its edge cases, the contracts it provides, its preconditions, and the specific places where the behaviour is genuinely undecided. Every claim carries the file and the line it came from.
Two things then become possible that a scanner cannot do.
The first is that generation gets grounded. An agent writing against the layer is writing against the contracts your repositories already have rather than against a guess, so the requirement that would otherwise have been missed is visible before the first line is written. That is where accuracy of code above 93% comes from.
The second is that verification runs before merge. We trace what a change touches, generate tests for it, run them, and review each modified file against what that file promised at the indexed base rather than against what the diff claims it changed. Collateral damage is checked across the other repositories that read the same helper before anyone approves. A full pass came to 87,001 tokens at $0.11.
A concrete version
An agent adds a nullable field to a subscription model and stops counting cancelled subscriptions in monthly revenue. Every static rule passes and the tests are green.
The layer surfaces three things before the code is written. The definition of an active subscription already lives in the billing package rather than the API layer. The subscription shape is read by the reporting service as well, so a new field changes both surfaces at once. A mobile client decodes the same payload strictly, so an unknown field fails the parse there unless it is added deliberately. The change lands in 4 files, and the fourth is the one an agent working without the layer would have missed.
None of that is a vulnerability class. All of it is a production incident.
The economics, which decide whether this gets adopted
Indexing runs about 0.89, against roughly $30 for the same work by brute force. Token spend drops by roughly 80%.
That matters because the alternative has a documented price. One case study recorded autonomous agents building a system in a week, generating between €10M and €15M in token fees, and producing code described as nearly unmaintainable.
For regulated buyers the deployment story is the deciding factor. Hosted, on dedicated hardware, or fully inside your own network, read only in all three, with source never leaving your infrastructure on the second two.
Where a scanner is still the right tool
Known vulnerability classes, dependency advisories, secret detection and licence compliance are all better served by a purpose built scanner, and none of that goes away. The two are complementary, and a security review that reads the verification layer through MCP is stronger than either instrument alone.
The honest limitation
Ours is a confidence figure rather than a guarantee, and 93% is not a number anybody should treat as a security control on its own. A derived layer can be wrong about what code means, which is why every claim carries a file and a line so it can be checked in about 10 seconds, and why there is a window after a push where a claim can lag the branch.
We also do not cover every language. Mojo is not indexed today.
This is what ByteBell builds
The question for a security team is narrow. Take the last vulnerability that reached production and ask whether a rule set would have caught it, or whether catching it required knowing what another team’s service was relying on. If it is the second, the tool you are missing is not a better scanner.
ByteBell is the verifiable context layer for code. We run the LLM compiler pattern, a one time pass where a model reads every file and lowers it into a verifiable code IR capturing purpose, business context and cross repository relationships, on your own infrastructure through Docker, with your source never leaving your environment. Every engineer, on any copilot, queries the same representation through a single MCP url, and every agent edit is checked against it before it lands, using per file SHA-256 diffing so only what actually changed gets examined again. Across 46 Kubernetes ecosystem repositories and 150,000 files we measured roughly 10% higher accuracy at 70% lower cost, on about a fifth of the tokens.