AI-generated code security: the risks and how to review it

Last updated: 29 October 2026

AI-generated code is not secure by default. Veracode's 2026 report, covering more than 100 models, found AI-written code passed security checks only 56% of the time, a rate virtually unchanged from 2025. It becomes safe to ship once a person has reviewed access control, logins, secrets, input, packages and failure paths.

Most AI-written code runs on the first try. That is the trap. Working code and secure code are different things, and a demo only tests the first. This post covers what the 2026 research says about AI-generated code security, the six ways AI-written apps fail, how each maps to the OWASP Top 10:2025, and what an AI code security review checks.

Is AI-generated code safe?

Not by default. It can be, once someone has read it.

Two large studies from 2026 point the same way:

• Veracode, July 2026. More than 100 models have been tracked since Veracode's testing began. Nearly all of their code compiled: the syntax pass rate is close to 100%. The average security pass rate is 56%. Java was lowest, at 30%. Nearly all of the code runs, and close to half of it fails security checks (SD Times report, 28 July 2026).
• IOActive, April 2026. 27 models and coding tools, 730 real-world prompts that never mentioned security, and nearly 20,000 code samples. 31.6% of the samples were fully exploitable. Authentication, rate limiting and cryptography failed across nearly all models. Adding "write secure code" to the prompt often did not help (IOActive).

There is a human side too. In a user study by Perry and colleagues (2022, revised 2023), people with an AI assistant wrote significantly less secure code than people without one. They were also more likely to believe their code was secure.

So the risk is not that AI writes bad code. Much of it is fine. The risk is that it writes plausible code fast, and people trust it more than they should.

Is vibe coding safe?

Vibe coding means describing what you want to an AI tool and accepting what comes back, often without reading it. It is a fast way to build a demo. It is not safe for real users on its own, because nobody has checked the parts a demo never touches.

The incidents are public. CVE-2025-48757, published in May 2025, describes database access rules in sites generated by Lovable that let unauthenticated attackers read or write arbitrary tables. Lovable disputes it, on the grounds that each customer is responsible for their own app's data. In February 2026, The Register reported one Lovable-hosted app with 16 vulnerabilities, six of them critical, and 18,697 user records exposed. Lovable said the vulnerable database was not hosted by Lovable and that it offers a free pre-publish security scan.

Both cases make the same point about vibe coding security: the tool will not own your app's data. Someone on your side has to check it.

What goes wrong in AI-written apps?

The same six problems come up again and again. None of them shows in a demo.

1. Auth and session gaps

The login screen works. Behind it, the checks are thin. A route that should need a signed-in user answers anyone who calls it directly. A session never expires, or a password reset link works twice. AI tools build the screen you asked for. They don't always build the checks you didn't mention. IOActive found authentication failing across nearly all models.

2. Data leaking between users

This is the most serious one. The app shows you your orders, but the request behind it takes an order ID and returns any order, whoever owns it. Change one number and you read a stranger's data. Broken access control is A01, the top risk, in the OWASP Top 10:2025. If your backend relies on database rules for this, our post on Supabase and Row Level Security explains why they matter.

3. Exposed secrets

API keys, database passwords and payment tokens end up where anyone can read them: in code sent to the browser, in the app bundle or in the repository. A key that reaches the browser is public. Anyone can run up your bill or read your data with it.

4. Unchecked input

The form expects an email address and gets a script, a 10 MB string or nothing. The code trusts it and passes it to the database, the page or another service. Injection, including cross-site scripting, is the result.

5. Outdated or invented packages

AI tools suggest packages from what they saw in training. Some are years out of date, with known holes. Some don't exist. A 2024 study of package hallucinations found that, on average, at least 5.2% of packages suggested by commercial models and 21.7% by open-source models were made up. An attacker can publish a package under an invented name and wait for someone to install it.

6. Happy-path-only logic

The code handles the case where everything goes right. Then the network drops halfway through a payment, the user taps twice, a token expires mid-request or a list comes back empty. Nobody asked the tool about those cases, so the code doesn't handle them. These failures turn into lost data and support tickets.

AI-generated code security and the OWASP Top 10:2025

The OWASP Top 10 is the standard list of web application risks. Its 2025 edition covers each of the six:

This table is the core of an AI code security review. A useful review reads the code with each row in mind.

Automated code scanning is good at the mechanical rows, such as package versions with known holes or a key committed to the repository. The access-control and failure-path rows need a person who knows what the app is meant to allow.

Timing matters too. A problem found before launch is fixed before users touch it. The same problem found after launch is fixed while users wait, possibly after their data has leaked.

Can AI tools review their own code?

They can help, and we use them. But a tool asked to check its own output often misses what it missed while writing it, because both passes start from the same assumptions. It doesn't know your business rules. It doesn't know that a manager may see their own team's records but not another team's.

An AI code security review needs someone who answers for the result: a person who reads the code, knows how the parts fit and can explain any line to the next engineer. Our post on how a senior engineer reviews AI-written code covers how that review works in practice.

Who owns AI-written code?

Ask before you ship. Check who holds the code and the accounts it runs in, and check the licence of every package the tool pulled in. Copyright rules for AI output are a legal question, so take legal advice on anything that matters to your business.

How iHux handles AI-written code

"Engineered, not generated" is the line on our work. We use AI for routine work such as boilerplate, scaffolding and test generation. Engineers plan the architecture before AI writes anything. The code then goes through several levels of code review, with automated code scanning alongside. The senior engineer who reviews it is not the engineer who built it.

On our fixed-price MVP, the senior review happens on day 11 of 14 working days. Everything it finds is fixed before the code is handed over on day 14, and the delivery date doesn't move.

Every handover includes a written security report. It covers six areas:

• Login and sessions: who can sign in, and when a session ends.
• Data access: whether each user sees only their own records.
• Secrets: where keys and passwords are stored.
• Unexpected input: how the app handles bad or hostile data.
• Third-party packages: what the app depends on, and whether those versions are safe.
• Findings and fixes: what the review found, and how each finding was fixed.

It is written so a founder who isn't technical can read it. The MVP development page shows the timeline and price. For how AI pilots reach production more broadly, read why AI projects fail and how to reach production.