How AI-built apps expose customer records (and how to prevent it)

An app built by AI can look finished, work perfectly for the person who built it, and still hand your customer list to anyone who knows where to look. That is not a hypothetical. Since early 2025, independent researchers have scanned thousands of AI-built apps and found customer names, emails and other records readable by strangers. Platforms themselves have shipped flaws that exposed private apps.

This guide is for owners, IT leads and finance leads who are about to let a team put real customer records into AI-built tools. It covers what has actually gone wrong (with sources at the bottom), the four ways exposure happens, why the same mistakes keep repeating, a test checklist anyone can run, and exactly what to require from a platform before the first record goes in.

What researchers have actually found

Each of the findings below is public and linked in the sources. They are worth reading in full, because each one points to a specific safeguard.

Missing database rules in Lovable apps (March 2025)

In March 2025, researcher Matt Palmer scanned 1,645 apps built with Lovable, one of the best known AI app builders, and found 170 of them exposed, with 303 vulnerable endpoints (an endpoint is a web address an app uses to fetch or save data). The cause was missing row-level security, the database rules that decide which rows each person may see. The flaw was recorded as CVE-2025-48757, published in May 2025 with a severity score of 9.3 out of 10. Lovable disputes the CVE, saying each customer is responsible for protecting their own app's data, according to the record in the US National Vulnerability Database.

That dispute is worth noticing. Whatever you think of it, it tells you where many platforms draw the line: the platform builds the app, and protecting the data inside it is your job.

One app, 18,697 user records (February 2026)

In February 2026, The Register reported that researcher Taimur Khan found 16 vulnerabilities, 6 of them critical, in a single app hosted on Lovable. Together they exposed 18,697 user records. One app, built quickly and shared publicly, was enough.

A platform regression that exposed projects (2026)

Platforms can expose data too. Lovable says a regression in February 2026 exposed the chat history and source code of public projects from February 3 to April 20, 2026, and that it shipped a fix within two hours of the public report. Lovable also says reports submitted through its bug bounty program from February 22 were closed without escalation. The Register reported that the company first said "We did not suffer a data breach" before apologizing. Chat history matters here because people often paste real details into the conversation while they build.

Sign-in that could be bypassed (July 2025)

Security firm Wiz found a flaw in Base44, an AI app builder owned by Wix, that let anyone who knew an app's public ID register on private apps, bypassing sign-in including single sign-on (the setup where staff log in once with their company account). Wiz reported that the fix landed in under 24 hours and that there was no evidence of exploitation.

Exposure at scale (2025 and 2026)

• Escape, October 2025: security company Escape analyzed over 5,600 publicly available vibe-coded apps (apps built mostly by describing them to AI) and found more than 2,000 vulnerabilities and more than 400 exposed secrets, meaning passwords and keys sitting where outsiders could read them.
• RedAccess, May 2026: RedAccess reviewed about 380,000 vibe-coded assets. About 5,000 were built for corporate purposes, and 40 percent of those exposed sensitive data.
• reeve.page, August 2026: a scan of 18,554 Lovable apps found that 57 percent of the 3,553 databases it could check had tables readable without logging in.
• Censys, October 2026: Censys reported that internet hosts exposing AI-related tools grew more than 63 percent between October 2025 and July 2026.

This is not new to AI

In August 2021, UpGuard found 38 million records exposed across 47 Microsoft Power Apps portals, and Microsoft first called the behavior "by design." The lesson carries straight over to AI builders: when protecting data depends on each app builder getting a setting right, many apps will ship without it.

The four ways customer records get exposed

Strip away the brand names and nearly every case above falls into one of four patterns.

Why access rules fail so often

Most AI app builders connect the app's screens to a database, often a hosted database service. The screens can be beautifully designed and still talk to a database that answers anyone. The person building sees their own records, everything looks right, and nothing on screen warns them that a stranger would see the same thing. Row-level security exists to stop this, but on many platforms someone has to turn it on and write the rules correctly for every table. AI writes those rules too, and AI can get them wrong.

Why it keeps happening

• Speed is the product. AI builders sell the ability to go from idea to published app in an afternoon. Security work is invisible when it is done and only visible when it fails.
• The builder is not a security engineer. These tools exist so people who are not developers can build. That is a strength, and it means the platform has to carry the security load because the builder cannot.
• AI output is almost right. In the 2025 Stack Overflow Developer Survey, 66 percent of developers named "AI solutions that are almost right, but not quite" as their top frustration with AI tools. An access rule that is almost right is a data leak.
• Public by default, or one click from it. Many tools make it easy to publish to the internet because that is what a startup founder wants. An internal tool for your office never needs to be public.
• Checks happen late. A scan before publishing is better than nothing, but by then the app has been built around whatever assumptions the AI made.

What is actually at risk

When owners hear "data exposure," they picture a hacker. In practice the damage is more ordinary and more expensive.

• Customer trust. A customer who learns their details were readable by anyone may not come back, and may tell others.
• Notification and legal costs. Depending on where you and your customers are and what the data is, an exposure can trigger duties to notify people or regulators. Your legal or compliance advisor decides what applies.
• Contract problems. Many business customers require you to protect their data. An exposed internal tool can put a contract at risk.
• Cleanup time. Someone has to find out what was reachable, for how long, and by whom. Without a record of activity, that question can take weeks or never be answered.

A test checklist anyone can run

You do not need to be a developer to catch the most common problems. Run these on any AI-built app before customer records go in, and again after major changes. Use test records, not real customers, until the app passes.

1. Open the app in a private browser window without signing in. You should see a sign-in screen and nothing else. If you see any customer data, stop.
2. Copy the link to a record page and open it signed out. A direct link to a specific customer should not work for someone who is not signed in.
3. Sign in as a low-access test user. Create an account with the most limited role. Confirm it sees only what that role should see, and nothing from other people or other locations.
4. Change a number in the address bar. If a record's address ends in a number or ID, change it by one while signed in as the test user. You should not be able to see someone else's record.
5. Try to sign up as a stranger. If there is any way to create an account without an invite, find out why and close it.
6. Ask where the data lives. The builder or vendor should be able to tell you in one sentence which system stores the records and who can reach it.
7. Ask what is checked before changes are saved. A clear answer names the checks. "We scan it before publishing" is a start, not an answer.
8. Remove a test user and confirm access ends. After removal, that person's sign-in should stop working immediately.
9. Check the activity record. You should be able to see who created the app, who changed it, and when.
10. Search for the app. Search the app's name and address in a search engine. An internal tool should not appear.

If an app holds health, financial or other sensitive records, add a review by a qualified security professional. The checklist above catches common mistakes; it does not replace that review. For the full pre-launch routine, see how to test an AI-built app before your team relies on it.

What to require from any platform

Testing finds problems after they exist. The better answer is a platform that prevents them by design. Ask every vendor these questions and expect plain answers.

1. Does every app live inside our company? Every request to every app should check that the person belongs to your company. Outsiders should get nothing back, not even a sign the app exists.
2. How do people get in? Look for invite-only joining, invites that work once and expire, and no public sign-up.
3. What can each role see and do? Owners, admins, builders and people who only use the tools need different powers. See role-based access, explained simply.
4. When is security checked? Every piece, as it is built, before it is saved. Not once at the end.
5. Who is responsible for the data inside our apps? If the answer is "you are," understand what that means before your team builds.
6. What record do we get? A complete history of who did what, for every app and every change.
7. What happens when someone leaves? Access should end in one step, and the apps they built should stay with the company.

If you think an app is already exposed

Act in this order. Speed matters more than perfect diagnosis.

1. Restrict access first. Take the app offline or limit it to the smallest group possible.
2. Preserve the record. Do not delete the app or its history. You will need it to answer what happened.
3. Work out what was reachable. Which records, which fields, and for how long.
4. Call your legal or compliance advisor. They decide whether customers or regulators must be told.
5. Fix the cause. Correct the access rules or sign-in, then retest with the checklist above before reopening.
6. Change the way you build. One exposed app is a symptom. Look at how apps get built and published across the team. Our guide to shadow AI covers apps your team may have built without anyone knowing.

How FORGE handles it

FORGE was built for companies that put real customer records into the tools their teams build, so the protections are part of the platform, not a setting someone has to remember.

• Every app lives inside your company. Every request checks that the person asking belongs to your company. Anyone outside gets nothing back, not even a hint the app exists.
• Only the people you invite. Your admin invites each person by email, every invite works once and expires on its own, and there is no public sign-up to slip through.
• The right access for every role. Owners, admins, builders and app users each see and do exactly what their role allows.
• Security checked before it exists. Every piece of every app is checked for quality and security before it is ever saved, and the tool is checked at every step of the build, no matter who on your team asked for it.
• A complete record. Every step of every build is recorded with who or what did it.
• People leave, tools stay. Removing someone ends their access immediately, and every tool they built stays with your company.

Your IT lead gets a full walkthrough of how FORGE handles your data during your workflow workshop, on your real work. Read more on our security page or talk to us.

Questions people ask

Sources

1. Matt Palmer: statement on CVE-2025-48757
2. NVD: CVE-2025-48757
3. The Register: AI-built app on Lovable exposed 18K users (February 2026)
4. Lovable: our response to the April 2026 incident
5. The Register: Lovable denies data leak (April 2026)
6. Wiz: critical vulnerability in Base44
7. RedAccess: shadow AI builders security report
8. Escape: how we discovered vulnerabilities in vibe-coded apps
9. reeve.page: vibe-coded app security 2026
10. UpGuard: Power Apps portals data exposure
11. Stack Overflow Developer Survey 2025: AI
12. Censys: State of the Internet 2026