Here's a scenario playing out in engineering teams right now. A developer uses Claude Code or Copilot to ship a feature in two hours instead of two days. It works. Tests pass. It gets merged. Nobody looks too closely, because it looks fine, the code is clean, it's readable, it does what it's supposed to do.
Three months later, a security researcher finds a SQL injection vulnerability sitting in that endpoint. Or an API key gets exfiltrated through a malicious project config file. Or a user discovers they can access records that aren't theirs because nobody validated the input.
The code wasn't obviously bad. It just wasn't secure. And the team had no process in place to tell the difference.
This is the AI code security problem in a nutshell and it's more structural than most coverage suggests.
So is AI code actually less secure?
The short answer is: For the time being, yes, measurably, and in specific ways.
Veracode's 2025 GenAI Code Security Report is one of the most comprehensive studies on this. They tested over 100 large language models across 80 real-world coding tasks in Java, Python, C#, and JavaScript. The headline finding: 45% of AI-generated code introduced security vulnerabilities classified within the OWASP Top 10, the industry's standard list of the most critical web application security risks.
That's nearly one in two tasks. And it didn't improve with larger models. Newer, bigger, more expensive models performed no better on security than smaller ones. Veracode's CTO called it "a systemic issue rather than an LLM scaling problem."
The specific failure rates by language make it worse. Java had a 72% security failure rate. Python, C#, and JavaScript all came in between 38% and 45%. Cross-site scripting vulnerabilities appeared in 86% of relevant code samples. Log injection vulnerabilities appeared in 88%.
A separate study from the Cloud Security Alliance found 62% of AI-generated code solutions contained design flaws or known vulnerabilities, even when developers used the latest models available. Earlier research from Georgetown's CSET found approximately 40% of GitHub Copilot-generated code was vulnerable to the MITRE CWE Top 25 most dangerous software weaknesses.
These aren't fringe findings. They're consistent across multiple independent research groups over multiple years.
Why does this keep happening?
The answer isn't that AI is careless or malicious. It's more fundamental than that and understanding it matters if you want to actually fix the problem.
AI optimizes for functionality, not security
When you ask an AI coding assistant to "query the users table by ID," it is optimizing for one thing: giving you working code as quickly as possible. Security is a constraint you have to explicitly declare. If you don't mention it, the model often doesn't apply it.
A classic example from the Cloud Security Alliance: ask a model to evaluate a user-provided math expression, and it may return eval(expression), a single line that solves the problem cleanly, and also opens the door to remote code execution. The model isn't being reckless. It just found the shortest path to a passing result.
Same with SQL injection. The pattern "SELECT * FROM users WHERE id = " + user_input appears thousands of times in the training data. The model has seen it work. It produces it again.
If you want security, you have to know how to prompt for it.
The model doesn't know your threat model
This is the deeper problem. AI coding assistants train on public code at massive scale. What they don't know is anything specific about your application: who your users are, what the business logic is, what the data is worth, what your internal security standards say.
An API endpoint generated by an AI will accept input without validating, sanitizing, or authorizing it, simply because the prompt never said it needed to. The model has no way to infer that the endpoint sits in front of a healthcare database, or that the user input comes from an untrusted third-party integration, or that your compliance requirements mandate field-level encryption.
That context lives in the heads of your engineers and business development teams. It doesn't automatically transfer to the model.
It was trained on insecure code
This one is uncomfortable to sit with. The AI models generating your code were trained largely on public GitHub repositories, which contain a lot of insecure code. If an unsafe pattern appears frequently in training data, the model learns that pattern as a normal way to solve a problem.
Georgetown's CSET research goes further: training data can be deliberately poisoned. An attacker who gets malicious code into the repositories a model trains on can influence the model to produce insecure outputs in specific contexts.
This isn't theoretical, it has been demonstrated in controlled research conditions. The model generates code that looks correct and passes tests, but contains a hidden vulnerability activated by specific inputs.
Missing protections are harder to spot than broken code
The most dangerous vulnerabilities in AI-generated code often aren't things that are obviously wrong, they're protections that are simply absent. No input validation. No authorization check. No output encoding. The code does exactly what it was asked to do. It just doesn't do the things it wasn't asked to do, and those omissions are what attackers exploit.
This is what makes AI security debt different from traditional security debt. A classic developer mistake, a buffer overflow, a hardcoded credential, tends to be findable by code review. A missing access control on an endpoint, where the endpoint itself works perfectly, is much easier to miss.
The new attack surfaces nobody planned for
Beyond the code itself, AI development tools have introduced entirely new categories of security risk that didn't exist two years ago.
Check Point Research disclosed two critical vulnerabilities in Claude Code in early 2026, CVE-2025-59536 and CVE-2026-21852, that allowed attackers to achieve remote code execution and steal API credentials through malicious project configuration files. The attack vector was the CLAUDE.md file and related config mechanisms that developers share via Git repositories.
The exploit works because developers inherently trust project configuration files. They're considered metadata. They don't go through the same scrutiny as application code during reviews. But in an AI-powered workflow, those files actively control execution paths, meaning a single malicious commit to a shared repository could compromise every developer who clones it.
Anthropic patched both vulnerabilities following Check Point's disclosure. But the underlying issue, that configuration files are now code, and are being treated as if they aren't, isn't going away. It's a new trust boundary that the security community is still figuring out.
There's also the API key problem. A stolen Anthropic API key doesn't just run up your bill. It can give an attacker complete read and write access to all workspace files, including those uploaded by other developers on the same team. It can exhaust rate limits and API budgets, causing service interruption. And unlike a compromised individual machine, a compromised API key affects the whole team's shared resources.
The vibe coding problem
There's a cultural dimension to all of this that the data alone doesn't capture.
"Vibe coding", prompting your way to a working app without explicitly thinking about security, has normalized a development workflow where security is an afterthought at best. Developers who would never have skipped input validation when writing code by hand are merging AI-generated endpoints without a second thought, because the code looks clean and the tests pass.
This isn't a criticism of those developers. It's a predictable consequence of tooling that optimizes for speed and functional correctness, deployed into teams that haven't updated their review processes to account for what the tooling doesn't check.
CrowdStrike's research found that up to 90% of developers were already using AI coding tools in 2025, often with access to high-value source code. And formal governance frameworks for AI-generated code were, as of early 2026, the exception rather than the norm across most organizations.
What should you actually do about it?
None of this means stop using AI coding tools. The productivity argument is real and the direction of travel isn't reversing. But "use it responsibly" needs to mean something more concrete than a vague awareness that AI can make mistakes.
A few things that actually matter:
Treat AI-generated code like untrusted code. It should go through the same security review process as code from a new contractor you've never worked with before. Functional correctness and security correctness are two different things. Your review process needs to check for both explicitly.
Static analysis is not optional. Automated scanning tools should be running on every PR, including those containing AI-generated code. The fact that the code looks clean doesn't mean it is clean.
Add security requirements to your prompts. If you're asking an AI to build an API endpoint, tell it what the threat model is. Specify that inputs should be validated and sanitized. Ask it explicitly what security considerations it applied. You won't always get perfect results, but you'll get significantly better ones than if you say nothing.
Treat your CLAUDE.md and equivalent config files as code. They control execution paths now. They should be reviewed with the same scrutiny as your application code, especially in shared repositories.
Build a CLAUDE.md that encodes your security standards. If you're using Claude Code, use the shared config file to document your security requirements, your internal standards, and the patterns you don't want the model to use. Every lesson learned from a security review should go back into that document.
The honest version of this
AI is also, simultaneously, one of the most powerful security tools ever built. Anthropic's own research found that pointing Claude at exposed code can identify security lapses that traditional static analysis tools miss entirely, because the model reasons about code the way a human security researcher would, rather than just matching against known patterns.
An AI security startup discovered all 12 zero-day vulnerabilities in OpenSSL's January 2026 security patch. Another researcher used o3 to find a previously unknown Linux kernel vulnerability that traditional tools had consistently missed for years.
The same capabilities that make AI-generated code risky are the capabilities that make AI-powered security scanning genuinely powerful. The technology cuts both ways.
What it doesn't do is make security someone else's problem. The teams shipping AI-generated code at speed are accumulating security debt at a rate that manual review processes weren't designed to handle. Closing that gap isn't a security team problem or an AI problem. It's an engineering culture problem and the organizations that figure it out first are going to have a meaningful advantage over the ones that don't.