AI-Generated Code Is Riskier Than You Think

TL;DR

AI coding tools produce vulnerable code nearly half the time — and improving model capability hasn’t changed this rate.
The bigger threat isn’t bad code in isolation. It’s bad code deployed at speed, bypassing every review gate that existed before.
A new attack class — “slopsquatting” — lets attackers exploit AI hallucinations to poison your supply chain without writing a single line of malware.
There’s a viable security posture. But it requires treating AI output as untrusted input, not a trusted shortcut.

Should You Even Use AI-Generated Code in Production?

This isn’t a binary question, and anyone who tells you “never” or “always” isn’t being honest with you. The answer is contextual. Here’s the actual decision framework:

⚡ Decision Gate — AI Code in Production

Use AI code if:

Every PR goes through automated SAST scanning
You have a dependency audit pipeline that checks AI-suggested packages
The code is in low-sensitivity, non-auth, non-data paths
A security-literate engineer reviews the output
You’re using it for prototyping, not moving straight to prod

Pause or avoid if:

You ship from AI prompt to production without review
Your team treats “it runs” as “it’s safe”
The code handles auth, payments, PII, or permissions
You’re in a regulated industry without formal code audit requirements
No one on the team can read and audit what was generated

The Problem No One Is Framing Correctly

The conversation about AI code security has been dominated by a single data point: 45% failure rate on security benchmarks. That number is real, sourced, and alarming. But fixating on it misses the more dangerous dynamic at play.

Every senior engineer who spent years shipping software will tell you: bugs have always existed in human-written code. The difference was never zero vulnerabilities — it was the friction between writing bad code and that code reaching production. Code review caught things. Static analysis caught things. Slow iteration cycles gave teams time to think.

AI tools have dissolved that friction. What OX Security found when analyzing over 300 software repositories — including 50 using tools like GitHub Copilot, Cursor, and Claude — was that AI-generated code is not necessarily more vulnerable per line than human-written code. The problem is speed. Bottlenecks including code review, debugging, and team-based oversight have been largely removed.

⚠ The Core Insight

Speed that compresses a two-week sprint into two days also compresses the security review that would have happened in those two weeks into nothing. The risk multiplier isn’t just the vulnerability rate — it’s that rate times the acceleration.

This article breaks down what the data actually shows, which threat classes are genuinely new, and what a functional security posture looks like for teams that aren’t willing to stop using AI tools.

The Four Risk Classes That Actually Matter

👉 In one sentence: AI code failures cluster into four categories — some are old vulnerabilities wearing new clothes; one is entirely novel and currently under-defended.

1. Classic OWASP Vulnerabilities, at Scale

Veracode’s 2025 GenAI Code Security Report is the most rigorous study on this to date. They tested over 100 LLMs across 80 real-world coding tasks — tasks specifically designed around the MITRE Common Weakness Enumeration system. The result: 45% of all code samples introduced OWASP Top 10 vulnerabilities. Cross-Site Scripting (CWE-80) had an 86% failure rate. Java emerged as the highest-risk language for AI code generation.

Source: Veracode 2025 GenAI Code Security Report — data last verified May 2026

What’s damning isn’t the percentage alone — it’s the trajectory. Despite frontier models improving dramatically on syntax, grammar, and general reasoning, their security performance has remained flat. Better models write cleaner-looking code that fails security checks at roughly the same rate as older ones.

2. The Volume Multiplier Problem

Apiiro’s research across Fortune 50 enterprises found something the benchmarks undercount: AI tools don’t just introduce vulnerabilities — they scale them. Their data showed a 322% increase in privilege escalation paths in codebases using AI tools, a 153% increase in design flaws, and a 40% jump in secrets exposure (API keys, tokens, and credentials embedded in generated code).

Design flaws are particularly hard to catch because they’re not syntax errors. They’re architectural decisions that look correct in isolation but create attack surfaces when combined with other system components. Static analysis tools aren’t built to catch these.

3. Secret Leakage and Over-Permissive Configurations

Repositories using GitHub Copilot show a 40% higher rate of secret leakage compared to those without AI assistance, according to GitGuardian. This isn’t because the models are intentionally writing secrets into code — it’s that AI tools trained on open-source repositories learned patterns from code that included hardcoded credentials. They reproduce those patterns confidently, and developers who aren’t auditing for secrets accept them.

A separate but related issue: AI tools consistently generate IAM policies, permission configurations, and access controls that are over-permissive. They optimize for “code that works” rather than “code that works with minimum necessary access.” In cloud environments, this regularly produces configurations that would fail any security review — if the review ever happened.

4. Slopsquatting — The Genuinely New Threat

👉 In one sentence: AI tools hallucinate package names that don’t exist; attackers register those exact names with malicious payloads and wait for developers to install them.

This is the attack class that deserves the most attention, because it’s architecturally new and conventional defenses weren’t designed to catch it.

A 2025 study published at USENIX Security analyzed 576,000 code samples across 16 LLMs. Nearly 20% of recommended packages did not exist in any public registry. Commercial tools like GPT-4 hallucinated at roughly 5%; open-source models ran significantly higher. Critically, 43% of hallucinated package names repeated consistently across multiple prompts — they’re not random. They’re predictable.

Security researcher Seth Larson coined the term “slopsquatting” in April 2025: attackers register malicious packages under AI-hallucinated names on PyPI and npm, then wait. No phishing. No credential theft. No zero-day. Just waiting for the statistical inevitability of a developer accepting an AI suggestion without checking whether the package exists.

According to Endor Labs’ 2025 State of Dependency Management report, only one in five dependencies proposed by AI coding tools meet safety standards — meaning 80% introduce risk through known vulnerabilities, hallucinated packages, or unclear provenance.

The AI Code Risk Assessment Framework

⚙

Trendix Risk Matrix — AI Code by Context

Code Context	Risk Level	Primary Threat	Minimum Gate
Auth / session management	Critical	Broken auth logic, token mishandling	Manual security review, no exceptions
Data access / database queries	Critical	SQL injection, over-broad queries	SAST + human review + parameterized query enforcement
Third-party integrations / APIs	High	Secrets exposure, over-permissive scopes	Secret scanning on every commit
Dependency declarations	High	Slopsquatting, outdated packages with CVEs	SCA tool + manual registry verification
Input validation / form handling	Medium	XSS, injection (86% fail rate in benchmarks)	Automated SAST, DAST in staging
IAM / cloud permissions	Medium	Over-permissive roles, privilege escalation	Policy-as-code linter + CSPM tool
UI components / presentational	Lower	XSS if rendering user content	Automated scan, CSP headers
Utility functions / calculations	Lower	Logic errors, edge case mishandling	Unit test coverage

How the Attack Surface Actually Works in Practice

Abstract risk classifications are useful. What’s more useful is understanding how these threats chain together in a real development workflow. Here’s what a typical vibe-coding pipeline looks like — and where the actual exposure points are:

Developer prompts an AI coding assistant with a natural language description: “Add a user login endpoint with JWT authentication.” The AI generates a full implementation — syntactically correct, plausible-looking.

The model suggests dependencies. Some exist; some don’t. Hallucinated package names like fastapi-jwt-middleware or auth-helper-utils appear alongside real ones. Without a registry check, they all look equivalent.

Developer accepts and installs. A package under that hallucinated name — registered by an attacker months ago in anticipation — gets pulled from PyPI or npm. It runs. Nothing breaks. The compromise is silent.

The generated auth code itself contains flaws — perhaps weak token validation, predictable secrets, or an over-broad session scope. These pass cursory review because the code is readable and functional.

Code ships to production. In a team using AI tools without a formal security gate, the path from prompt to production can be measured in hours. The vulnerability ships with it.

The MCP configuration attack surface. In agentic development environments, prompt injection attacks through configuration files (like the “Rules File Backdoor” disclosed in GitHub Copilot and Cursor in 2025) can manipulate the AI itself — turning the assistant into a vector for producing malicious output that looks legitimate.

A large-scale scan of 5,600 publicly deployed applications built with AI coding platforms found 2,000 highly critical vulnerabilities, 400 exposed secrets including API keys and access tokens, and 175 instances of PII — including medical records and payment data. These weren’t test environments. They were production deployments.

The Security Posture That Actually Works

👉 In one sentence: The goal isn’t to stop using AI tools — it’s to build a pipeline where AI output is treated as untrusted input, like any other external data source.

This is the mental model shift that most engineering teams haven’t made yet. AI-generated code isn’t a peer’s pull request. It’s output from a probabilistic system that has no security intent. Treating it with the same skepticism you’d apply to user-submitted form data changes how you build the tooling around it.

The 80% Solution Stack

SAST Tool

Semgrep, Snyk Code, or Veracode — runs on every PR, catches injection flaws, weak crypto, hardcoded secrets in AI output before merge

SCA Tool + Registry Check

Snyk Open Source or Socket.dev — verifies every dependency actually exists and is free of known CVEs; catches slopsquatting before install

Secret Scanner

GitGuardian or Gitleaks — scans for API keys, tokens, and credentials embedded by AI tools; integrates at pre-commit and CI

CSPM / IAM Linter

Wiz, Checkov, or AWS IAM Access Analyzer — validates that AI-generated cloud configs aren’t over-permissive; enforces least-privilege

DAST in Staging

OWASP ZAP or Burp Suite — dynamic testing catches runtime vulnerabilities that static analysis misses, especially in AI-generated auth flows

📌 Integration Type

This stack runs as a pipeline — not a checklist. SAST and secret scanning at pre-commit/PR time (native to CI/CD). SCA at dependency install time. CSPM continuously in cloud environments. DAST on every staging deployment. The friction is intentional: it replaces the friction that vibe coding removed.

For Dependency Risk Specifically

Before installing any package suggested by an AI tool, verify it manually against the relevant registry (PyPI, npm, crates.io). This takes under 30 seconds. It is the single highest-leverage action against slopsquatting. Socket.dev’s analysis of package registries found 454,648 malicious packages published in 2025 alone — the volume of the attack surface makes manual trust meaningful.

What This Posture Doesn’t Solve

Being precise about limitations matters more than overselling a framework.

Design-level flaws remain hard to catch automatically. SAST tools catch implementation bugs. They don’t catch architectural decisions that create systemic attack surfaces — the kind Apiiro found proliferating in enterprise codebases. Those require human understanding of the system, not just the code.

MCP and agentic AI tooling is a frontier. The attack surface of AI coding agents that can read, write, and execute code autonomously is still being mapped. CVE-2025-54136 (MCPoison) demonstrated that persistent code execution through poisoned agent configurations is possible. Conventional security tooling wasn’t designed for an attacker who manipulates the AI rather than the application.

AI security performance hasn’t improved with capability. Veracode’s data shows security failure rates have remained flat as model capability has increased. Better syntax doesn’t mean better judgment about secure defaults. There’s no evidence this changes in the near term without explicit security-oriented training.

Speed pressure will consistently beat security process in teams without executive mandate. The 35% of enterprise development teams already using vibe coding adopted it faster than security governance frameworks could respond. This isn’t a technical problem — it’s an organizational one.

Questions That Change How You Think About This

Is this just a problem with cheaper or older AI models?

No. Veracode tested over 100 LLMs, including frontier commercial models. The security failure rate was consistent across model generations. More capable models write syntactically cleaner code that fails security benchmarks at roughly the same rate as older ones. The problem isn’t model quality — it’s that security wasn’t a training objective.

Does using an enterprise version of an AI tool (like GitHub Copilot Enterprise) fix this?

Enterprise licensing adds data privacy protections and some additional configuration options, but it doesn’t change the underlying model’s security failure rate. GitGuardian found the 40% elevated secret leakage rate in repositories using Copilot regardless of licensing tier. The guardrails come from your pipeline, not from the vendor.

What’s the actual slopsquatting exposure for a typical development team?

A study of 576,000 code samples found roughly 20% of AI-suggested packages don’t exist. If a team generates code with AI tools daily and installs suggested dependencies without verification, the math suggests regular exposure to hallucinated package names. The attack requires an attacker to have pre-registered those names — and Socket.dev’s 2025 mid-year threat report found over 454,000 malicious packages published to public registries that year, indicating the registration activity is already underway at scale.

If we already use SAST scanning, are we adequately protected?

Partially. SAST catches implementation-level flaws — injection vulnerabilities, hardcoded secrets, weak crypto. It does not catch hallucinated dependencies (that’s SCA), design-level architectural flaws, over-permissive IAM configurations (that’s CSPM), or runtime vulnerabilities that only manifest under specific conditions (that’s DAST). SAST alone addresses roughly one category of the four risk classes described here.

Should non-developers using AI to “vibe code” apps worry about this?

More than most. The Escape.tech scan of 5,600 publicly deployed apps built with vibe coding platforms found 400 exposed secrets and 175 instances of PII in production. Non-developer builders are the least likely to have security tooling in place and the most likely to go directly from AI prompt to public deployment. If you’ve built something with these tools and deployed it publicly, a security audit is worth the cost before any significant user base builds up.

Final Thoughts

AI coding tools are genuinely useful. The productivity gains are real, measurable, and not going away. But the security conversation around them has been framed in the wrong direction — as a bug to be fixed in the next model update, rather than a structural property of how these systems work and how they’ve been adopted.

The bug-fix framing is comfortable because it implies patience will solve the problem. The structural framing is uncomfortable because it implies you need to change how your team builds software right now, while under pressure to ship faster than ever.

What’s genuinely new about slopsquatting is instructive: it doesn’t exploit a vulnerability in your code or your infrastructure. It exploits the workflow. It exploits the trust developers have placed in AI suggestions and the speed at which those suggestions get implemented. The attack surface is a process, not a codebase.

The uncomfortable truth

The teams most at risk from AI-generated code aren’t the ones using it badly. They’re the ones using it confidently — because confidence, in this context, is what removes the friction that security depends on.

Primary Sources

Secondary Sources

Help Net Security — OX Security Army of Juniors Report (Oct 2025)
Retool — The Risks of Vibe Coding: Security Vulnerabilities and Enterprise Pitfalls
Snyk — Slopsquatting: New AI Hallucination Threats & Mitigation Strategies

AI-Generated Code Is Riskier Than You Think — Here’s Why