We rebuilt 318 AI-built apps. About 1 in 4 let strangers read personal data.

01 · Summary

Five things we found.

1. PatchLabs lab study, Nov 2026. 500 public repos sampled, 436 run, 318 built a working database in the lab.
2. 106 of 318: 70 (22%) readable by anyone with the app’s public key, 36 (11%) by anyone who signs up.
3. Removing businesses’ own public contact details, using the false-alarm rate from the fix study (4 of 24 flagged apps, n=24, 5 Nov 2026).
4. Autonomous pipeline on 20 new apps from the study, 9 Nov 2026, n=20. The other 2 went to a person.

1. 01

   About 1 in 4 public AI-built apps expose personal data to people who shouldn’t see it. Emails, phone numbers, addresses and dates of birth, readable with nothing more than the key every visitor already has, or a throwaway account.

2. 02

   A third of the leaks need a sign-up, and outside scans can’t see them. 36 of the 106 apps leaked only to signed-in users. The public studies we reviewed test only as a logged-out visitor, so they miss this group entirely.

3. 03

   The cause is a handful of access-rule patterns. Row level security never switched on, or read rules that say yes to everyone (using (true)) or to anyone signed in. Each has a stable ID in our finding index.

4. 04

   Most fixes can be written and proven by machine, cheaply. 18 of 20 passed a strict three-identity lab proof with no human; 15 needed only the smallest model. Median model cost $0.46 and 3.5 minutes per app.

5. 05

   Proven isn’t the same as safe to ship blind. Closing a leak can break a page or needs a business decision. In an earlier study only 4 of 20 fixes were safe to apply with no human review. That’s why an engineer approves every change.

02 · The funnel

From 500 sampled repos to 106 exposing personal data.

We drew a random sample of 500 public GitHub repos with a Lovable/Supabase project layout and ran 436 of them through the lab. In 318 the migrations built a working database; those 318 are the denominator for every exposure number in this report. The 118 that didn’t build are excluded, not counted as safe.

Not every hit is a person’s private data. When fix agents examined 24 flagged apps closely, 4 (about 1 in 6) were a business’s own public contact details, such as a shop’s phone number on its own listing. Applied to the 106, that leaves about 88 apps, or 28%. We quote 25–28% rather than one figure because the false-alarm rate comes from a small sample. Either way it rounds to about 1 in 4.

03 · Who could read it

Two thirds leaked to anyone. One third leaked to anyone who signs up.

Every Supabase app ships a public key inside its pages; access rules decide what that key can read. We tested each rebuilt database as two outsiders: an anonymous visitor holding only that key, and a signed-in stranger, a second test user who owns none of the rows.

04 · What leaked

Profiles, other people’s records and private messages.

We counted a table as leaking when an outsider could read at least one seeded row with a personal column: email, phone, address or date of birth (and similar names such as dob, ssn or passport). For the 20 apps in the autonomous run we can say what kind of table leaked. They had 37 leaking tables between them.

The pattern is consistent: the table everyone thinks of (users) is only part of it. Apps also expose the people their users deal with: suppliers, staff rosters, sellers’ contact details, and logs of private conversations.

05 · Why it happens

Four patterns behind the leaks.

AI builders write access rules quickly and make the app work first. The rules that make a permissions error disappear are the same rules that open the table. These are the patterns we see, each with a page showing the vulnerable SQL, a self-check and the fix.

create table public.leads (…);
-- no "enable row level security"

create policy "Viewable by everyone"
  on public.profiles for select
  using (true);

create policy "Logged in users can view"
  on public.bookings for select
  using (auth.uid() is not null);

-- public by design: name, city, photo
-- leaking: email, phone

Supabase’s own linter deliberately does not flag public read rules, because they are often intended. That is a reasonable choice for a linter, and it is exactly why these leaks survive: only knowing what the table holds, and who should see it, tells you whether using (true) is a feature or a leak. All findings

06 · Mistake or intended?

Most leaks were mistakes. Some were public tables leaking private columns.

Before writing a fix, the agent reads the app’s code to judge intent: which pages read the table, whether they are logged-out pages, and which columns they use. Across the 37 tables in the autonomous run, it reached these verdicts:

In the earlier fix study the agents caught 4 false alarms in 24 apps on their own, all of them a business’s own public contact details (5 Nov 2026, n=24). A pure rules-based scanner can’t make that call. It either flags every public read, and drowns you in noise, or flags none, and misses the leaks above.

07 · The fixes

18 of 20 fixes passed a strict lab proof with no human involved.

On 9 Nov 2026 we gave the pipeline 20 leaking apps from the study that had never been through a fix agent (14 readable by anyone, 6 by any signed-up user). It rebuilt each database, wrote a fix with the smallest Claude model, and ran an independent proof. A fix passes only if the anonymous visitor and the signed-in stranger can read neither the private rows nor the personal columns, and the owner still reads their own row and its personal columns. If the proof fails, the attempt is discarded and the next model tries.

What the fixes looked like

Three shapes, matching the verdicts. These are synthetic examples of each shape, not code from any studied app.

drop policy "Profiles are viewable by everyone" on public.profiles;
create policy "Users can view own profile" on public.profiles
  for select to authenticated using ((select auth.uid()) = id);

-- The directory stays public; contact details don't.
revoke select on public.sellers from anon;
grant select (id, shop_name, city, avatar_url) on public.sellers to anon;

-- No SQL. The flagged column is the business's own public phone number.
-- Question for the owner: keep it visible on the listing page? Recommended: yes.

The agent also judged the risk that each fix changes how the site behaves: low for 18 of the 20 apps, medium for 2. It wrote 18 plain-English questions for owners across the 20 apps, each with options and a recommended answer, for the decisions code can’t make.

A separate study on 5 Nov 2026 had already re-run every agent fix by hand: 19 of 20 real fixes worked first time and applied cleanly (n=20).

08 · Cost and time

Median $0.46 and 3.5 minutes per app. Here is the whole spread.

Medians hide tails, so here is every app. Cost is the model spend reported for each fix attempt, summed per app. Time is the agents’ working time, summed across attempts; rebuilding the database and each re-verification added seconds on top (a median of 2 and 3 seconds in this run).

14 of 20 apps cost under $0.50. The 15 apps fixed by the smallest model had a median cost of $0.41 and never exceeded $0.76. The tail comes from escalation: the most expensive app went through all three models and cost $15.65 over 67 minutes. That is why every check now has a spend cap: a free check can’t run away.

Why smallest first? In a trial on 3 apps the same fixes cost an average of $2.26 per app on Opus, $0.83 on Sonnet and $0.25 on Haiku (9 Nov 2026, n=3). In that trial Haiku’s first attempts failed 2 of 3 until the verifier’s verdict was made explicit, which is the point: a cheap model is only safe behind an independent proof that refuses to pass a fix that locks the owner out or leaves strangers a way in.

Every run

Ordered by cost. No table names, repos or owners.

Cost is model spend only. It excludes the lab machine and any human time. Prices are those in effect in November 2026.

09 · The two failures

Two apps went to a person. Both for good reasons.

In both cases no model produced a fix that passed the proof, so the pipeline made no fix branch and the report said “needs a person”. That is the behaviour we want: a fix that can’t be proven isn’t presented as one.

10 · Where people are still needed

A proven fix still needs an engineer’s yes.

Passing the lab proof means the leak is closed and the owner keeps access, on the database the migrations build. It does not mean the change is safe to deploy with nobody looking. In the 5 Nov study (n=20 real fixes), only 4 of 20 (20%) were safe to apply with no human review. The reasons were rarely the agent’s skill:

Most of these are questions for the app’s owner, not engineering work. So PatchLabs writes them as plain-English questions with a recommended answer, and the owner’s engineer approves the final change. Nothing reaches the live app until they do.

11 · Other studies

Why our number is higher than outside scans.

Other public studies of AI-built apps probe live sites from the outside, as a logged-out visitor. That is a useful, different measurement. Ours rebuilds the database and reads it as each kind of user, so it sees two things outside scans can’t: read rules that are open by design (using (true)) and leaks that need a sign-up.

Third-party figures as published by their authors, checked Nov 2026 (source). The studies use different samples and definitions, so the figures are not directly comparable. Our own text scan undercounted for the same reason outside scans do: it reads rules as written, not what the final database allows.

12 · Limitations

What this study can’t tell you.

• Public repos only. The sample is public GitHub repos with a Lovable/Supabase layout. Private and commercial apps may be better or worse.
• The lab is only as complete as the migrations. 118 of 436 repos didn’t build and are excluded. Changes made in a dashboard but never saved as a migration are invisible to us, so a repo can differ from the live app in either direction.
• Personal data is detected by column name (email, phone, address, date of birth and similar). Oddly named columns can be missed; public business contacts can be counted, which is why we adjust.
• The 25–28% adjustment comes from a small sample (4 false alarms in 24 apps). Treat it as an estimate.
• Fix results are small samples: n=20 on 5 Nov and n=20 on 9 Nov, one run each. Costs depend on model prices at the time.
• The proof covers reads by three identities. Write rules, functions and storage were checked statically, not proven in the lab.
• Readable is not the same as read. We never touched live apps, so we can’t say whether anyone actually took this data.
• We sell a product that fixes this. The study was designed and run by PatchLabs and has not been peer reviewed. That is why the method and the aggregate data are public.

13 · Disclosure

How we handled other people’s apps.

14 · Data and citation

Take the data. Check our working.

Cite this report

@techreport{patchlabs2026onein4,
  author      = {Dhillon, Manraj Singh},
  title       = {The 1-in-4 Report: personal-data exposure in AI-built apps},
  institution = {PatchLabs},
  year        = {2026},
  month       = nov,
  url         = {https://patchlabs.dev/research/1-in-4}
}

Quoting a number? Please keep its sample size: “about 1 in 4 of 318 rebuilt public apps (PatchLabs, Nov 2026)”. Journalists and researchers can reach the author at manraj@patchlabs.dev.