A straight answer for founders who built with Lovable, Bolt, Replit, Cursor, or Claude.
If you're asking this question, you're ahead of most founders, because most never ask it. They find out the answer from a customer, a security researcher, or a bill.
Here is the straight answer: your app can almost certainly be made secure, but it almost certainly isn't yet. Not because you did anything wrong, and not because AI writes bad code. Because security is a property of how your whole system fits together, and no sequence of prompts ever looked at your whole system.
This article gives you the evidence for that claim, the seven places AI-built apps actually break, and what checking them properly involves.
The numbers say assume you're exposed
Security researchers spent much of the past year scanning AI-built apps in production, and the results are consistent enough to treat as a baseline.
When security firm Escape scanned 5,600 publicly deployed vibe-coded applications, they found more than 2,000 high-impact vulnerabilities and over 400 exposed secrets such as API keys and access tokens. That works out to roughly one in three AI-built apps live on the internet with a flaw serious enough for anyone to exploit. Escape's scans of vibe-coded apps have also surfaced exposed personally identifiable information, including medical records and financial data, belonging to real users of live applications.
The trend is accelerating. Georgia Tech's tracking of CVEs, the official registry of disclosed software vulnerabilities, attributed 6 to AI-generated code in January 2026, 15 in February, and 35 in March, and the researchers consider confirmed cases a small fraction of the real total, since most AI-assisted code leaves no attribution trail.
But the most important finding for you personally comes from a Stanford controlled study by Perry, Srivastava, Kumar and Boneh: participants completing security-related programming tasks with an AI assistant wrote significantly less secure code than those without one, and were simultaneously more likely to believe their code was secure. Read that twice. The tools don't just miss security issues. They make you feel confident while missing them.
That's why "my app works fine and nothing bad has happened" tells you nothing. Every exposed app on Escape's list worked fine too.
Why prompting can't get you to secure
AI coding tools answer the question you asked. Build me a login. Add a dashboard. Let admins delete users. Each answer is competent on its own terms.
Security lives in the questions you didn't ask. Can user A request user B's data by editing a URL? Does the delete endpoint check permissions on the server, or only hide the button? Is the API key that powers your AI feature sitting in code the browser downloads? These are system questions. Answering them requires holding your database rules, your API routes, your session handling, and your hosting configuration in view at the same time, and no single prompt ever contains all of that.
So the features stack up, each one working, while the questions nobody asked accumulate underneath them. That's the security debt the researchers keep measuring, and it's invisible from the founder's side of the screen precisely because everything appears to work.
The seven places AI-built apps break
Audit enough of these apps and the findings stop being surprising. They cluster in the same seven areas, which is good news: a known list is something you can work through.
1. Authentication and access control. The most common and most dangerous gap. Apps that verify who you are but never verify what you're allowed to touch, or run the check in the browser where anyone can switch it off. This one is deep enough that we wrote a full breakdown: why AI-built app authentication is probably broken.
2. Database permissions. On Supabase and similar backends, row-level security policies are what stop one user reading another's rows. AI tools routinely skip them or set them permissively so the demo works. The interface shows each user their own data, so it looks fine, while the database answers anyone who asks it directly.
3. Exposed secrets. API keys and credentials embedded in frontend code, committed to repositories, or visible in network requests. The 400 exposed secrets in Escape's scan were not hidden cleverly. They were sitting in the open, because embedding them was the shortest path to a working feature.
4. Payment wiring. Whether your app grants access based on Stripe's server-side confirmation or on a browser redirect anyone can reach. Get this wrong and customers either pay without receiving, or receive without paying. Full breakdown here: why AI-built app Stripe integration quietly loses you money.
5. Error handling. What your app does when a payment fails midway, an API goes down, or a user submits something unexpected. In most AI-built apps the answer is undefined, because only the happy path was ever requested.
6. Deployment configuration. Debug modes left on in production, admin panels reachable from the public internet, hosting settings that expose more than intended.
7. Backups and recovery. Not a breach risk, a survival risk. Without verified backups, one bad migration or one wrong prompt can delete customer data permanently. Ask yourself when you last tested a restore. If the answer is never, you don't have backups, you have hope.
Does this mean your app is unsafe?
It means you don't know, and neither do we until someone looks. That's an important distinction.
Some AI-built apps come through review in genuinely good shape. Most need hardening in three or four of the seven areas, work measured in days. A rebuild is rarely the answer: the interface your users like and the product decisions you iterated on are usually sound, and it's the layer underneath that needs engineering. Anyone who prescribes a rewrite before reading your code is selling you a rewrite.
What separates the founders who get breached from the ones who don't isn't skill. It's whether they checked before their users did.
Get it checked properly
A meaningful security review doesn't try to "hack" your app and call it a day. It maps the whole system: every endpoint's access control, database and row-level security, secrets, the data model, payment wiring, error handling, deployment, and backups, then ranks what it finds by business impact, so you know what threatens you this week versus what can wait a quarter.
That's what our Production Readiness Audit is for. A senior engineer reviews all seven areas end to end. You get a plain-English report you own outright, every issue prioritised, delivered within 5 business days of getting access.
Book a 20-minute call and we will tell you honestly whether it is worth doing.
