Vibe Coding Security Risks: What the 2026 Research Actually Found

Andrej Karpathy named vibe coding in February 2025. By 2026 roughly 46% of newly shipped code is AI-generated, which means the practice stopped being a novelty and became the default way a lot of software gets written.

That volume finally produced something the argument was missing: data. For most of 2025 the security conversation about AI-written code was people trading anecdotes. There are now published studies with sample sizes, and they tell a more specific story than either side of that argument expected.

The short version: AI-generated code is not uniformly insecure. It fails in a small number of predictable places, hard, at scale. Knowing which places is most of the defense.

What the numbers actually say

Read those together and a shape emerges. The failures are not exotic logic bugs. They are supply chain, credentials, and access control — the three areas where correct-looking code and secure code diverge most.

Why the failures cluster where they do

A language model optimizes for code that looks like working code. Security properties are mostly invisible in that frame, for three structural reasons.

Absence is not visible. A missing authorization check produces no error, no warning, and no failing test. The feature works. The model has no signal that anything is wrong, and neither do you, because you tested as yourself with full permissions.

Training data reflects tutorials, not production. An enormous share of public example code is deliberately simplified — API key in the client, permissive CORS, no rate limiting, admin credentials in a config file. Those simplifications carry a comment in the original. The comment does not survive generation.

The adversary is never in the prompt. You asked for a user profile page. You did not ask what happens when someone changes the ID in the URL to a different user. The model builds what you asked for, competently.

None of this is a claim that models write bad code. It is a claim that they write code for the requirements they were given, and security requirements are the ones nobody states out loud.

The five failures we find in almost every audit

Across the AI-built apps we have reviewed, the same five show up with tedious regularity.

Secrets in the frontend bundle. OpenAI keys, Stripe secret keys, database service keys — placed client-side because that is where the code that used them lived. The GitGuardian numbers above are the public-repo version of this; the private version is worse because nobody scans it. If this is your situation right now, what to do about keys in the frontend is the immediate playbook.

Access control that exists in the UI only. The dashboard hides the admin button for non-admins, and the API endpoint behind it checks nothing. This is the single most common serious finding, and it is invisible until someone opens the network tab.

Row-level rules enabled but not enforced. Supabase apps in particular ship with RLS switched on and a policy of "using true," which is decorative. See the RLS mistakes specific to AI-generated Supabase apps for the full pattern list.

Dependencies nobody chose. Packages added mid-session by an agent, sometimes hallucinated, sometimes real but abandoned, almost never reviewed. This is where the slopsquatting risk lives — the attack is explained in detail in our post on hallucinated packages.

No limits on anything. No rate limiting, no request size caps, no spend ceiling on metered APIs. Not a breach on its own, but it converts a bored teenager into a five-figure invoice overnight.

What the research does not say

Being honest about the limits matters, because overstating the case makes it easy to dismiss.

These studies do not establish that AI-written code is more vulnerable per line than human-written code. Human code has been shipping the OWASP Top 10 for two decades. What the data supports is narrower and still serious: AI code is produced far faster, reviewed far less, and written by people who often cannot evaluate what they received. Volume plus low scrutiny is the risk multiplier, not some inherent property of model output.

The Escape.tech figure also comes from apps that were publicly deployed and scannable. That population skews toward the least hardened end of what gets built. Your app is not automatically in that group — but if you have never had it looked at, you do not know that it is not.

What to do this week

You do not need a security program. You need four afternoons.

1. Scan for secrets, in code and in git history. Rotate everything you find; hiding a committed key does nothing because the history still has it.
2. Test one authorization boundary by hand. Log in as a normal user, find an object ID belonging to someone else, call the API directly with your own session. If it returns data, you have a whole class of bug, not one bug.
3. Audit your dependency list. Every package should be one you can name a reason for. Pin versions with a committed lockfile.
4. Put a ceiling on every metered service. Spend limits at the provider, rate limits at your edge.

That covers the majority of what the research found. The rest — input validation, error handling, session management, logging — is real work, and it is what a proper AI code audit exists to find. If you want the full list before hiring anyone, a production readiness checklist is free to work through yourself.

Frequently asked questions

Is vibe coding inherently unsafe? No. Vibe coding is a way to produce software quickly, and speed is neutral. What is unsafe is shipping code to real users when nobody in the loop can evaluate its security properties, which describes a lot of what gets built. If you want the mechanics of the practice itself, start with what vibe coding is.

Can I ask the AI to audit its own output? It will find some things — a hardcoded key, an obvious injection — and it is worth ten minutes. It will not find missing authorization, because absence is exactly what it is blind to, and it will report confidently either way. Treat it as a first pass, never as the verification step.

How much does fixing this cost? Industry-wide, audit-plus-hardening engagements typically run $1,000 to $15,000 over four to ten weeks depending on codebase size and whether money moves through the app. Compare that to a leaked metered API key, which can burn thousands over a single weekend.

---

If you built something with AI, it has users, and nobody has ever checked the areas above, you are in the population these studies were measuring. SprintX audits AI-generated codebases against exactly these failure classes and gives you a prioritized list with fix costs attached. Send us your repo or builder link.