For the last two years, "AI-generated code has security problems" was a claim you could still argue about. It isn't anymore. Veracode's 2026 GenAI Code Security Report tested code from more than 100 large language models across hundreds of coding tasks and found a security pass rate of 56 percent, barely moved from 55 percent the year before, even as every one of those models got dramatically better at producing code that compiles, runs, and passes its own tests. Roughly 44 percent of generation tasks introduced at least one exploitable vulnerability. The models are not getting worse. They are optimizing for the thing they were trained to optimize for, which is functional correctness, and security was never part of that objective.
What changed in the last year is not the vulnerability rate. It is the volume of AI-generated code actually reaching production. Coding agents now open, review, and merge real pull requests inside real engineering orgs, and the acceptance rate of that code has climbed fast enough that most teams no longer read every line before it ships. That is the gap this post is about: not whether AI-generated code has security debt, but what a team does about it once the code is already the majority of what gets merged.
It is worth being specific about where the risk actually concentrates, because "AI code is less secure" is too vague to act on. The research from this year points at a handful of repeatable patterns rather than a diffuse cloud of risk.
None of this means coding agents are unusable. It means the failure modes are specific and known, which is actually good news, because specific and known failure modes can be caught with specific and known controls. The rest of this post is about which controls actually work.
The most distinctive new risk in this cycle does not exist in human-written code at all. Large language models occasionally hallucinate package names that sound entirely plausible, a name that fits the ecosystem's naming conventions and does exactly what the surrounding code needs, but does not exist. Attackers have caught on. The pattern, now called slopsquatting, is simple: watch which nonexistent package names multiple models hallucinate for the same prompt, register those names on npm or PyPI before anyone else does, and wait for an AI coding assistant to recommend the package and a developer to install it without checking.
This is not theoretical. Researchers at Socket.dev ran the same prompts across five frontier models and found 53 hallucinated package names that were still available for registration, 41 on PyPI and 12 on npm, meaning any of the researchers, or an attacker running the same experiment, could have claimed them. It has already happened for real: developers using AI tools were recommended a package called react-codeshift, a hallucinated mashup of two legitimate packages, and in an earlier documented case a hallucinated Python package name accumulated more than 30,000 real downloads before anyone flagged it. A study across 2.23 million AI-generated code samples found that 19.7 percent contained at least one hallucinated package reference. That is not a long tail edge case. That is roughly one in five AI-assisted code samples pointing at a dependency that might not exist yet, and might exist tomorrow with someone else's code inside it.
Traditional code review assumes the author understood the code they wrote and made a judgment call, even a wrong one, that a reviewer can interrogate. AI-generated code breaks that assumption. The pattern a model produces is usually the statistically common one for that kind of task, not a considered decision about your specific trust boundary, and it will look exactly as confident whether it is right or catastrophically wrong. A human engineer who is unsure tends to leave a comment, a TODO, or a question in a pull request description. A model rarely does, because nothing in its training rewarded expressing uncertainty in a diff.
This matters for how you staff review, not just how you tool it. A reviewer skimming an AI-authored pull request for style and obvious bugs will miss almost everything on the list above, because the code reads cleanly and passes its tests. The vulnerabilities in AI-generated code are disproportionately the kind that only show up under a security-specific lens: an IAM policy that is technically valid but too broad, a dependency that resolves but was registered eleven days ago, an error handler that swallows an exception instead of failing closed. None of that trips a linter. All of it trips a security reviewer who knows to look for it.
The teams handling this well are not banning coding agents, and they are not reviewing every line by hand either. Both extremes fail: a ban gets quietly ignored, and full manual review does not scale to the volume agents now produce. What works is a gate that is proportional to risk, applied automatically wherever possible and by a human wherever it can't be.
None of the controls above require pausing your use of coding agents, and none of them are exotic. The teams furthest ahead on this treated it as an SDLC change, not a tooling change: they updated their branch protection rules, added a dependency-freshness check to CI, and drew a short, explicit list of paths that always require a named human reviewer regardless of who or what authored the diff. That list took most of the teams we have talked to about this less than a day to write down and has already caught real issues once enforced.
The pattern underneath all of this is the same one that shows up whenever a new class of contributor joins a codebase faster than your review process can adapt to it: the fix is rarely more process everywhere, and almost always sharper process in the small number of places where the blast radius is largest. If you are scaling coding agent adoption and want an outside read on where your current review gate actually has gaps, that kind of audit is core to what our AI consultancy work does for engineering teams moving from pilot to production. Start with the permission boundaries and the dependency gate. Everything else on this list gets easier once those two are in place.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.