What Actually Breaks in AI-Built Apps: The Incident Record | CloudWeld

Security

What Actually Breaks in AI-Built Apps: The Incident Record

CloudWeld TeamJune 29, 202611 min read

AI app builders are genuinely astonishing. A non-technical founder can describe a product on a Monday and have paying users by Friday. That is not hype; it is happening at enormous scale. What is also happening, at the same scale, is that a predictable set of things break the moment those apps meet real users.

This is not a warning about what might go wrong. It is a record of what already has. Every failure below is documented, named, and in most cases has a CVE or a security firm’s report attached to it. If you have shipped something built with Lovable, Bolt, Cursor, Replit, or Claude Code and it now has real users, you should read this as a checklist, not a horror story.

A record, not a hypothetical

The individual incidents are worth seeing together, because the pattern only becomes obvious in aggregate. Different tools, different founders, different products, and the same handful of root causes over and over.

That last row is the one that should stop you. A single security firm scanned roughly 380,000 publicly reachable AI-built apps and found about 5,000 holding sensitive corporate data, with around 2,000 exposing genuinely private information (Axios covered the findings). This is not a handful of unlucky founders. It is a base rate.

The five ways AI-built apps break

Sort every one of those incidents by root cause and you get the same short list. These are the five failure modes we find, in some combination, on almost every AI-built app that comes to us with real users.

1. Access rules that do not actually block anything. This is the big one. Modern app builders lean on tools like Supabase, where a feature called Row Level Security decides who can read which rows. AI builders frequently generate tables with those rules missing or wide open. The app looks fine, because in the demo you are logged in as yourself. Query the database directly as a stranger and the whole table comes back. That is exactly the Lovable and Moltbook failure.

2. Secrets shipped to the browser. Anything in your frontend code is public, including API keys. GitGuardian measured AI-assisted commits leaking secrets at roughly twice the rate of human-only ones, and logged 28.65 million new hardcoded secrets on public GitHub in 2025 alone (State of Secrets Sprawl 2026). The consequences are not abstract: founders have had attackers use a leaked Stripe key to refund every paying customer, and to run up tens of thousands of dollars in fraudulent charges.

3. Authentication that is present but not attached. Sometimes the login screen exists and works, but a specific endpoint behind it was never actually protected. That is the Base44 bypass: the front door was locked, and a side window was wide open. Agents are very good at building the thing you asked for and silently skipping the guardrail you did not think to ask for.

4. No safety net underneath. No staging environment, no scheduled backups, no rollback, no separation between the AI’s workspace and the live database. So when one bad generation goes sideways, there is no undo. Replit’s agent deleting a production database during an explicit code freeze is the famous version, but the quiet version, one careless change with no way back, happens constantly.

5. A codebase nobody can actually own. The app works, and no human can explain why. The first time you hire an engineer, face a security review, or try to fix a subtle bug, the answer to every hard question is the same: the AI wrote it. That is not a moral failing. It is an operational risk with a name, and increasingly a line item in due diligence.

Why it is always the same five things

There is a single reason the list is so consistent. AI builders optimize for the demo, and the properties that make software production-grade are precisely the ones a demo never touches.

Nobody demos a restore from backup. Nobody demos what the API returns to a logged-out stranger. Nobody demos month three of dependency updates, or the tenth engineer trying to understand the auth flow. So the generated app does not have those things, and nothing in the build loop tells the founder they are missing. The gap between “it works” and “it holds” is invisible right up until a real user, or a real attacker, walks into it.

This is also why the failures cluster at the boundaries: the database, the secrets, the auth edge, the deploy. The happy path in the middle is usually fine. It is the edges, the parts a demo glides past, where everything breaks.

What the platforms fixed, and what they did not

To their credit, the platforms responded. Lovable now runs an automatic security scan before publishing. Supabase ships a security advisor that flags missing access rules. Replit added a security center after the database incident. These are real improvements, and they catch the most famous mistakes.

They also have a hard ceiling. Independent testing has shown these scanners can confirm that an access policy exists without testing whether it actually blocks the right things. And none of them touch the failures that are not about a single misconfiguration: whether your backups restore, whether your secrets have ever been rotated, whether anyone can take the codebase over. Detection of the obvious holes is now cheap and automated. Judgment about the rest, and the actual remediation, still needs a human who has run production systems.

Test your own app in ten minutes

You do not need us to find the first-order problems. Two checks catch a surprising amount.

First, hit your own API as a stranger. Open the network tab, find a request that returns data, copy it, strip the auth header, and run it from a terminal:

# What does your API return to someone who is NOT logged in?
curl -s https://your-app.example.com/api/rest/v1/users \
  -H "apikey: YOUR_PUBLIC_ANON_KEY"

# If this returns other people's rows, so can anyone on the internet.

If that comes back with data that is not yours, your access rules are not doing their job, and you have found the Lovable failure in your own product. Second, open your deployed frontend, view source, and search it for the words key, secret, and token. Anything that looks like a live credential is public and needs to be rotated and moved server-side today.

These two checks are not a security audit. They are the smoke alarm. If either one trips, the building is already on fire.

The short list

If you do nothing else to an AI-built app that has real users, do these five things. In our experience they close the large majority of what actually gets exploited.

1. Test your access rules from the outside. Query your own API logged out and as a different user. If you can see data you should not, so can everyone else. Fix the rules until the stranger gets nothing.
2. Get every secret out of the browser. Move keys server-side, rotate anything that ever shipped to a client, and add secret scanning so the next leak is caught in the commit, not the breach.
3. Separate the agent from production. Your AI tools work on a branch and a staging environment, never against the live database. One bad generation should never be able to reach real user data.
4. Keep backups you have actually restored. A backup you have never tested is a wish. Schedule them, then do one real restore drill so you know it works before you need it.
5. Add monitoring before customers do it for you. Error tracking and uptime alerts, so the first person who hears about an outage is you, from a notification, not a churning user from a support ticket.

None of this requires throwing away what you built or abandoning your AI tools. It is a few days of focused work by someone who knows where these apps break, wrapped around the product you already have.

Production-Ready Sprint

Real users on an AI-built app?

We fix exactly these five things in a fixed-price, two-to-four-week sprint, and hand you a runbook so it stays fixed. If something already leaked, we can start with 72-hour emergency triage.

Book a Free TeardownHow the Sprint Works

Continue Reading

Related Articles

[

ai-codebases-investor-diligence

Production

Your Codebase Is 95 Percent AI-Generated. Investors Now Check.

CloudWeld

AI-generated codebases stopped being a curiosity and became a due-diligence line item. What technical reviewers actually look for, what it does to your valuation, and how to be ready before the data room opens.

10 min read

](/blog/ai-codebases-investor-diligence)[

mcp-servers-that-survive-production

MCP & Agents

Most MCP Servers Die Before Production. Yours Does Not Have To.

CloudWeld

Audits show more than half of public MCP servers are dead and fewer than one in five are production-ready. The reasons are consistent: authentication, tool design, and a spec that keeps moving. Here is what production-grade actually requires.

11 min read

](/blog/mcp-servers-that-survive-production)[

the-flat-rate-ai-era-is-over

AI Costs

The Flat-Rate AI Era Is Over. Here Is the Math That Replaces It.

CloudWeld

In June 2026, AI coding tools and subscriptions switched from flat rates to meters, and a lot of budgets broke in the same month. What happened, why it was inevitable, and how to engineer your way back to predictable costs.

9 min read

](/blog/the-flat-rate-ai-era-is-over)