TL;DR: AI coding tools are graded on one thing: code that runs. Code that resists attack is a different job, and no demo ever tests it. That is why AI-built apps work perfectly and leak anyway. The gaps land in four places — security, reliability, performance, and monitoring — and each has a fix.
We scan AI-built apps for a living, and the story never changes. The app works. The demo is smooth. The founder ships. Then someone finds the gap the AI never mentioned, because the AI did not know it was there either.
This page explains why. Not "AI bad" — the tools are very good at what they are trained to do. The problem is what they are trained to do. Want your own number before the theory? Run the free scan on your live URL. About 30 seconds.
The mechanism: graded on "runs," not "resists"
Ask an AI builder for a login flow, and you get one. Users can sign up, sign in, reset a password. It works.
What you do not get: a rate limit on that route. An end date on that session. A check that stops a script from testing ten thousand emails against your form overnight. None of that was in the request, so none of it is in the code.
Here is the core of it. The model's reward is "does this run," not "would this survive a stranger with twenty minutes and a terminal." Working code gets tested by the demo. Safe code only gets tested by someone trying to break it. Most founders never run that second test before launch.
CMU's SusVibes study measured the result. 61% of AI-written code had at least one security flaw. Not because the models are careless. Because nobody graded them on it.
The four failure modes, one by one
"Insecure" is too vague to fix. We split each audit into four parts, because the AI drops the ball in four distinct ways.
| Dimension | What the AI ships | What breaks |
|---|---|---|
| Security | Open access rules, keys in the bundle, no rate limits. | Data leaks. Account takeover. Surprise API bills. |
| Reliability | Happy-path code with no error handling. | One failed API call takes the whole flow down. |
| Performance | Queries in loops, no indexes, bloated bundles. | The app that flew with 10 users crawls at 1,000. |
| Monitoring | Nothing. No error tracking, no alerts, no logs. | Customers find your outages before you do. |
Security: the defaults are open
AI builders default to open, because open code runs on the first try. Database rules that let any logged-in user read any row. Secret keys pasted into frontend code, because that was the fastest path to a working feature. No cap on requests, because the demo never sent more than one.
This is not a rare edge case. It is the pattern behind CVE-2025-48757, where missing Row Level Security exposed data in 170+ Lovable-built apps. The apps all worked. That was never the question. Start with our guide to Supabase RLS policies if your app has a database, and our guide to finding exposed secrets if it has keys. It has keys.
Reliability: the happy path is the only path
AI code assumes the network is up, the API answers, and the user clicks in the right order. Real life does none of that.
The common finds: no retry when a call fails. No transaction around a two-step write. A crash halfway leaves half an order in the database. Two requests racing for the same row with no lock. The demo never hits these. Month two of real traffic hits all of them.
Performance: it works, slowly, later
The classic AI pattern is a query inside a loop. Load 50 users, then run one query per user. That is 51 queries where one would do. With ten rows of test data, nobody notices. With real data, the page takes eight seconds and users leave.
Missing indexes are the same story. So are giant script bundles that ship a whole library for one function. None of this fails a demo. All of it fails a launch.
Monitoring: silence is not health
Ask yourself one question: if your app started failing for all your users right now, how would you find out? For most AI-built apps, the honest answer is "a customer email." The AI wired up zero error tracking, zero alerts, and zero useful logs. None of those make the demo look better.
It is the dullest fix on the list, and the cheapest. It is also the difference between a five-minute incident and a five-day one.
Why nobody catches it before launch
In a normal team, a senior engineer looks at the change and says "wait, why is this endpoint public?" That safety net does not exist in vibe coding. The person shipping the app often cannot read the code the AI produced. That is not a dig — it is the whole point of these tools. But it means nobody is looking for the gap, so nobody finds it. Until someone outside does.
The numbers back this up. Symbiotic Security scanned 1,072 AI-built apps: 98% had at least one flaw, and 16% had critical issues. Our own scans of 100 apps averaged 42/100. The tools are good. The unchecked defaults are not.
There is a fingerprint side to this too. AI tools leave tells in production — our scanner treats a public /.cursorrules file as a near-certain Cursor tell (platformFingerprintScanner.js:208 scores it at 0.93 confidence). If we can tell which AI built your app from the outside, so can someone hunting for that tool's known defaults.
One legal note while you are here
If your app has an AI feature and EU users, the EU AI Act's transparency rule (Article 50) applies from August 2, 2026. Users must be told they are talking to an AI. Fines for that breach run up to €15 million or 3% of global turnover. AI builders do not add the notice by default. Our EU AI Act guide for SaaS founders covers it, and the Compliance Wing checks it.
What to do this week
- Run the free scan on your live URL. Get the baseline number.
- Check your database rules with the Supabase RLS checker. Owner-scoped policies on every table. No
USING (true). - View your page source. Search for key prefixes. Rotate any private key you find, then move it server-side.
- Test your rate limits with the rate limit checker. Login, reset, and API routes first.
- Set security headers at your host, and confirm them with the header checker.
- Add error tracking and one alert. Any is better than none.
- Re-scan. Fixes interact, and the score tells you what moved.
The demo says it works. Find out if it is safe.
One free scan of your live URL. One score out of 100. About 30 seconds. No code access.
Run the free scanWhat a real check costs
The free scan is $0. The full Launch Readiness Audit is $499 one time. You get a branded PDF with each finding and a ranked fix plan with time estimates. You also get a benchmark against 200+ audited apps and a senior review of each finding. See a sample report and how we test before you spend a cent. Ongoing scans run from $149/mo. For the full pre-launch path, our vibe coding security guide is free and covers all four dimensions.
FAQ
Why is AI-generated code insecure by default?
AI models are graded on producing code that compiles and runs. Attack resistance never shows up in that grade. Rate limits, access rules, and input checks get skipped unless someone asks for them by name.
Can an AI-built app pass QA and still be unsafe?
Yes. QA checks whether the button works. It does not check whether the button leaks data to the wrong user. Working and safe are two different tests, and AI tools only train for the first.
What breaks first in AI-built apps?
Security, and usually access control. Symbiotic Security scanned 1,072 AI-built apps and found 98% had at least one flaw. Open database rules and exposed keys lead the list.
Do AI tools also skip reliability and performance?
Yes. AI code handles the happy path and little else. Missing error handling, race conditions, and N+1 query patterns are standard findings, because none of them show up in a demo.
How do I check my own app?
Run the free Launch Ready Code scan on your live URL. No code access, about 30 seconds, and you get a score out of 100 across security, reliability, performance, and monitoring.
What does a full audit cost?
The scan is $0. The full Launch Readiness Audit is $499 one time: a branded PDF, a ranked fix plan with time estimates, a benchmark against 200+ audited apps, and a senior review of every finding.