Your AI Is Writing Vulnerable Code. Here's the Proof — and the Fix.

There is a conversation happening in engineering teams right now that nobody wants to have out loud.

The AI coding tools are fast. The velocity numbers are real. Developers are shipping features in a fraction of the time it used to take. The productivity gains are not imaginary. And yet, quietly, security teams are watching the vulnerability counts in their codebases climb in ways that do not match the story being told in the all-hands meetings.

This is not a criticism of AI tools. It is a description of a gap that the industry has not yet closed — and one that will cost real money, real data, and real trust if developers do not understand it clearly.

The Numbers That Should Make You Uncomfortable

Veracode tested over 100 large language models across thousands of coding tasks and published a finding that deserves more attention than it gets: 45% of AI-generated code introduces known security vulnerabilities. Not obscure, edge-case flaws. The OWASP Top 10 — SQL injection, cross-site scripting, broken access control — the attacks that have been well-understood for over a decade.

A separate analysis found that AI-generated code contains 2.74 times more vulnerabilities than human-written code. CodeRabbit's review of 470 open-source pull requests found AI co-authored code had approximately 1.7 times more major issues than human-written code.

Put this in concrete terms: if a 10,000-line feature written by a developer would typically introduce 10 vulnerabilities, the AI-generated version is likely to introduce 27. In a 100,000-line codebase, you are not talking about edge cases anymore. You are talking about systemic exposure.

What makes this particularly difficult is that the code looks fine. It passes linters. It passes functional tests. It handles the happy path correctly. The vulnerabilities are in the security controls that a senior developer would include by default — the ones that do not show up until a penetration tester, or an attacker, goes looking for them.

Why AI Generates Insecure Code (It's Not a Bug, It's a Design Gap)

Understanding why this happens matters more than just accepting that it does.

AI code generation models are trained to maximize functional correctness. They are benchmarked against HumanEval and similar datasets that measure whether code produces the right output. Security is not a benchmark. There is no training signal that rewards "this code correctly validates the user's authorization before touching the database." There is a signal that rewards "this code returns the correct result."

The result is code that works functionally but is missing the security controls that experienced developers embed almost unconsciously: parameterized queries instead of string concatenation, output encoding before rendering user data, least-privilege API calls, proper secret handling, session invalidation on logout. These are habits formed through exposure to breaches, post-mortems, and security training. An AI has read about these concepts, but it has no skin in the game when the breach happens at 3 AM.

A second issue is context blindness. Security vulnerabilities are often contextual. A function that is perfectly safe in one part of your system can be dangerous when the input comes from an untrusted source somewhere else. AI does not know your threat model. It does not know which endpoints are public-facing, which users have elevated privileges, or which data is regulated. It knows the code in front of it, and it writes accordingly.

The Production Incident That Made This Real

In early 2026, a popular AI coding platform generated database schemas without Row Level Security policies — meaning any authenticated user could read, modify, or delete data belonging to any other user. The vulnerability was not in a single application. It was in the platform's code generation defaults, which meant over 170 production applications were affected simultaneously.

This is the new failure mode: not one developer making one mistake, but an AI tool making the same architectural omission at scale, across every project that used a particular generation pattern.

When a human developer has a blind spot, it shows up in their code. When an AI tool has a blind spot, it shows up in every codebase that relied on it.

Eight Practical Gates That Stop This

The answer is not to stop using AI tools. The answer is to build security checkpoints into your AI-assisted workflow that are non-negotiable, regardless of velocity pressure.

1. Treat AI-generated code as untrusted input. The same way you would not trust user-submitted data without validation, do not trust AI-generated code without security review. This is a mindset shift more than a process change, but it matters.

2. Run static analysis on every AI-generated PR. Tools like Snyk, Semgrep, and SonarQube are table stakes. They will not catch everything, but they will catch the category of vulnerabilities — injection flaws, insecure dependencies, hardcoded secrets — that AI generates most frequently.

3. Never let AI generate authentication or authorization logic without senior review. These are the highest-stakes parts of any system. They are also the parts where AI is most likely to produce code that is functionally correct but security-broken. Make this a hard rule in your team, not a guideline.

4. Check for secrets exposure explicitly. AI will sometimes generate code with hardcoded API keys, database credentials, or tokens in places that get committed to version control. Run a secrets scanner — GitGuardian, TruffleHog — as part of your CI pipeline.

5. Review Row Level Security and data access patterns. Who can read what? The authorization logic at the data layer is often the last thing a developer thinks about and the first thing an attacker exploits. If AI generated your database schema or your ORM queries, audit the access patterns manually.

6. Prompt for security explicitly. Telling an AI "write a login function" produces different code than "write a login function that prevents timing attacks, uses constant-time comparison, rate-limits attempts, and logs failures." The model will include security controls if you ask for them. Most developers do not ask.

7. Build a "no-AI sandbox" for security-critical paths. Some code should be written by humans, full stop. Cryptographic implementations, payment flows, regulated data handling — these warrant the extra time. Speed is not worth the liability.

8. Track your vulnerability trend line, not just your feature velocity. If your team is shipping 3x more features but your security findings are up 10x, the math is not in your favor. Measure both.

The Bottom Line

The AI tools are not going away, and the productivity gains are genuine. But right now, the industry is running a silent experiment: shipping AI-generated code at scale while hoping that the security debt does not come due.

It will come due. The only question is whether you are the team that discovers the vulnerability in a code review, or the team that discovers it in a post-mortem.

Build the gates now. They take less time than you think, and they cost less than the alternative.