AI-Generated Code Security Risks: What Breaks, What It Costs to Fix, and How to Verify It

The security risks of AI-generated code concentrate in four places: input handling, cryptography, access control, and dependencies. Veracode’s 2026 GenAI Code Security Report tested more than 100 large language models across 80 code-completion tasks and found security has stalled at a 56% pass rate. Models fail hardest on the ordinary weaknesses, missing cross-site scripting defences (CWE-80) in 86% of cases and log injection defences (CWE-117) in 88%. They also invent third-party package names that attackers then register on npm and PyPI.

I lead AI transformation at AppVerticals, and most of the people who call me about this are not security engineers. They are founders and CTOs with a working product, a codebase a model wrote a large share of, and a launch date already promised to someone.

This piece is written for them. What actually breaks, what it costs to fix, and what evidence to ask for before you accept a delivery.

What Are the Security Risks of AI-Generated Code?

The security risks of AI-generated code are weaknesses a language model introduces because it optimises for code that looks right rather than code that is safe. The four recurring categories are unvalidated input handling, weak or misapplied cryptography, missing access control, and dependencies that were never verified. They pass tests and compile cleanly, which is what makes them hard to catch.

That last point is the one I keep coming back to. A missing permission check does not throw an error. An unescaped output does not fail a build. The code runs, the demo goes well, and the weakness sits there until someone goes looking or something goes wrong.

So the honest framing is that speed moved and verification did not. The generation step got dramatically faster. Reading, testing, threat-modelling and reviewing take exactly as long as they always did.

Why AI Writes Insecure Code: Three Root Causes

Three things drive almost everything I find in these codebases. They are worth understanding because each one points at a different control.

1. The training data carries the flaws

These models learned from public repositories, documentation and forum answers. That corpus contains excellent code and it also contains deprecated functions, insecure patterns and examples written to demonstrate a concept rather than to ship.

A model reproducing a common pattern will reproduce a commonly insecure one at roughly the rate it appears. Popularity in the training data is not a proxy for safety.

2. The model cannot see your architecture

A language model works from the text in front of it, which is a fraction of your system. It does not know your naming conventions, your permission model, your data classification, or the compliance constraint your legal team agreed to last quarter.

So it fills the gap with a generic pattern that fits a generic application. That is the mechanism behind most missing access control I see. The model wrote a working endpoint for an application it was never shown.

3. Security is rarely what the prompt asked for

Models optimise for a plausible, useful answer to the request as stated. Almost nobody types “and make sure the output is escaped.” Security is implicit in the request and explicit in nothing, so it gets treated as optional detail.

This is the same root cause behind the broader problems with how AI is used across the software development lifecycle. The model is answering the question you asked, and security was not in it.

The Vulnerability Classes AI Introduces Most Often

The pattern in the research is consistent. Models do reasonably well on weaknesses with one obvious defensive move and badly on weaknesses that require understanding how data travels through an application.

CWE numbers below refer to MITRE’s Common Weakness Enumeration, the standard catalogue security teams use to classify software flaws.

Language matters too. Java has consistently shown the highest failure rates in the Veracode testing, which puts large enterprises with Java back ends in the most exposed position.

Hallucinated Dependencies and the Slopsquatting Problem

This is the risk that has no equivalent in hand-written code, and it is the one I would flag first to any team shipping AI-assisted work.

Ask a model to handle a common task and it will often recommend a third-party library. Sometimes that library does not exist. The model produced a name that fits the naming conventions of the ecosystem, and it reads as entirely plausible.

Attackers watch for these invented names and register them on public registries like npm and PyPI, filled with whatever they want to run on your machine. The industry has settled on calling this slopsquatting.

What makes it dangerous is that the import line looks correct in review. A reviewer scanning a diff sees a sensibly named package doing a sensible thing. The control that catches it is resolving every dependency against a real, dated registry entry, not reading the code.

What the 2026 Data Shows: Security Has Stalled, Not Improved

The reasonable assumption is that this problem is solving itself as models improve. The measurement says otherwise.

Veracode has run the same test each year: 80 code-completion tasks with known potential for security weaknesses, across more than 100 models, with no security-specific prompting. The 2026 GenAI Code Security Report found the pass rate sitting at 56%. Roughly two in five samples still carry a known weakness out of the box.

The one architectural factor that helped was reasoning capability. That is a useful signal, and it is a long way from a solved problem.

I read this as a planning input rather than an argument against the tools. Adoption is going up and the safety floor is holding still, which means the review burden scales with output. Plan for it now.

Assisted, Generated, Autonomous: Three Risk Tiers, Not One Problem

Most advice on this topic treats “AI-generated code” as a single condition. In practice I see three, and they fail differently enough that one remediation plan will underdeliver on all three.

Tier 1 is the least alarming and the most common. The code sits in a real repository with real tests, and the problem is volume against review capacity.

Tier 2 is where I find the serious issues. When applications built this way have been scanned at scale across thousands of vibe-coded apps, the recurring findings are exposed secrets and access rules that were never enforced. The interface is usually the strongest layer and the backend is usually the weakest.

This is why I treat vibe coding for mobile app development as a validation route rather than a delivery route. It is excellent for proving an idea and it does not produce a backend you should put customer data in.

Tier 3 is newest and moves fastest. As teams adopt agentic AI software development, the permission scope granted during a prototype tends to survive into production, and the cost of a wrong decision scales with the breadth of what the agent is allowed to touch.

What It Costs to Secure an AI-Generated Codebase

This is the question everyone actually calls about, and it is the one with the least published guidance. The answer depends almost entirely on which tier you are in and whether the data model underneath is sound.

Here is how I scope it.

One decision drives most of the cost. Hardening works when the architecture is sound and the failures sit in access control, validation and error handling. A rebuild becomes cheaper when the data model is wrong, because every fix layered on a broken schema gets redone later anyway.

The wider bill here is AI technical debt, which covers how to score your exposure across both generated code and production AI systems and put an annual figure against it. Security is one of three places that debt lands.

The Acceptance Gate: What to Demand Before You Accept AI-Generated Code

If you are commissioning a build rather than writing it, this section is the one that saves you money. Almost every remediation project I take on could have been avoided by asking for evidence at handover.

Ask for these eight things as deliverables. A capable partner will produce them without friction.

1. A written statement of which components were AI-generated and with which tools.
2. Static analysis output run on the delivered branch, not on a clean sample.
3. A dependency manifest with every package resolved to a real, dated registry entry.
4. Evidence that access rules were tested with a lower-permission account, not just an admin.
5. Documented behaviour for failure states: failed login, denied permission, empty data, failed payment.
6. A named engineer who can explain any module on request.
7. Secrets scanning results across the full commit history, not just the current head.
8. A written list of what was found and deliberately not fixed, with the reasoning.

That last one matters more than it looks. Every project has accepted risks. The difference between a healthy delivery and a bad one is whether those risks were decided or discovered.

There is a fuller vetting checklist in our guide to how to evaluate an AI development company which covers the process questions alongside these evidence requirements.

Where OWASP and NIST Guidance Actually Applies

Two standards come up constantly in these conversations, and it helps to be precise about what each one does.

The owasp.org is a ranked list of the most critical web application security risks. It is the right vocabulary for classifying what a review finds, and the weaknesses in the table above map onto it directly. It does not tell you anything specific about generated code, because the flaws are the same old flaws arriving by a new route.

The NIST Secure Software Development Framework  is the more useful reference for this problem. It describes the practices a development process should contain — reviewing code, protecting the toolchain, verifying third-party components, without prescribing tools. Every one of those practices is exactly what gets skipped when generation outpaces review.

So the practical read is that neither standard needs an AI-specific edition for you to act. Generated code breaks the same controls the frameworks already ask for, and the gap in an audit will be written up as a change-management failure rather than an AI problem.

Where AI does need its own treatment is agent permissions and model oversight, which is what our AI governance services put in place before a system reaches production traffic.

The coupling you accept at the start also shapes how much of this you can control later, which is the argument underneath building your own model versus calling an API. 

AI-Generated Code Security Risks in Regulated Builds

Healthcare, fintech and anything handling regulated data change the calculation in one specific way. The controls are not stricter because AI wrote the code. They were always this strict, and generated code makes them easier to skip.

An auditor will ask how a change reached production and what evidence exists that it was reviewed. If AI-suggested changes merged without a documented review, the finding lands against your change-management control and the AI is incidental to it.

My working rule for regulated builds is that generated code gets a stricter review than hand-written code, rather than an equal one. A person wrote the hand-written line and can explain the reasoning. Nobody has yet reasoned through the generated one.

Where to Start

The decision in front of you is smaller than the problem sounds. You do not need a position on whether AI belongs in your codebase, because it is already there. You need to know which of the three tiers you are in, and the six questions above will settle that in an afternoon.

What follows from the answer is straightforward. Tier 1 needs a review standard written down and enforced. Tier 2 needs the backend and the access rules rebuilt before real users touch them. Tier 3 needs permission scopes narrowed before the next agent run.

All three need someone who can explain the code, and that is the requirement no tool satisfies on your behalf.

The teams that get burned are the ones who accepted a delivery that compiled, passed, and had never been read.