AI-generated code is not safe by default. It behaves like untrusted input from a contractor you've never vetted, and it needs to be checked before it touches production. The single highest-priority action is enforcing automated security gates, static analysis (SAST), software composition analysis (SCA), and secret scanning, at the pull request stage. The most common high-impact failures are broken authorization logic, injection flaws, and dependencies that don't actually exist until an attacker registers them.
TL;DR:
- Nearly 44% of AI-generated code fails security tests, with failure rates ranging from 45% to 70% depending on the testing methodology and language.
- Hallucinated dependencies and unsafe patterns, such as hidden secrets and authorization gaps, significantly increase the attack surface in AI-produced code.
- Automating security gates like SAST, SCA, and secret scanning in CI/CD pipelines is essential, especially for high-risk areas like authorization, cryptography, and external APIs.
- Relying on iterative self-refinement without human checkpoints can worsen security vulnerabilities rather than improve them.
- Implementing monitoring for agent permissions, provenance verification, and strict dependency vetting effectively reduces operational risks associated with AI code generation.
Table of Contents
- What Makes AI Generated Code Security Different From Traditional Code Review
- Why AI Models Keep Producing Insecure Code
- What the Data Actually Shows About AI Code Failure Rates
- How to Reduce Security Risk in AI-Generated Code
- Building AI Code Security Into Your SDLC and Governance
- Choosing the Right Tools to Verify Generated Code
- How Adrianlabs Approaches AI Code Security in Practice
- Your 30/90/180-Day Plan for AI Code Security
- The Uncomfortable Part of This Conversation Nobody Wants to Say Out Loud
- Get Security Enforcement Built In, Not Bolted On
- Sources
What Makes AI Generated Code Security Different From Traditional Code Review
The threat surface for AI-generated code isn't new in kind, but it's different in shape and speed. A human developer writes a few hundred lines a day and usually understands the surrounding system. A coding assistant can produce thousands of lines in minutes with no memory of how the last file it touched relates to this one. That mismatch creates specific, recurring failure patterns.
Authorization and cross-service logic gaps top the list. Models are good at writing a function that does what you asked. They're bad at inferring the unwritten rule that a user should only see their own records, especially when that rule lives in a database policy three files away. This is the single most common vulnerability class the industry is currently measuring, and it's the hardest one to catch with a quick glance at a diff.
Injection and unsafe execution patterns show up constantly, including SQL injection, cross-site scripting (XSS), command injection, and casual use of eval() or shell calls to solve a problem that had a safer built-in solution. These are old vulnerability classes, but generated code reintroduces them at a volume manual review was never built to catch.
Hardcoded secrets end up in client-side bundles more often than teams expect, because a model asked to "get this working" will often take the shortest path, which is pasting a key directly into the code rather than wiring up a secrets manager.
Hallucinated dependencies are a supply-chain problem unique to generative tools: a model invents a plausible-sounding package name that doesn't exist yet, and an attacker registers it first, waiting for an install.
Agent and automation risk adds a newer layer entirely. Coding agents with file and shell access can be steered by instructions embedded in a document they read, a risk tied to llms.txt exploitation and unowned package installs, turning a routine "read this file" task into remote code execution.
Underneath all of it sits an operational risk that's easy to underestimate: teams reviewing AI output with the same confidence they'd give a senior engineer's pull request, at a volume no human review process was designed to sustain.
Why AI Models Keep Producing Insecure Code
Three separate mechanisms drive these failures, and each one calls for a different fix.
The first is inherited pattern replication. Models learn from enormous code corpora, and a meaningful share of that training data includes insecure patterns that were never flagged as bad examples. The model isn't malicious. It's reproducing what it saw, including the mistakes.
The second is hallucination itself, the same mechanism that invents a citation can invent a package name, a function signature, or an entire configuration option that sounds correct and doesn't exist. This is precisely the failure mode attackers exploit in dependency confusion attacks tied to llms.txt-style instructions.
The third, and probably the least understood, is insufficient system-level reasoning. A model can write a syntactically clean authorization check without understanding that the same check needs to apply across related services it never saw.
There's also a compounding effect worth knowing about: iterative refinement without a human in the loop tends to make things worse, not better. Controlled testing found that critical vulnerabilities increased significantly after several rounds of AI self-refinement without human validation, as the model optimized for "looks fixed" rather than "is actually fixed."
A few root causes worth watching closely:
- Training data includes insecure patterns the model has no way of knowing were bad practice.
- Hallucinated package names and function calls create attack surface that didn't exist a week ago.
- Cross-service and system-wide security intent, like row-level security, rarely survives a single-file generation context.
- Refinement loops without human checkpoints can degrade security rather than improve it.
- Agents that treat retrieved documents as instructions rather than data open a path to permission escalation.
Pro Tip: If your team lets an assistant iterate on its own output more than two or three times without a human review checkpoint, you're statistically more likely to end up with a worse security posture than where you started, not a better one.
What the Data Actually Shows About AI Code Failure Rates
The numbers are more consistent across sources than most developers assume, and none of them are flattering.
Veracode's GenAI Code Security testing found models pass security tasks at roughly a 56% rate, meaning close to 44% of the code they produce fails a security test outright. That's not a snippet-level edge case. It's a coin-flip-adjacent baseline, and it varies sharply by language: Java trails Python, and categories like XSS and log injection score especially poorly.
The Cloud Security Alliance's research puts the failure range even wider, between 45% and 70%, depending on testing methodology, with authorization gaps and missing access controls as the dominant pattern. That range matters because it tells you the number isn't a fixed constant. It shifts based on how rigorously you test, which is itself a warning about relying on a single audit pass.
Academic benchmarks add a different angle. The A.S.E repository-level benchmark shows that code performing well on isolated snippet tasks still contains CVE-aligned vulnerabilities once you evaluate it at the scale of a real repository, a gap between "looks correct" and "is secure" that snippet-level testing simply can't see.
| Source | What it measured | Reported failure rate |
|---|---|---|
| Veracode GenAI Code Security | Security task pass/fail across languages | ~44% fail |
| Cloud Security Alliance | AI-generated samples across methodologies | 45% to 70% fail |
| A.S.E benchmark | Repository-level CVE-aligned checks | High rate; varies by model, snippet-passing code still fails |
These are lab and industry-scale measurements, not a promise about what your specific pipeline will produce. Model choice, language, prompt discipline, and review rigor all move the number. Treat every figure here as a reason to test your own code, not as a substitute for testing it.
How to Reduce Security Risk in AI-Generated Code
Prioritize the controls that scale automatically over the ones that depend on a human remembering to look.
- Make SAST, SCA, and secret scanning mandatory CI/CD gates. Any pull request touching AI-assisted code should fail the build automatically if it trips a scanner, no exceptions, no "we'll fix it later" merges.
- Require tiered human review for high-risk code paths. Authorization logic, storage policies, cryptography, and external API boundaries should require sign-off from an engineer with security training, not generic peer review.
- Enforce software bills of materials (SBOMs) and provenance metadata. Every release should carry a record of what went into it and where it came from, with signed artifacts required before deployment.
- Harden agent permissions. Revoke unnecessary execution rights, block auto-install from unvalidated registries, and vet any document, including llms.txt-style files, before an agent is allowed to treat it as instructions.
- Build security-aware prompt templates and lightweight model critics. A small heuristic checker that flags
eval(), shell execution, or missing auth checks before SAST even runs catches obvious problems earlier and cheaper. - Operationalize incident response for AI-generated releases. Have a rollback playbook and a triage process specifically for vulnerabilities traced back to generated code, not a generic process borrowed from manual development.
On the dependency side specifically, the practical fix is blunt but effective: block installs from unvetted registries, enforce namespace allow-lists, and reject any pull request proposing a new dependency unless it went through an authorized maintainer workflow. This single control closes off most of the hallucinated-package attack path before it ever reaches a review queue.
Pro Tip: Treat every AI-suggested new dependency as a red flag worth a second look, even if it resolves and installs cleanly. A package resolving successfully today doesn't mean it existed a month ago, or that its current maintainer is who you'd expect.
Building AI Code Security Into Your SDLC and Governance
NIST's Secure Software Development Framework and its generative AI community profile (SP 800-218A) give you a structure instead of a pile of disconnected tips. Mapping your controls to its four outcome areas, Prepare, Protect, Produce, Respond, turns ad hoc mitigation into something you can actually audit.
- Prepare: train developers on AI-specific failure modes and harden the environments where agents operate.
- Protect: lock down execution permissions, registry access, and secrets management before generation even starts.
- Produce: run SAST, SCA, and DAST (dynamic analysis) on every AI-assisted change, with provenance captured at build time.
- Respond: define a vulnerability triage path specifically for generated code, with clear rollback authority.
Assign real ownership here. Security champions embedded in engineering teams, a defined approver for high-risk PRs, and a named owner for model governance (which tools are approved, what data they can see, what permissions they carry) turn this from a policy document into an enforced practice. OWASP's secure development guidance remains a solid foundation here; it just needs AI-specific controls layered on top, not replaced.
Track a small number of metrics that actually move: security pass rate on AI-assisted pull requests, count of high-risk PRs requiring escalated review, and mean time to remediate once a vulnerability is flagged. If those three numbers aren't trending the right direction quarter over quarter, the policy exists on paper only.
Choosing the Right Tools to Verify Generated Code
Snippet-level testing catches the obvious problems and misses the systemic ones. Repository-level and pipeline-level testing catches both.
Run SAST, SCA, DAST, and interactive analysis (IAST) tuned specifically for generated output, on every pull request, before merge, not as a periodic audit. Waiting for a quarterly security review means months of vulnerable code already shipped.
- Adopt repository-level benchmarks like A.S.E and CVE-aligned static checks rather than relying on snippet-scale tests that miss cross-file logic gaps.
- Automate SBOM generation and dependency vetting on every build, rejecting hallucinated or unregistered package names automatically.
- Enforce registry allow-lists so a new dependency can't slip in without a known, trusted source.
- Monitor for anomalous installs or unexpected parent-process behavior from coding agents, a leading indicator of agent-driven compromise before it becomes a full incident.
| Approach | Best for | Limitation |
|---|---|---|
| Snippet-level SAST | Fast, cheap, catches known patterns | Misses cross-file and system-wide logic |
| Repository-level benchmarks (A.S.E) | Catches CVE-aligned issues at scale | Slower, resource-intensive |
| SBOM and dependency vetting | Blocks hallucinated packages | Needs ongoing registry maintenance |
| Agent behavior monitoring | Detects live exploitation attempts | Reactive, not preventive on its own |
How Adrianlabs Approaches AI Code Security in Practice
Adrianlabs builds these principles directly into how it generates and ships software, rather than treating them as an afterthought bolted on after the code is written.
- Autonomous debugging with project isolation keeps a fix in one project from leaking assumptions, credentials, or dependencies into another, closing off a common cross-contamination risk in multi-project environments.
- Release verification checks provenance metadata and artifact signatures before anything deploys, so a shipped build can be traced back to exactly what generated it.
- Local-model and bring-your-own-API-key options let teams keep generation on their own infrastructure when code ownership and data privacy matter more than convenience, a choice worth understanding fully before you run an AI app builder on your own machine.
- As a concrete example of enforcement in practice: a CI gate should reject any generated pull request missing row-level security on a new database table, or one that embeds a client-side secret, automatically, before a human ever needs to catch it manually.
If you want a deeper look at why generated apps often compile cleanly while still hiding structural problems, that gap between "runs" and "is safe" is worth understanding in more depth.
Your 30/90/180-Day Plan for AI Code Security
The verdict hasn't changed: AI-generated code is untrusted by default, and enforcement, not trust, is what closes the gap. In the next 30 days, turn on SCA and secret scanning for every AI-assisted pull request and baseline your current pass rate. By 90 days, add SAST and tiered human review for high-risk modules, and start your SBOM rollout. By 180 days, align policy to SSDF, automate provenance capture, and establish model governance with ongoing benchmarking. Track pass rate, high-risk PR count, and mean time to remediate, and let those numbers, not a feeling of confidence, tell you whether the program is working.
The Uncomfortable Part of This Conversation Nobody Wants to Say Out Loud
The conventional advice on this topic treats AI code security as a review problem: read the diff more carefully, ask better questions, slow down. That advice was written for a world where a human wrote the code at human speed. It doesn't scale to a world where a model can generate a week's worth of pull requests before lunch.
What the evidence actually supports is a different posture entirely: security has to move from a review step to a gate, something automated, mandatory, and blind to how confident the code looks. It's a reason to stop trusting human judgment as the primary control at all.
Where most teams get this wrong is treating agent permissions as an afterthought. The llms.txt exploitation research should have been a wake-up call: an agent with shell access doesn't need to be attacked directly if it can be convinced to attack itself. Lock down execution rights before you worry about prompt quality. The order of operations here is not optional.
Prioritize the boring stuff first. SCA and secret scanning are unglamorous and take a week to set up. They also close off the two most exploitable gaps immediately, before you touch anything harder.
— Adrian
Get Security Enforcement Built In, Not Bolted On
Most teams adopting AI-assisted development end up stitching together SAST tools, SCA scanners, and secret detection after the fact, hoping the pieces cover the gaps a fast-moving pipeline creates. Adrianlabs takes a different approach: security enforcement, autonomous debugging, project isolation, and release verification, is part of how the platform generates code in the first place, not a separate step your team has to remember to run.
That matters most if you're a founder or small team without a dedicated security engineer reviewing every pull request. Adrianlabs handles planning, full-stack generation, and testing with the same gating discipline this article recommends, verified provenance, signed releases, and options to run local models or bring your own API key when code ownership and privacy are non-negotiable. You can see exactly where your code goes and how it's verified before you commit to a workflow. If you're ready to build with security enforced from the first line of generated code rather than added after the fact, start with Adrianlabs and see the difference a security-first generation process makes.
Sources
- AI writes half our code now. It still fails security tests 44% of the time.
- Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale
- Secure Software Development Framework | CSRC
- Claude, Codex and Hermes installed unowned code inside corporate networks