AI-Generated Code Security: What to Review Before Deploy

Multiple independent 2026 studies put the vulnerability rate in AI-generated code between 25% and 45%, depending on methodology and language. Veracode's Spring 2026 GenAI code security update found that even reasoning-focused models — the best performers tested — pass security evaluations only 70–72% of the time. 

Before deploying AI-generated code, review seven things: authentication and authorisation placement, input handling, secrets, database access rules, dependencies, error handling, and what the code actually does versus what you asked for. 

What the research says

The numbers converge from independent sources, which is what makes them credible rather than alarmist.

•      Veracode's Spring 2026 update, drawing on an evaluation programme covering over 150 large language models, reported a 28–30% vulnerability rate even among the highest-performing reasoning models, with a broader baseline security pass rate around 55%.

•      An AppSec Santa study of 522 code samples across six LLMs, tested with five SAST tools, found a 25.7% vulnerability rate — roughly one in four samples containing a confirmed flaw. The most frequent weakness classes were CWE-918 (server-side request forgery) and CWE-22/23 (path traversal).

•      NYU research on GitHub Copilot, one of the earliest empirical studies in this area, found roughly 40% of generated programs contained vulnerabilities, with higher rates in C than in Python.

•      CodeRabbit's analysis across repositories found AI-generated code was 1.88x more likely to introduce vulnerabilities than human-written code, with injection flaws accounting for around a third of confirmed findings.

•      Wiz Research found that one in five organisations using vibe-coding platforms faced systemic security risks, including client-side authentication that could be bypassed by modifying JavaScript, hardcoded secrets, and exposed internal applications.

Two findings deserve particular attention because they are about people rather than models. Research by Perry et al. found that developers using AI assistants wrote significantly less secure code while rating their own insecure solutions as secure — a measurable false sense of security. And security review coverage has been reported as 20–30% lower for AI-generated code than for hand-written code, meaning the code most likely to contain flaws is the code least likely to be reviewed.

Why models generate insecure code

This is not a bug awaiting a patch. It follows from how the systems work.

• Training data reflects the internet, not a secure codebase. Models learn from billions of lines of public code that include tutorials, abandoned prototypes, Stack Overflow answers, and quick hacks alongside production-quality work. A model sees far more string-concatenated SQL queries than parameterised ones, especially in older code. Models learn from frequency, not from correctness.

• Functionality is the optimisation target. The prompt asks for a working feature. The generated code satisfies that request. Security is a property of what the code refuses to do, and nothing in the request specifies it.

• Security is contextual and models lack the context. Whether a given endpoint needs authorisation depends on your threat model, your trust boundaries, and your data classification. None of that is in the prompt or the surrounding file.

• Vibe coding removes the compensating control. The practice of prompting for code and shipping it without reading it does not create new vulnerability classes — it removes the human review layer that was catching them. The risk multiplier is procedural, not technical.

•  

The seven-point pre-deployment review

Review in this order. The first three catch the majority of serious findings.

Authentication and authorisation — check placement, not presence

The recurring failure is not missing auth; it is auth in the wrong place. Generated code frequently implements access control client-side, where it can be bypassed by editing JavaScript in a browser.

Verify: every endpoint enforces authorisation server-side; the check is on the object being accessed, not just on the user being logged in (broken object-level authorisation is the most exploited API flaw); role checks cannot be satisfied by a client-supplied value; and no endpoint was added without a corresponding check.

Input handling — assume nothing was validated

Injection flaws remain the largest confirmed category in AI-generated code. Check for SQL built by string concatenation rather than parameterised queries; output rendered without contextual encoding, producing XSS; user input reaching shell commands, file paths, or deserialisation; and URLs taken from user input and fetched server-side — the SSRF pattern that was the single most frequent finding in the AppSec Santa study.

Secrets — scan, do not read

Hardcoded credentials, API keys, and connection strings appear consistently across studies. Run a secret scanner over every generated file before commit, not after. Check configuration files and test fixtures as well as application code, and verify that nothing was written into a client-side bundle.

Database access rules — the platform-level trap

This is where generated applications fail most severely, because the flaw sits below the application code. CVE-2025-48757 concerned Lovable generating Supabase schemas without Row Level Security, exposing more than 170 production applications. The application code looked correct; the data layer was open.

Verify row-level security or equivalent tenant isolation is enabled on every table, that the service account is not using an over-privileged role, and that no client-side key grants direct table access.

Dependencies — check what was imported

AI-generated code shows higher rates of insecure dependencies than hand-written code. Models sometimes suggest packages that are outdated, abandoned, or — occasionally — do not exist at all, which creates a supply-chain opportunity for attackers registering the hallucinated name. Run software composition analysis, verify every package actually exists and is the one you intended, and generate an SBOM.

Error handling and logging — check what leaks

Generated error handling frequently returns stack traces, query fragments, or internal paths to the client. Separately, log injection appears at high rates in AI-generated code: user input written to logs without sanitisation can forge log entries and, in aggregating systems, become an injection vector downstream.

Intent match — read what it actually does

The subtlest category. The code compiles, passes tests, and does something adjacent to what you asked. Research has found LLM-generated code lacking defensive programming constructs and containing subtly incorrect implementations of security-critical algorithms — a token comparison that is not constant-time, a randomness source that is not cryptographic, an expiry check that is never reached. 

The review checklist, condensed

Automate the first six. Never automate the seventh.

A structural alternative: generate configuration, not code

There is a design response to this problem that most of the debate misses.Much of the risk in AI code generation comes from the output being free-form code in a general-purpose language — an unbounded surface where any vulnerability class is expressible. Every generated line is a line that could contain a flaw, and reviewing it requires reading it.Platforms built over a workflow engine take a different path: the AI generates structured, validated workflow configuration within a bounded schema rather than arbitrary code. The security-critical machinery — authentication, session handling, database access, permission enforcement, audit logging — belongs to the platform runtime and is written once, reviewed once, and hardened once. It is not regenerated per application.

This is KodeFlex's architectural position. The platform generates workflow configurations with built-in validation and error correction, supports human review before release, and produces output intended for direct enterprise delivery rather than prototype code requiring refactoring. Permission groups are generated automatically from the app structure rather than hand-wired per endpoint, and private deployment keeps the whole surface inside your own perimeter.

The honest framing: this shrinks the attack surface, it does not eliminate it. You still review permission group assignments, approval routing (a mis-set approval node is a business-logic vulnerability), data source queries where custom SQL is used, and field-level visibility on sensitive data. But you are reviewing a configuration you can read in minutes rather than auditing thousands of lines of freshly generated application code.

Governance: three policies worth writing down

• Review parity. AI-generated code gets the same review depth as human-written code — ideally more, given that measured review coverage is currently lower and vulnerability density higher. Mark AI-assisted pull requests so reviewers know.

• No unreviewed generated code in production paths. Prototypes are fine. The rule applies to anything handling authentication, personal data, money, or external input.

• Gate on tooling. SAST, SCA, and secret scanning run in CI and block merge. This is table stakes, and it is what makes the human review time affordable — reviewers spend it on intent and logic rather than on findings a scanner should have caught.

FAQ

How much AI-generated code contains security vulnerabilities? 

Independent 2026 studies converge on 25–45%, varying by methodology and language. Veracode's Spring 2026 update reported a 28–30% vulnerability rate among the best-performing reasoning models, AppSec Santa found 25.7% across 522 samples from six LLMs, and earlier NYU research on GitHub Copilot found roughly 40% of generated programs contained flaws.

Is AI-generated code safe to deploy? 

Not without review. The evidence indicates AI-generated code is roughly 1.9 to 2.7 times more likely to introduce vulnerabilities than human-written code, while receiving 20–30% less security review coverage. It is safe to deploy under the same review and scanning discipline you would apply to code from an unfamiliar contractor.

What are the most common vulnerabilities in AI-generated code? 

Injection flaws (SQL, command, and code injection) are the largest confirmed category. Server-side request forgery, path traversal, cross-site scripting, hardcoded credentials, client-side authentication that can be bypassed, missing input validation, and insecure or non-existent dependencies also recur consistently across studies.

What is vibe coding and why is it a security risk? 

Vibe coding is prompting an AI to generate code and shipping it without reviewing the output. It does not create new vulnerability classes — it removes the human review layer that catches them. Wiz Research found one in five organisations using vibe-coding platforms faced systemic security risks including bypassable client-side auth and hardcoded secrets.

Do SAST tools catch AI-generated vulnerabilities? 

They catch the mechanical classes well — injection patterns, hardcoded secrets, known-vulnerable dependencies, unsafe API usage. They do not catch business-logic flaws, missing authorisation on a specific object, or subtly incorrect implementations of security-critical algorithms. Automate scanning and reserve human review for logic and intent.

Is generated configuration safer than generated code? 

Structurally, yes, because the output is constrained to a validated schema rather than an unbounded general-purpose language, and the security-critical runtime is written and hardened once rather than regenerated per application. It reduces the attack surface but does not remove the need to review permissions, approval routing, and any custom queries.