Is AI-generated code secure? What the testing shows

Ask whether AI-generated code is secure and you usually get an opinion. There is measured evidence now, and it is specific enough to plan around.

The short answer

Veracode's spring 2026 study tested more than 150 large language models against 80 coding tasks, across four languages and four vulnerability types. Only 55 percent of the generations produced secure code when the prompt gave no explicit security guidance [1]. Put plainly, close to half of what came back contained a known vulnerability.

The more useful number is the trend. Security performance has stayed between 45 and 55 percent since 2023. Over the same period, syntax correctness rose from roughly 50 percent to about 95 percent. Models got better at writing code that compiles and runs, and did not get better at writing code that is safe. Veracode describes the gap between code that works and code that works securely as growing wider.

That matters because the thing that improved is the thing you notice, and the thing that did not improve is the thing you do not.

Where it fails, and where it does not

The averages hide large differences. Broken out by language, Python passed 62 percent of the time, C# 58 percent, JavaScript 57 percent, and Java 29 percent. A Java service built this way is in a different risk category from a Python one, and no general statement about "AI code quality" stays true across results that far apart.

By vulnerability type the range is wider. SQL injection was handled correctly 82 percent of the time and insecure cryptographic algorithms 86 percent. Cross-site scripting was handled correctly in 15 percent of cases, and log injection in 13 percent.

There is a pattern worth naming. The categories the models handle well are the ones with a single standard fix that appears constantly in public code: use a parameterised query, use a modern cipher. The categories they handle badly are the ones where safety depends on context the model cannot see, such as where a value came from, whether it has already been escaped, and where it is about to be rendered. Cross-site scripting is exactly that kind of problem, and it is the one the models are worst at.

So the risk is not spread evenly across your codebase. It is concentrated in the code that takes untrusted input and passes it to a place where it will be interpreted.

Why "we review everything" is a weak answer

The obvious control is human review, and it is much weaker here than it feels.

The first reason is volume. Generated code arrives faster than anyone reads it, and review quality falls as diff size grows. A reviewer facing 900 lines does not apply the attention they would give 90.

The second reason is that these flaws are, by accident, the kind a reader misses. Generated code is fluent. It follows conventions, it is commented, it looks like the surrounding code. A missing escape on one path in a well-structured file is harder to see than a badly written function.

The third reason is that we are poor judges of our own performance with these tools. In a randomised controlled trial published in July 2025, METR gave 16 experienced open-source developers 246 real tasks in repositories they already knew well. The developers using AI tools took 19 percent longer, and afterwards estimated that AI had made them 20 percent faster [2]. METR is careful to label the result as historical, since the tools have changed since then, and that caveat is fair. The finding that still holds is that skilled people misjudged their own performance by 39 points, in the direction that made the tool look better. If your sense of your own speed is that unreliable, your sense of whether a diff is safe is not going to be better.

Developers seem to sense this. In Stack Overflow's 2025 survey, 46 percent said they actively distrust the accuracy of AI output, against 33 percent who trust it [3].

What actually works

Security has to move from something a person notices to something a pipeline enforces. Three things matter most.

Static analysis that blocks the merge. Not a report someone reads on Friday. A check that fails the build. If it only warns, it will be ignored within a month.

Checks aimed at the categories that fail. The general scanner is the minimum. Add explicit assertions on the paths where untrusted input reaches a place where it is used: rendering to a page, writing to a log, building a query, constructing a shell command. Those are where the measured failure rate is worst, and a targeted check finds what a general one misses.

Prompt-level guidance, with verification anyway. The 55 percent figure is for generations with no security guidance in the prompt. Asking for secure output helps, and it is free, so do it. It is not a control, because you cannot tell from the output whether it worked. Ask, then verify.

All three follow the same idea covered across this guide: the check has to exist before the code, and it has to be able to fail. That is the subject of eval-driven development, and the security case is the clearest argument for it.

What to ask a vendor

If someone is writing AI-generated code for you, four questions separate a real answer from a reassuring one.

Which security checks run on every change, and do they block a merge or produce a report? What happens to a pull request that fails one? Which languages and flaw classes are you treating as higher risk, and why those? When a vulnerability reaches production, what changes in the pipeline afterwards, not just in the code?

The last one matters most. A team that fixes the bug and does nothing more will see the same bug again. A team that adds the check that would have caught it gets better protection with each bug. We wrote about the cost of skipping that step in the real cost of shipping unverified code.

If you want the wider view, how to review AI-generated code covers what a person should still look at, and AI coding governance covers the rules once more than one team is building this way. If you are deciding whether to generate the whole thing yourself instead, Reveneau vs an AI app builder sets out where that limit is.