Is AI-Generated Code Safe? What the 2026 Data Shows, and What Scanners Miss

Is AI-generated code safe?

No, not by default. AI-generated code is as safe as the controls around it, and most setups have no control that acts before the code lands. Independent benchmarks agree on the shape of the failure: the code runs, it passes its tests, and it still carries a vulnerability. Safety here is a property of your pipeline, not the model.

The oldest systematic measurement is still the clearest. In Asleep at the Keyboard, submitted in August 2021 by a team at New York University with a co-author at the University of Calgary, the researchers prompted GitHub Copilot with 89 scenarios drawn from MITRE's Top 25 weaknesses and collected 1,689 completions. Their finding, in their words: "Of these, we found approximately 40% to be vulnerable." That number is five years old and it is about one assistant, so treat it as the baseline rather than as today's verdict.

Today's verdict comes from SusVibes, a benchmark from Carnegie Mellon's Language Technologies Institute with collaborators at Columbia, Johns Hopkins and HydroX AI, accepted at ICML 2026 and last revised on 21 August 2026. It takes 186 real feature requests from open-source projects where the human implementation was itself vulnerable, covering 79 CWE categories, and runs 12 agent configurations against them. The best setup, SWE-Agent with Claude 4 Sonnet, was functionally correct on 57% of tasks and secure on 11.8%. The paper adds the line that should worry you most: 79.3% of its functionally correct solutions have vulnerabilities.

11.8%

of the best agent's solutions were secure, against 57% functionally correct (SusVibes, 186 real feature requests, revised August 2026)

79.3%

of that agent's functionally correct solutions still carried a vulnerability (same benchmark)

100%

of applications OWASP tested showed some form of broken access control, its number-one risk for 2025

The scale is what turns a per-task rate into a business problem. In DORA's 2025 State of AI-assisted Software Development report, published on 23 September 2025, "90% of survey respondents report using AI at work" while "30% report little or no trust in the code generated by AI". The same report notes that "AI adoption does continue to have a negative relationship with software delivery stability". Nine developers in ten are shipping it, three in ten do not trust it, and stability is where the tension surfaces.

Why is so much AI-generated code insecure?

Because a model can hold a security principle and still fail to apply it at the line where it matters. A June 2026 systematization from the University at Buffalo named this the knowledge-actuation gap and measured it: models score far higher on knowing the rule than on producing code that survives the matching exploit. Knowing is not doing.

That paper, SoK: AI Secure Code Generation, puts numbers on the distance. "The benchmark-level gap is 47.9 points for CWEval and 72.9 points for BaxBench", and the gap widens as the task gets more realistic: CWEval is function-level, BaxBench asks for whole web applications, where the guard has to land in the right middleware, the right route, the right file. Its thirteenth takeaway reads as the sentence to remember, that the gap is a delivery problem, because models hold the right security knowledge and fail to apply it at the correct implementation boundary. Interventions work by binding a known principle to the right code location, not by teaching the model more security.

Two older forces compound it. The corpus problem: the model learned from a huge body of public code full of string-concatenated SQL, missing authorization checks, weak crypto and inlined secrets, so insecure-by-default is its statistical prior. And the absence problem: security is usually a guard that is present, and a model asked for a positive outcome ("add a checkout endpoint") does not add a negative guard nobody requested. The feature works precisely because the missing check does not affect the happy path.

Then the reader problem, and it is the decisive one. The person prompting can tell whether the feature works. They often cannot tell whether it is safe. That gap, between the author's intent and the reviewer's ability, is the whole security problem, and it is exactly what widens when a non-specialist vibe-codes a feature in a paragraph of intent. We go deeper on this in vibe coding security.

What kinds of vulnerabilities does AI code introduce?

The same ones humans introduce, reproduced faster than review can keep up. Injection, broken authorization, hardcoded secrets, missing input validation, insecure deserialization and business-logic errors. Most of them sit in the 2025 CWE Top 25, which is the point: these are not exotic model failures, they are the industry's oldest and best-documented weaknesses.

• Injection (CWE-89, CWE-78). Concatenated SQL and shell commands built from user input, because the model learned them from a corpus full of them. SQL injection ranks second and OS command injection ninth in the 2025 CWE Top 25. See why most SAST findings are noise for why only the reachable ones matter.
• Broken authorization and IDOR (CWE-862, CWE-639). The agent builds the endpoint that returns the record but rarely the check that the caller owns it. Missing authorization is fourth in the same list, and OWASP puts the parent category first: A01:2025 Broken Access Control is "maintaining its position at #1 in the Top Ten", with "100% of the applications tested" showing some form of it.
• Hardcoded secrets (CWE-798). Asked for a working integration, the model inlines an API key or password so the code runs on the first try, and it then lives in the repo and every fork. Worth noting that this one is absent from the 2025 CWE Top 25, so that ranking is not where you will find it.
• Missing input validation (CWE-20). Generated endpoints trust their inputs, which is the quiet enabler of injection and deserialization downstream. Eighteenth in the 2025 list.
• Insecure deserialization (CWE-502). "Load the saved object" becomes pickle or yaml.load on untrusted bytes, turning a stored blob into remote code execution. Fifteenth in the 2025 list.
• Business-logic flaws. The most dangerous class, because no scanner is shaped to catch it: a negative-quantity cart, a coupon that stacks, a refund that skips the ownership check. The code is syntactically perfect and semantically wrong, and it appears in no CWE ranking because it is specific to your domain. This is our deep dive on business logic flaws in AI-generated code.

What do scanners, and the models themselves, miss?

Two things. Business logic, which offers no dangerous sink to match, and the model's own blind spots, which it cannot audit while the blind spots are still in place. SusVibes measured the second directly: augmenting the feature request with vulnerability hints did not mitigate the security issues, so prompting the model harder is not the fix.

The first blind spot is business logic. A static analyzer reasons about code patterns; a business rule ("only the owner may edit this document", "quantity must be positive") lives outside the code, in your domain. There is no tainted input and no dangerous sink to match, just an if statement that was never written, so the scanner reports the file as clean while it is fully exploitable.

The second is the model marking its own homework. Asking the same agent that wrote the code to review it inherits the same blind spots: it does not know your authorization model, it cannot see the other findings around the line, and it is as confident about the insecure version as the secure one. This is the knowledge-actuation gap again, seen from the review side. A trustworthy check needs outside signal: reachability-aware scanning that follows real data flow, and your own rules loaded as ground truth, not the model's own opinion.

“

The question is not whether AI writes insecure code, every author does. It is whether anything catches the insecure line before it ships, and at AI speed the only place left to catch it is where the line is written.

Can you trust an AI to fix its own vulnerabilities?

You can trust an agent to apply a fix far more than to decide what is a real, reachable vulnerability. It rewrites a line well once it knows exactly what to change, and judges exploitability badly, which a scanner already computed. So hand it confirmed findings and your rules, let it patch, and approve every diff.

The trustworthy pattern is therefore not "AI, secure my code", it is "hand the agent confirmed, reachability-ranked findings plus your rules, let it fix them, and review the result". We cover that loop in AI vulnerability remediation and whether an agent can find and fix vulnerabilities automatically.

What does not work is writing the rules down and hoping. In our controlled study of 24 August 2026, 30 developer tickets were run in triplicate against a mid-sized codebase, 90 autonomous runs and 93 independent security scans with Claude Opus 5 at effort high. A realistic hand-maintained rules file in the repository implemented 7 of 55 rule specifics exactly, 13%, against 8 of 65 with no file at all, 12%. The file changed almost nothing. Delivering the same rules at the moment of the edit reached 57 of 64, 89%. The study also measures the honest limits: one ticket where the unassisted arm did better, one where the rule was served thirteen times and the agent dismantled its own safeguards anyway, and a design that measures staying at zero on a codebase that started clean rather than digging out of an existing backlog.

How do you make AI-generated code safe?

You move the control to the moment the code is written, then keep scanning and human review behind it. Three moves, in order of leverage: govern what the agent writes before it writes it, feed confirmed scanner findings back into the loop, and keep a CI gate plus a human approving diffs as the backstop.

1. Govern at generation time. Load your security and business rules into the agent before each edit, so the safe pattern is the default it reaches for. The vulnerability that is never written needs no triage. This is the core idea of AI coding agent security.
2. Scan continuously and feed the findings back to the agent. Keep reachability-aware SAST, SCA, secrets, IaC and CI-CD scanning running, and put their confirmed findings in the agent's hands so it remediates the real ones in the loop. In our study, new security findings introduced per task fell from 0.10 without a tool to 0.033 with the layer, and the independent scanner's count went from 1 to 4 on the unassisted arm across thirty tickets while the governed arm stayed at 1.
3. Keep CI and human review as the backstop. A SAST gate on every pull request and a human approving diffs catch what slips. They are necessary, but at AI speed they cannot be the only line.

The full hands-on version is how to add security to your AI coding workflow and how to secure a whole app in five minutes.

VibeDefend is the layer that does the first two. It is a free npm CLI that installs in seconds and wires Claude Code, Cursor, Windsurf, OpenAI Codex and VS Code Copilot into four governance layers inside the agent loop.

Three layers govern what the agent writes, Business Rules mined from your repo, Security Rules drawn from the OWASP, SOC 2, GDPR and ISO 27001 families, and an Action Guard that blocks destructive calls. The fourth, Live Findings, wires the agent into CybeDefend's scanning platform, with SAST, SCA, secrets, IaC and CI-CD scanners running continuously and every finding live in the agent's context, so the agent does not only write safer code, it fixes the vulnerabilities you already have. Nothing about your code crosses the wire; only structured governance metadata does, on EU or US regions kept physically separate.

Frequently asked questions

Short answers, each grounded in the sources linked above: the NYU Copilot study of 2021, the SusVibes benchmark revised in August 2026, the University at Buffalo systematization of June 2026, the OWASP Top 10:2025, and our own controlled study of 24 August 2026.

Is AI-generated code safe?

Not by default. AI-generated code reliably runs and passes the happy path, but independent testing repeatedly finds a large share of it insecure: approximately 40% of Copilot completions were vulnerable in NYU's 2021 "Asleep at the Keyboard" study, and in the SusVibes benchmark revised in August 2026 the best agent setup was functionally correct on 57% of real feature requests while only 11.8% of its solutions were secure. It becomes safe when you add a control that acts where the code is written and keep human review and CI scanning behind it.

Is it safe to deploy AI-generated code to production?

Only after it is reviewed and scanned the way any code should be, and ideally after it was governed as it was written. Deploying AI code straight from "it works" is risky because the flaws (missing authorization, injection, hardcoded secrets, business-logic errors) do not affect the happy path and so survive a functional test. SusVibes measured exactly that gap: 79.3% of the best agent's functionally correct solutions still carried a vulnerability. Gate it with reachability-aware SAST in CI, human review of security-sensitive paths, and a prompt-time control so the safe version is written first.

Why is AI-generated code insecure if the model is so capable?

Because capability at producing working code is not the same as producing secure code. The University at Buffalo's June 2026 systematization calls this the knowledge-actuation gap and measured it at 47.9 points on CWEval and 72.9 points on BaxBench: the model knows the principle and fails to apply it at the right implementation boundary. Add the corpus (public code is full of insecure patterns), the absence (security is a guard nobody asked for), and the reader (the person prompting often cannot evaluate safety). None of these are fixed by a smarter model.

Can I just ask the AI to check its own code for vulnerabilities?

It helps a little and is not sufficient. The same model that wrote the code shares its blind spots: it does not know your authorization model or tenant boundary, it cannot see the other findings around the line, and it is equally confident about the insecure and secure versions. SusVibes tested the obvious workaround and reports that augmenting the feature request with vulnerability hints did not mitigate the security issues. Trustworthy checking needs outside signal, reachability-aware scanning and your own rules as ground truth.

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

Injection (CWE-89, CWE-78), broken authorization and IDOR (CWE-862, CWE-639), hardcoded secrets (CWE-798), missing input validation (CWE-20), insecure deserialization (CWE-502), and business-logic flaws. Four of those six classes map to entries in the 2025 CWE Top 25, and OWASP ranks broken access control first for 2025, reporting that 100% of the applications it tested had some form of it. The first five are detectable by good scanners when you filter for reachability; the last, business logic, is the dangerous one because no scanner is shaped to catch a syntactically perfect, semantically wrong rule.

How do I make AI-generated code safe?

Move the control to generation time: load your security and business rules into the agent so it writes the safe pattern first, scan continuously and feed the confirmed findings back to the agent to remediate, and keep a CI SAST gate plus human review as the backstop. Writing the rules into a file in the repository is not enough: in our controlled study of 24 August 2026 a realistic rules file implemented 7 of 55 rule specifics exactly, 13%, against 8 of 65 with no file at all, 12%, while the same rules delivered at the moment of the edit reached 57 of 64, 89%.