AI-Generated Code Security Risks: What Your Tools Aren’t Telling You About Vulnerable Code

Those AI coding tools are fast, and your developers love them. But somewhere in all that AI-generated code, there’s a security vulnerability that slipped through code review.

Key Points

• Security risks are often the result of missing context.
• AI-generated code can introduce injection flaws, XSS, auth gaps, and unsafe data handling.
• AI tools amplify supply chain risk through unsafe or hallucinated dependencies.
• Human review, SAST, SCA, DAST, policy, and audit trails all matter more when AI is in the SDLC.

AI Coding Tools and Security Vulnerabilities

What happens when you hand a confident new developer a codebase they’ve never seen and ask them to write security-sensitive code? You get software that potentially has multiple attack vectors, and that isn’t necessarily using the common libraries the way the team has decided to. For a human, it takes time to learn your auth model, data classification rules, and your threat model.

AI tools are just like that newly-hired developer, except they’re doing it faster and confident, without ever asking the important questions about your system architecture. Unlike that new hire, AI doesn’t raise its hand in standup and say, “So, how does the auth flow work here?”

Most security issues can be traced to three root causes, and they’re all structural. Unfortunately, these issues persist regardless of larger context windows and newer models.

The Training Data Problem

Training is one of the few things human engineers and LLMs have in common. Unfortunately, when we are trained on insecure patterns, we’re likely to keep falling back on them. LLMs suffer from this explicitly: public repositories and Stack Overflow, where insecure approaches to programming are common. The Cloud Security Alliance put it to the test and confirmed the insecure nature of the training data.

Additionally, LLMs reproduce patterns without reasoning about security. LLMs lack operational experience and a deep understanding of your security context, so they can (and do) reproduce risky patterns.

Context Gaps and LLM Inference

You may think this is a model-quality problem, but it’s not. The proof can be seen in Veracode’s 2025 GenAI Code Security Report. They tested a large set (over 100) of large language models on their security performance. The results, at least to me, were surprising: performance was flat regardless of model sophistication.

Regardless of which frontier model you’re using, the security vulnerabilities you get remain the same. It sounds counterinuitive, but the bigger model doesn’t know your organization’s authentication scheme or that your payment service has different input validation rules than your user profile service. The problem is context.

Fluency Bias

This is the one that makes me nervous. The generated code looks right, plausible at first glance.

Apiiro’s research found that syntax errors dropped 76% and logic bugs fell by over 60% with AI-assisted development compared to pre-AI. The unfortunate larger picture is that privilege escalation paths and architectural flaws spiked by 322% and 153%, respectively. The surface got “cleaner”, but the foundation weakened under our feet.

The Scary Truth

• Veracode found that 45% of AI coding tasks introduce at least one OWASP Top 10 vulnerability. That’s nearly a coin flip.
• AI-generated code is 2.74 times more likely to contain security vulnerabilities than human-written code.
• 96% of developers don’t fully trust AI output, yet only 48% always verify it before committing (Sonar, 2026).

Pull Requests and Their Security Risks

Now that we’ve established that security risks are spawning along with AI-generated code, it would be good to know what types of these risks are presenting themselves. The short answer? OWASP Top 10 issues. These are the most advertised and studied vulnerabilities out there, and the AI-generated code is littered with them. Let’s take a look at the biggest risk types.

• Injection flaws. We’re talking about SQL injection, command injection, and log injection. Veracode found AI models failed to guard against log injection 88% of the time. To add to that, generated Java was the worst offender at 72% across all injection categories. The code is technically valid, and not secure, and that’s scary. Usually, we guard against injection flaws with input validation, but AI tends to skip that guard code way too often.
• Cross-site scripting. AI models failed on XSS defenses in 86% of cases. Again, this is syntactically correct output that renders user input without proper escaping. Perfectly functional, but wrong.
• Broken authentication and authorization. ZeroPath calls it bluntly: “Authorization bugs are having their SQL injection moment.” Case in point: I had an AI tool generate what looked like a clean admin endpoint for a team I was working with. Proper routing, solid request validation, and good error handling. One problem: no ownership check. Any authenticated user could hit it. The AI didn’t know our authorization model existed because nobody told it (and, let’s be real, nobody was going to paste the entire RBAC config into a prompt). After that incident, we introduced a hard rule: mandatory human review for anything touching auth. Nobody gets to say “the AI handled it.”
• Hardcoded credentials and secrets. GitGuardian’s 2026 State of Secrets Sprawl found 29 million secrets leaked on public GitHub in 2025, up 34% year over year, and AI service credential leaks were up 81%. The crux of the issue is that developers exposed credentials nearly twice as often as those writing code manually when they used AI.
• Crypto misuse and unsafe file handling. I’ve seen AI-generated code default to ECB mode for AES encryption in minimal examples (the one mode your security team tells you never to use). Path traversal, insecure temp files, weak randomness: they all show up regularly, and they’re the kind of security flaws that look fine at a glance. These types of issues can wreck your compliance audit.

Software Supply Chain: AI as an Attack Surface Amplifier

Dependencies and libraries are the all-too-often security attack vectors we willingly import into our projects.

Without proper software development discipline, it is easy to reach for packages with known security issues, both unintended and malicious. Larger coding shops have regulatory requirements for software bills of materials, which leads to careful examination of these dependencies, and subsequent use of security testing tools, both static and dynamic (i.e., SAST and DAST). The reality is that not every team has the bandwidth or inclination for this rigor, and AI tools import dependencies into your codebase without a care in the world. Every dependency is an attack surface, and your AI coding tools are adding them at a rate that should concern you.

Endor Labs’ 2025 State of Dependency Management Report put real numbers on this. 80% of AI-suggested dependencies contained some form of risk. Only 1 in 5 were safe to use, and nearly half had known vulnerabilities. And to top it off, AI suggested using dependencies 34% of the time for ones that didn’t exist in public registries. AI hallucination at its worst.

That leads to slopsquatting, a term gaining traction, where people register package names as potential security traps. This USENIX study of over 576,000 generated code samples found that roughly 20% of recommended packages didn’t exist, and, interestingly, 43% of those hallucinated names repeated consistently across queries. That’s predictable, which means exploitable.

Security researchers proved this with a simple experiment by registering an AI-invented package name (huggingface-cli) on PyPI and sat back. In just three months, they watched developers download and install it 30,000 times. The AI just kept recommending it, and developers kept installing it.

There’s also the provenance problem that nobody tends to think about. AI-generated code carries no chain of custody. Your software composition analysis (SCA) tooling can trace a traditional dependency back to its maintainer. AI-generated code patterns don’t generally support this chain. You’re trusting your AI’s training data. Most teams I’ve started working with haven’t even thought to see if their SCA tooling can flag a package that doesn’t exist in any registry.

Security Debt at Machine Speed: The Organizational Impact

Let’s look at an unfortunate truth for many teams. AI coding tools increase your PR volume, your code volume, and your security finding volume. Review capacity stays flat. Without an increase in capacity, something has to give, and thoroughness is what suffers.

Apiiro’s data tells another troubling story. By mid-2025, AI-generated code had introduced over 10,000 new security findings per month, a 10-fold increase in just six months. Teams with high AI adoption saw 98% more PR merges alongside 154% larger PRs. You would think that this increase in volume meant a higher rate of feature completion and bug fixes. It did not, as the findings showed only a 21% increase in completing actual tasks.

The AppSec team is hit the hardest. One engineer was barely able to triage thousands of SAST findings, and thanks to AI the same team is producing thousands more. Regardless of whether those findings are exploitable, there is a mass scaling of noise for that AppSec engineer.

Security Controls That Actually Catch AI-Generated Code Vulnerabilities

Security controls for mitigating AI-generated code security risks aren’t new. They’re the ones you already have for human code and they need to be enforced consistently.

• Human review is non-negotiable for anything touching authentication, cryptography, input validation, or sensitive data. No static analysis tool on the market catches errors or missing code in your business logic. A seasoned human on your team should.
• SAST (static analysis) catches pattern-based security vulnerabilities: injection flaws, XSS, and known insecure patterns. The weakness in SAST is that default rulesets miss framework-specific anti-patterns common in AI-generated code. You need to tune your rules for your frameworks.
• SCA (software composition analysis) needs to handle slopsquatting potential as a first-pass filter. Most legacy tools were built before AI models started hallucinating package names. If your SCA tool still assumes every import exists in a registry, it’s not built for AI-assisted development.
• DAST (dynamic testing) catches what static analysis misses: broken auth flows, session handling, and cross-site scripting in rendered templates. If you’re relying only on static analysis, then you’re open to vulnerability categories commonly generated with AI tools.
• Policy and guardrails. This is the security control most teams skip and then regret. Establish an approved tool list. Restrict sharing sensitive code with public AI models. Require secure-prompt elements when working in security-sensitive areas. If your AI usage policy isn’t written down, it doesn’t exist.
• Audit trails. Retain prompts and outputs tied to pull requests where feasible. When (not if) a security incident traces back to AI-generated code, you need the forensic trail.

My mantra is: treat AI-generated code as untrusted SDLC input. You must adhere to the same rigor around scanning, review, and approval gates. Yes, this slows things down, so staff for it.

AI-Related Security Risks in Regulated Environments

Now let’s talk about the un-fun part of AI-assisted development: compliance audits, evidence collection, and explaining to auditors why 50% of the codebase doesn’t have the same attribution trail as it did in early 2024. I’ve had three of these conversations over the last year or so, and they tend to cover the same points.

When SOC 2, ISO 27001, HIPAA, or PCI-DSS are a part of your landscape, AI-generated code tends to make life harder for auditors and engineers responsible for meeting those stringent controls. The headaches just compound with the increased volume of security risks associated with larger batches from AI-generated code (154% larger PRs, remember), with less attribution, and with potential security risks traditional change management wasn’t designed for.

Evidence and Traceability Concerns

ISO 27001:2022 requires change control evidence. That applies to pull request records, deployment logs, or equivalent artifacts. This also applies to every AI-assisted change, since they need the same audit trails as human-written code. I tell every team in regulated environments the same thing: your AI usage policy is now an auditable artifact.

As someone who leads, consults, and generates code, I can safely say that this extra burden takes quite a bit of the “fun” of AI coding out, but when I can’t show an auditor how that generated code flows through the security controls, that is a conversation both uncomfortable and unacceptable.

Access Controls and Data Handling

Protecting PHI and PCI data in prompts is crucial, especially when using external AI models. Researchers studying vibe coding applications found hundreds of exposed PII instances (including medical records) in deployed apps. In a HIPAA environment, that’s a reportable incident. Potentially a very expensive one, too.

Where AI Is Lower Risk and Where It Isn’t

Let’s boil it down to the the basics. Here’s the guidance I give to engineers on my team:

Lower risk (with scanning and human review): boilerplate, scaffolding, internal utilities, test fixtures, documentation. Minimize the chance that the code contains a security flaw that is unlikely to be directly exploitable in production.

High risk (mandatory human review, security scanning, and thorough testing): authentication, authorization, cryptographic operations, request parsing, deserialization, anything touching sensitive data, or processing user input.

Useful Development Cycle Metrics

Measuring if your software development process is keeping pace with AI adoption or building security debt. Track these:

• SAST and SCA hit rate by AI-generated versus human-written code.
• Time-to-fix for AI-introduced security vulnerabilities.
• Vulnerability recurrence in AI-touched modules.
• PR volume versus review capacity.

Is The Risk Worth It?

I have worked with software crews where critical security issues went to production, exacerbated by AI tools. The people are solid, but the software engineering game has changed at a rapid pace.

The unfortunate reality is that the AI-generated code looks too good and passes the smell test. That led to a massive increase in PR volume and the code in each of those PRs. Thus, stressing the resources and discipline around the validation and verification of that code. And, the associated AI security flaws were functional code. That’s what makes this hard.

These tools aren’t going away. We just need to adapt to their use. Those with the foresight or at least the ability to learn from mistakes will stay successful, and that includes handling AI code security. But the ones who treat AI-generated code as trusted output will suffer.

AI has changed the game, and security and compliance need to keep pace. Auditors and upper management don’t have the pocketbooks or patience to deal with an undisciplined engineering team.