Is AI-generated code secure? An honest answer

The honest answer is: often not, at least not without review. Multiple independent studies have found that a large share of AI-generated code contains exploitable flaws — Veracode's 2025 analysis put it at 45% of samples failing security tests, and an earlier NYU study found roughly 40% of GitHub Copilot completions were vulnerable in security-relevant contexts. AI coding assistants are genuinely useful and much of what they produce is fine, but they are not security-aware by default, and treating their output as trustworthy on sight is where teams get hurt.

This guide walks through what the evidence actually shows, where AI code is safe versus dangerous, the overconfidence problem that makes it worse, and the two things that measurably lower the risk.

What the studies actually show

Four findings from independent, first-party and peer-reviewed sources give a consistent picture. They measured different things, but they point the same way.

Veracode's result is the one to sit with. The failure rate barely moved with model size — so simply waiting for a bigger model does not fix it. Java fared worst at 72%, and even the strongest language in the set still failed well over a third of the time. Bigger models write more fluent code; they do not reliably write safer code.

The NYU finding predates today's models but has held up directionally: when researchers steered Copilot into security-relevant situations, about 40% of its suggestions contained a known weakness. Apiiro's 2025 analysis of production repositories found that as teams leaned on AI assistants they shipped several times more code but roughly ten times more security findings — including a sharp rise in privilege-escalation paths. More code, faster, is also more attack surface, faster.

The USENIX work points at a newer risk: nearly one in five packages an LLM recommends does not exist. Attackers register those hallucinated names and wait for someone to run the install — a supply-chain attack now called slopsquatting, which has its own concrete defenses.

Pulled together — as CSET's review of the cybersecurity risks of AI-generated code does — the finding is not one bad model or one bad language. It is a systemic property of how these tools work: they generate the most probable code, and the most probable code is not the most secure code. That is why the mitigations below are about process and guardrails, not about picking a different assistant.

Where AI-generated code is usually fine

The risk is not uniform. AI code tends to be safe exactly where a bug would be caught anyway or where there is no trust boundary to cross:

• Boilerplate with no security surface — data objects, config scaffolding, test fixtures.
• Pure functions and well-specified algorithms you can test directly against inputs and outputs.
• Code in a language or framework whose idiomatic defaults you already enforce (an ORM you always parameterize, a template engine that escapes by default).
• Anything you were going to read line by line before merging regardless.

Where it gets dangerous

The failures cluster in a small number of predictable places. These are the lines to slow down on:

• Anywhere untrusted input meets a query, a shell, a file path, or a template — injection lives here, and it is the most common class Veracode saw.
• Authentication, authorization, session handling, and cryptography, where a subtle error is silent until it is exploited.
• Dependency and package selection, where a single hallucinated import is a foothold.
• Secret handling — assistants happily hardcode keys and tokens, which is why keeping secrets out of the agent's reach is its own discipline.
• Error handling that fails open, leaking stack traces or granting access on the exception path.

The overconfidence trap

The most dangerous variable is not the model — it is how much we trust it. A Snyk survey reported that more than three-quarters of developers believe AI-generated code is more secure than human-written code, while around 80% said they bypass their own organization's AI-code security policies. Read those two numbers together: the belief that the output is safe is precisely what removes the review that would have caught the flaw. Vendor surveys should be read as directional rather than precise, but the direction here is unambiguous.

What actually lowers the risk

Two things move the needle, and neither is exotic.

1. Review AI code as adversarially as you would an external contribution. The secure-review workflow for AI-generated code covers what to flag first, a worked injection example, and where automated scanners quietly miss things.
2. Put guardrails between the agent and your repository — hooks that block dangerous commands, pin and verify dependencies, and keep secrets out of context. The AI coding agent guardrails checklist is the defense-in-depth version.

Claude Code ships useful security tooling for free — the /security-review command and a security-guidance plugin are a real starting point, and you should turn them on. The Kaairos Security Kit builds on that free foundation rather than replacing it: layered PreToolUse and pre-commit hooks, threat-model templates, and framework-specific reviewers, all license-audited and maintained so the guardrails do not rot. It does not remove the need to review; it makes the dangerous paths harder to walk down by accident.

The bottom line

Is AI-generated code secure? Not inherently — the evidence is consistent that a meaningful fraction of it ships with real vulnerabilities, and confidence in the tools tends to outrun their actual safety. But not-inherently-secure is not the same as unusable. AI code is fine where you would have reviewed it anyway and dangerous where you were tempted not to. Keep the review, add the guardrails, and the risk becomes manageable rather than invisible.