Summary: Why AI-written code fails differently from human-written code — insecure training patterns reproduced at scale, shortcuts that ignore security context, omitted controls, and subtle logic errors that pass review.
Sources: raw/Secure-coding-patterns/Understanding Security Risks in AI-Generated Code.md (Cloud Security Alliance); AI Code Security_ Complete Guide.md (Cycode); Best AI Code Security Solutions 2026...md (Orca)
Last updated: 2026-07-29
The root cause
“AI coding assistants don’t inherently understand your application’s risk model, internal standards, or threat landscape. That disconnect introduces systemic risks—not just insecure lines of code, but logic flaws, missing controls, and inconsistent patterns” (source: CSA).
Orca puts the same point as an incentive problem: “The assistant optimizes for code that runs and looks plausible, not code that is safe, and it does this thousands of times a day across your team.”
CSA’s four risks
1. Repetition of insecure patterns from training data. “If an unsafe pattern—such as string-concatenated SQL queries—appears frequently in the training set, the assistant will readily produce it.” The worked example:
sql = "SELECT * FROM users WHERE id = " + user_input
Returned “because that pattern appeared thousands of times in GitHub repos.”
2. Optimization shortcuts that ignore security context. “When prompts are ambiguous, LLMs optimize for the shortest path to a passing result, even if that means using overly powerful or dangerous functions. The model isn’t incentivized to reason securely—it’s rewarded for solving the task.” Example: eval(expression) for a user-supplied math expression — solves it, opens RCE.
3. Omission of necessary security controls. “Many vulnerabilities aren’t the result of… writing ‘bad code.’ They come from missing protections like validation steps, access checks, or output encoding.” An assistant “will deliver an endpoint that accepts input without validating, sanitizing, or authorizing the payload simply because the prompt never said it needed to.”
4. Subtle logic errors. The most dangerous, because “the code looks correct and might even pass some basic checks.” CSA’s example is worth keeping:
An assistant might write
if user.role == "admin"instead ofif "admin" in user.roles. “The code works for single-role users but fails when users have multiple roles, leading to overly permissive access in some workflows.”
That is an authorization bypass introduced by a plausible-looking refactor. No linter fires; the tests probably pass.
Why scanners under-cover it
Orca: “None of these trip a linter because the code is syntactically correct. They are logic flaws.” Cycode adds that “many vulnerability patterns are missed by legacy SAST tools.”
The recurring clusters Orca names:
- Missing input validation
- Injection-prone queries
- “Broken authentication or authorization checks where the generated handler never verifies who is calling”
The numbers, and how much to trust them
| Claim | Source | Provenance |
|---|---|---|
| 62% of AI-generated code solutions “contain design flaws or known security vulnerabilities,” even with the latest models | CSA, citing arXiv 2502.11844 | Academic; CSA cites it second-hand |
| Hallucinated packages in 5.2% of commercial-model and 21.7% of open-source-model outputs | Orca, citing USENIX Security 2025 (Spracklen et al.) | Academic, 576,000 samples — see slopsquatting |
| 2.7× higher vulnerability density than human-written code | Cycode | Vendor claim, no citation given |
| 97% of organizations using or piloting AI coding assistants; all surveyed had AI-generated code in their codebases | Cycode 2026 State of Product Security Report | Vendor survey |
Three of the four sources in this collection are vendor marketing with product CTAs embedded. The two academic figures (62%, and the slopsquatting rates) are the load-bearing ones; the density and adoption numbers should be cited as vendor claims or not at all.
Two structural problems beyond individual flaws
Reduced human oversight. Cycode: “Natural-language AI coding assistants have transformed developers from code authors to code reviewers… A developer is assumed to have thought through each line of code when it comes to a pull request, but what happens if an AI agent writes the entire feature, chooses dependencies, and submits a PR?”
Architectural drift. Orca: “When generation happens commit by commit with no one holding the whole design, codebases accumulate duplicated logic, inconsistent authentication patterns, and security controls applied in one path but not another.”
Drift is the one no scanner catches, because every individual commit is fine. It is the code-level analogue of the multi-turn problem: the unit of analysis is wrong.
Shadow AI. Cycode: developers “onboarding new AI models, integrating them into MCP servers, and leveraging various coding assistants, creating a vast, invisible landscape of AI tools across every phase of the SDLC.” Without an inventory, “there can be no meaningful enforcement of security controls.”
The framing that makes this tractable
All four sources converge on one instruction: treat AI-generated code as untrusted third-party input.
- Orca: “treating the output of an assistant as untrusted input… you scan and review it like any other risky source.”
- Checkmarx: “AI-generated code should be treated like any other untrusted external input.”
- CSA: assistants are “introducing untrusted code into your environment.”
This is exactly OWASP LLM05 Improper Output Handling applied to the developer’s own workflow — model output flowing into a system that trusts it. The difference is that here the downstream system is your production codebase.