AI-generated code security risks are vulnerabilities introduced when a coding model writes code without knowing what the surrounding system protects. Veracode's evaluation of more than 100 large language models found 55% of AI-generated code was secure.
Missing security context at generation time is what puts the flaw into the file, so it arrives before any review begins. Four practices address the gap: automated scanning, verification that suggested dependencies exist, security requirements defined upfront in the specification, and independent review of the highest-risk code paths.
A team shipping a meaningful share of its code through AI assistance eventually meets the statistics, and the statistics are bad enough to demand a response. Shutting the tooling down costs the velocity that made it worth adopting. Waving the numbers away keeps the exposure. The research behind the headlines has earned the attention it gets, with large samples, published methodology, and findings that have held up under scrutiny.
Most articles on the subject narrow at the fix. Study after study identifies why models produce insecure code, then recommends mitigations that operate on code after generation, which leaves the diagnosed cause sitting exactly where it was found. Here, we will cover the real per-language numbers, the root causes behind AI-generated code security risks, and what closes the distance between an accurate diagnosis and a durable remedy.
Just How Risky Is AI-Generated Code: The Real Numbers
Veracode’s analysis of more than 100 large language models across 80 coding tasks, four programming languages, and four vulnerability types found that only 55% of AI-generated code was secure. That figure has barely moved across successive model generations while functional correctness improved sharply. A newer or larger model writes cleaner code and arrives with the same security posture as the one it replaced.
The pattern carrying those numbers into production is vibe coding: fast, informal AI-assisted building, named as such in the same analysis. Used to find out whether an idea works, it earns its keep. Vibe coding security becomes a live exposure when that work ships and no structure gets added behind it. AI code security vulnerabilities also tend to arrive without a clear owner, which delays remediation and leaves security debt, meaning unresolved software flaws that persist for over a year after being identified.
The table below breaks the AI-generated code security risks down by language and by CWE, the public catalog of software weakness types. Every figure is the share of generated code that came out secure, from Veracode’s 2025 GenAI Code Security Report.
Category | Measurement | Secure-Code Rate |
|---|---|---|
By language | Python | 62% |
By language | JavaScript | 57% |
By language | C# | 55% |
By language | Java | 29% |
By vulnerability type | SQL injection (CWE-89) | 80% |
By vulnerability type | Cryptographic failures (CWE-327) | 86% |
By vulnerability type | Cross-site scripting (CWE-80) | 14% |
By vulnerability type | Log injection (CWE-117) | 12% |
Overall | 100+ LLMs, 80 coding tasks, 4 languages | 55% |
Category
By language
By language
By language
By language
By vulnerability type
By vulnerability type
By vulnerability type
By vulnerability type
Overall
Measurement
Python
JavaScript
C#
Java
SQL injection (CWE-89)
Cryptographic failures (CWE-327)
Cross-site scripting (CWE-80)
Log injection (CWE-117)
100+ LLMs, 80 coding tasks, 4 languages
Secure-Code Rate
62%
57%
55%
29%
80%
86%
14%
12%
55%
Three Categories of Risk, Not Just One
Vendor research tends to collapse this subject into a single question about output quality. Georgetown’s Center for Security and Emerging Technology (CSET) separates it into three.
The first is the model generating insecure code directly, which is the category almost all commercial research examines to the exclusion of the other two. The second is the model itself becoming a target, including prompt injection, where crafted input overrides the instructions a model was given so that it produces compromised output. Third comes downstream systemic risk: insecure AI-generated code lands in public repositories, those repositories feed the training data for future models, and the weakness propagates forward. That last one operates as a feedback loop rather than a single event.
CSET closes on a point worth carrying into any internal discussion of this. Responsibility here should not rest solely on the individual developers using the tools. It sits across the AI developers building them, the organizations deploying code generation at scale, and the industry standards both answer to.
Why AI Models Generate Insecure Code
Within the first of CSET’s three categories — the model writing insecure code directly — the same Veracode research that produced the numbers above identifies three drivers, and they compound.
Training data contamination comes first. Models learn from public repositories holding secure and insecure implementations side by side, and seeing both teaches the model that both are valid solutions. Second is a lack of security context: models generate code with no deep understanding of the specific application’s security requirements, its business logic, or the architecture it runs inside. The third driver is limited semantic understanding. Working out whether a variable holds user-controlled data requires interprocedural dataflow analysis, which current models cannot perform reliably.
The second driver is the one this article follows to its conclusion. In ordinary terms, a lack of security context is a context engineering problem, which is a question of what a coding agent knows about the security requirements of the specific system it is working in, as distinct from the general patterns it absorbed during training. The model was never handed information it needed.
One more pattern is worth adding, offered as observation and not measurement: common, well-represented code paths tend to come out reasonably secure, while the harder and less-common cases concentrate the failures. Call it the 80% problem. The edges are precisely where the context gap shows, and precisely where security debt accumulates. We have written elsewhere about why AI-generated code breaks in production.
Catching It vs. Preventing It: Where Most Existing Guidance Stops
Read across current guidance on this subject and the recommended mitigations converge. Static application security testing (SAST) reads source code for known weakness patterns. Dynamic application security testing (DAST) probes the running application. Software composition analysis (SCA) inventories third-party components and flags the ones with published vulnerabilities. Every one of these is a genuinely necessary tool and the correct tool for its job.
Every mitigation in that list also addresses AI-generated code security risks after the code exists. A scanner recognizes a vulnerability pattern that has already been written into a file. Supplying the security context the model lacked at generation time is outside what any of them can do, so the condition named in the research stays open for the next commit.
We know the limits of that tooling from having built it. We took Phoenix Security from the initial idea through release as its sole development provider. The UK vulnerability management platform now serves 380+ international companies, running a risk-reduction process 12x faster and at 7x lower cost than competing tools.
Treating security context as an input to development, with the scan waiting as the check at the end of it, is the approach that holds up as volume grows. The economics of that decision sharpen considerably once a prototype starts taking real traffic, which is the territory covered in our piece on the risks of scaling AI MVP development.
Giving Coding Agents the Security Context They’re Missing
The question of how to secure AI-generated code lands upstream, in three places a team already controls.
Security requirements can be written down as explicit inputs before an agent generates anything. What data counts as sensitive, what needs sanitizing, which access controls apply to which surface — all of it belongs in the specification, receiving the same discipline any functional requirement gets. This is spec-first development, where the specification is authored and agreed before implementation starts, and it is how secure-by-design stops being a slogan: security properties get decided at design time, when changing them is still cheap.
For the underlying discipline behind giving agents explicit, upfront requirements, see our guide to spec-first development.
Then there is the harness, the configuration surrounding a coding agent. A harness carries explicit, persistent security rules and can route sensitive code down a stricter review path automatically, which spares the agent from inferring case by case what matters. The mechanics of this run deep, and we cover them separately in our work on agent harness engineering.
Third is calibrated autonomy, a framework we use at SPD Technology rather than an industry-standard term. Authentication, payments, and anything touching personal data stay under mandatory human review no matter how reliable an agent has proven on routine work, because a security mistake on those paths costs something categorically different from a broken feature.
Serhii Leleko
AI & ML Engineer at SPD Technology
“An agent implements the threat model you wrote down and nothing you assumed. Authentication gets specified constantly; authorization almost never does, because to a human reviewer the second one looks like part of the first. The agent has no reason to make that inference, so the gap is already sitting in the specification long before it reaches the code.”
Independent Review: Why a Scan Alone Isn’t Verification
An unstated requirement is also invisible to the tool most teams rely on to catch it. An automated scan compares code against a catalog of known vulnerability patterns and reports matches. That work is genuinely valuable, and the CWE-indexed categories in the table above describe exactly what it was built to find. Judging whether an agent made a sound security decision in a situation the scanner’s rules never anticipated sits outside that capability.
The distinction resembles the one between tests and evals. A test is deterministic: the pattern appeared or it did not, and the answer is the same every run. Assessing whether an agent’s approach to a novel, context-specific security decision was defensible works differently, closer to an evaluation than to a pass-fail check. Our thinking on how to evaluate AI agents before production goes further into that.
Which leads to independent review: examination by a human or a separately-postured AI with no stake in the code already being correct. Whoever wrote a piece of code, human or agent, should not be its only check, and a single automated tool should not be either. Independent review catches a category of problem that neither a scan nor a self-check is built to surface.
A Practical Security Checklist for AI-Generated Code
An AI code security checklist earns its place when it covers both halves of the problem. The credited scanning practices belong here, and so do the upstream governance practices, with each covering ground the other leaves open. One term the rows use needs defining first: package hallucination is an AI coding tool referencing a software dependency that does not exist, generated because the name sounded plausible.
The rows below map AI-generated code security risks in the order a team should work through them, and they pair well with our broader AI production-ready checklist.
✓ | Practice | Layer | What It Catches |
|---|---|---|---|
⃣ | Automated scanning (SAST/DAST/SCA or equivalent) runs on AI-generated code before deploy | Downstream | Known vulnerability patterns matching cataloged categories (SQL injection, XSS, and similar) |
⃣ | AI-suggested dependencies are verified to actually exist and be legitimate | Downstream | Package hallucination and the malicious packages attackers register against invented names |
⃣ | Security requirements are defined as explicit input before code is generated, not inferred afterward | Upstream | The root-cause context gap — the model isn’t guessing at requirements nobody stated |
⃣ | Sensitive code paths (auth, payments, personal data) have dedicated, stricter review rules | Upstream | Higher scrutiny where the cost of a mistake is highest, rather than uniform treatment everywhere |
⃣ | High-risk code requires independent review, not self-review by the same agent or process that wrote it | Upstream | Context-specific judgment errors a pattern-matching scanner has no way to evaluate |
⃣ | An audit trail records what was checked, by what method, and by whom | Upstream | Claims about security posture can be verified, not just asserted |
✓
⃣
⃣
⃣
⃣
⃣
⃣
Practice
Automated scanning (SAST/DAST/SCA or equivalent) runs on AI-generated code before deploy
AI-suggested dependencies are verified to actually exist and be legitimate
Security requirements are defined as explicit input before code is generated, not inferred afterward
Sensitive code paths (auth, payments, personal data) have dedicated, stricter review rules
High-risk code requires independent review, not self-review by the same agent or process that wrote it
An audit trail records what was checked, by what method, and by whom
Layer
Downstream
Downstream
Upstream
Upstream
Upstream
Upstream
What It Catches
Known vulnerability patterns matching cataloged categories (SQL injection, XSS, and similar)
Package hallucination and the malicious packages attackers register against invented names
The root-cause context gap — the model isn’t guessing at requirements nobody stated
Higher scrutiny where the cost of a mistake is highest, rather than uniform treatment everywhere
Context-specific judgment errors a pattern-matching scanner has no way to evaluate
Claims about security posture can be verified, not just asserted
A team checking only the downstream rows has a scanning practice, which is necessary and incomplete. The upstream rows are the ones that reach the root cause the research itself identifies, and they are where most teams still have ground to cover.
Our Expertise
One of our long-standing clients operates a well-known US tourist attraction’s ticketing platform. We replaced a ten-year-old monolithic ticketing system there with a microservices architecture, producing a 3x performance improvement and API response times under 1.5 seconds. The work is that client’s second consecutive engagement with us.
The governance detail matters more here than the architecture. The pipeline includes a dedicated, more rigorous review profile applied specifically to payments and personal-data-adjacent code, on top of the standard mandatory review every AI-generated change already passes through. Sensitive surfaces get a higher-scrutiny path built into how they are handled from the first commit, and the scan still runs at the end of it.
Three practices hold that together. Security requirements are defined as part of the specification before implementation begins, which puts them in front of the agent at the moment it needs them. Independent review is standard for every AI-generated change, with the stricter profile reserved for sensitive surfaces specifically. An audit trail on every release records what was checked and by whom. The wider engineering process behind this is covered in our work on governed Claude Code development.
Key Takeaways
- Research across more than 100 large language models on 80 coding tasks found only 55% of AI-generated code secure, with results ranging from 62% in Python down to 29% in Java.
- Security performance in AI-generated code has stayed flat while models improved sharply at functional correctness, so upgrading to a newer model leaves the security gap exactly where it was.
- Credible root-cause research names lack of security context as a primary driver of insecure AI-generated code, which makes this a context engineering problem that model selection does not solve.
- Nearly every current mitigation operates downstream, scanning code after generation, which catches cataloged patterns and leaves the upstream context gap that produced the vulnerability untouched.
- AI-generated vulnerabilities often lack clear ownership, which slows remediation and lets them persist as security debt for over a year after identification.
- A scanner checks code against known vulnerability patterns and cannot judge whether an agent made a sound security decision in a context its rules never covered, so independent review catches a different category of problem.
- Responsibility for AI-generated code security is shared across model developers, deploying organizations, and industry standards, so the organizational process closes what individual developer training alone leaves open.
In short: AI-generated code security risks are a context problem, and they close — in the specification, in the agent’s configuration, and in the review path — with scanning as the safety net behind it.
FAQ
How common are security vulnerabilities in AI-generated code?
Common enough to plan around. Veracode’s systematic evaluation covering more than 100 large language models, 80 coding tasks, and four programming languages found that only 55% of AI-generated code is secure. Python performed best at 62%, with Java at 29%. The rate varies sharply by vulnerability type: SQL injection came out 80% secure, while cross-site scripting and log injection came out secure only 14% and 12% of the time. These are AI code security vulnerabilities measured across a broad sample, not cherry-picked edge cases.
Why does AI-generated code have more security vulnerabilities than expected?
Three factors drive it. Models train on public repositories containing secure and insecure implementations together, which teaches them that both are acceptable. They generate code with no deep understanding of the specific application’s security requirements, business logic, or architecture. And determining whether a variable holds user-controlled data requires interprocedural dataflow analysis that current models cannot perform reliably. The thread running through all three is security context. Raw coding capability has improved substantially, and the security numbers stayed where they were.
Does using a better or newer AI model fix the security problem?
No. Security performance has remained largely flat across model generations even as models improved dramatically at producing functionally correct, syntactically clean code. The practical implication is that this gap closes through how the development process supplies information to the model, and model selection on its own never reaches it. A team that upgrades and changes nothing else ends up with better code that carries the same weaknesses, because the missing security requirements were never written down anywhere the model could read them.
Is running a security scanner enough to catch AI-generated code vulnerabilities?
Necessary, and incomplete on its own. Scanners are excellent at what they do: matching code against catalogs of known vulnerability patterns, flagging vulnerable third-party components, and probing a running application for exposed behavior. Two things sit structurally outside their reach. They cannot supply the security context a model lacks while generating the code, and they cannot judge a decision that falls outside their pattern library. The pairing that works is scanning, plus explicit upfront security requirements, plus stricter review on sensitive code.
What is package hallucination, and why does it matter for AI-generated code security?
Package hallucination is an AI coding tool referencing a software dependency that does not exist, invented because the name looked plausible. Attackers watch for the names these tools produce most often and register real malicious packages under them, so an installed hallucination becomes an installed compromise.
Research presented at the 2025 USENIX Security Symposium generated 576,000 code samples across 16 code-generating models and found hallucinated package names averaging at least 5.2% for commercial models and 21.7% for open-source ones. Checking that a suggested dependency actually exists and comes from where it claims to is what stops an invented name from becoming an installed one.
Who is responsible for the security of AI-generated code — the developer, the AI vendor, or the organization?
Responsibility is shared across all three. CSET’s framing puts responsibility across the AI developers building the models, the organizations deploying code generation at scale, and the industry standards governing both. Worth knowing alongside that: code-generation benchmarks typically score whether generated code works, and security usually falls outside what they measure. So a team relying on benchmark performance as a proxy for safety is reading the wrong signal. Training individual developers better addresses one piece of a responsibility that is genuinely shared.
How much does it cost to add a security review layer to AI-assisted development?
Most engagements of this kind run between $20,000 and $60,000, with a single-repository pilot landing below that range and a multi-team rollout above it. Four variables move the number more than anything else. How many repositories fall in scope sets the baseline. Whether any scanning practice exists today determines how much gets built versus extended. The amount of production access the agents already hold changes how much review the sensitive paths need. And installing a process from scratch costs differently from repairing one that exists and underperforms.
How long does it take to set up security governance for AI-generated code?
Reckon on 6 to 12 weeks for a full rollout, with a single-repository pilot closer to 3 weeks. The sequence determines where in that range a given engagement lands. Security requirements go into existing specification templates first, which is mostly writing and agreement work. Rules then get encoded at the level of the agent’s configuration. Last comes defining which code paths require independent review and what that review consists of.
Value starts arriving before the full process lands: once the specification work is done, the next generated feature already has requirements the agent can read.