Is AI-generated code secure? What the research actually says

The short answer: AI-generated code is not secure by default, and it isn’t insecure by default either. It reflects the patterns the model learned and the instructions it was given. When those instructions don’t mention security — and most prompts don’t — security-relevant details are frequently missed.

The longer answer is more useful, because it tells you where to look.

What the largest benchmark found

In July 2025, Veracode published its 2025 GenAI Code Security Report, testing more than 100 large language models on 80 curated coding tasks designed to have both a secure and an insecure way to complete them.

The headline findings:

• In 45% of test cases, the models introduced a vulnerability classified in the OWASP Top 10.
• Java was the riskiest language tested, with a security failure rate over 70%. Python, C# and JavaScript failed in 38% to 45% of cases.
• Models failed to defend against cross-site scripting (CWE-80) in 86% of relevant cases, and against log injection (CWE-117) in 88%.

The report’s most important observation is a trend rather than a number: models were getting better at producing functional, syntactically correct code, but not correspondingly better at producing secure code.

How to read these numbers

A benchmark measures behavior on controlled tasks. It doesn’t tell you that 45% of your code is vulnerable. What it does show is that security isn’t something you can assume, even from strong models — and that certain categories, like output encoding and input handling, fail far more often than others.

Packages that don’t exist

A distinct risk comes from dependencies. Researchers presenting at USENIX Security 2025 analyzed 576,000 code samples generated by 16 models and measured how often the models referenced packages that don’t exist. They found average hallucination rates of about 5.2% for commercial models and 21.7% for open-source models.

This matters because an attacker can register a package under a commonly hallucinated name. The next developer who accepts the suggestion and runs the install command pulls in the attacker’s code. The researchers also showed that mitigation strategies can significantly reduce the problem — but only if someone applies them.

Secrets keep leaking

Exposed credentials aren’t unique to AI-generated code, but fast-moving projects make them more likely. GitGuardian’s State of Secrets Sprawl 2025 reported 23.8 million new hardcoded secrets in public GitHub repositories during 2024 — a 25% increase on the previous year — and found that 70% of secrets leaked in 2022 were still active. Leaked keys tend to stay usable long after the mistake.

What it looks like in the real world

In 2025, a researcher scanning apps built with an AI app builder reported that a significant number exposed their databases to anyone holding the app’s public key. The issue was recorded as CVE-2025-48757, describing insufficient Row Level Security policies that let unauthenticated attackers read or write database tables of generated sites. The platform disputed the CVE, on the basis that each customer is responsible for protecting their own application’s data.

That dispute is instructive regardless of who’s right: when the tool generates the code, the responsibility for its security still lands on the person who ships it. We cover the underlying mistake in our guide to Supabase Row Level Security.

Why AI-generated code misses security

The failures cluster for understandable reasons:

1. Prompts describe behavior, not threats. “Add an endpoint that returns an invoice by ID” says nothing about who should be allowed to see which invoice. The model satisfies the request as written.
2. Training data includes decades of insecure code. Public code contains countless string-built SQL queries, unsanitized HTML and hard-coded keys. Familiar patterns resurface.
3. The model can’t see your whole system. It may not know your authorization rules, which middleware runs before a route, or which variables reach the browser.
4. Working code removes the pressure to look closer. When everything runs on the first try, there’s no error message prompting a second look.

What to do about it

None of this is a reason to stop using AI coding tools. It’s a reason to change what “done” means.

• Verify before you deploy. Treat AI-generated code as you would a pull request from a talented contributor who has never thought about attackers.
• Ask for security explicitly. Prompts that state requirements — “only the invoice’s owner may read it” — produce noticeably better results than prompts that don’t.
• Use automated checks for the common mistakes. Tools like VibeTect catch repetitive, high-impact issues quickly, so human attention goes where it’s most needed.
• Layer your defenses. Pair code-level checks with platform settings reviews and, for sensitive systems, a professional assessment.

Start with our vibe coding security checklist — fifteen checks that cover the mistakes behind most incidents in AI-built apps.