You built it in a weekend. Who checked it?

Something genuinely good is happening. A person with an idea and no engineering background can now describe an app in plain language and have working software appear. People are building booking tools, marketplaces, and small social apps in a weekend, and real customers are signing up. That is a gift. It is also the problem, because the same weekend that produced a live product rarely included the step where someone asked whether the data behind it is safe.

It usually is not the founder's fault. The tools are optimized to make something that works, and "works" and "secure" are different questions. An app can greet every user perfectly and still, underneath, let anyone on the internet read everyone's records. The founder cannot see that gap, because from the outside the app looks fine. The people who can see it are the ones scanning for it, and lately they have been finding a lot.

Four scans, one pattern

Over the past year, several security teams have scanned large numbers of apps built with AI tools, and the results rhyme. In May 2026, the firm RedAccess reported finding more than 5,000 AI-built apps with almost no authentication at all, out of roughly 380,000 public assets it examined across popular building platforms. About 40% of the weak apps were exposing sensitive data, including medical and financial records. The platforms disputed parts of the framing, which is fair, but the direction is hard to miss.

A separate scan by the firm Escape looked at more than 5,600 public apps built this way and catalogued what it found inside them.

What one scan of 5,600+ AI-built apps turned up

Counts of issues found by Escape in public "vibe-coded" apps.

In plain terms: across 5,600+ AI-built apps, one scan found over 2,000 high-impact vulnerabilities, over 400 exposed secrets such as keys and passwords, and 175 cases where personal data, including medical and bank details, was openly accessible. Source: Escape, October 2025. Scan counts from different firms use different methods and should not be added together.

The pattern is broad, not a few bad apps. One security firm scanned roughly 380,000 public assets built on popular app-builder platforms and found more than 5,000 apps with almost no security or authentication. About 40% of the weak ones exposed sensitive data, including medical and financial records. The platforms disputed parts of the framing, and that argument is the heart of it: security is a shared responsibility, but the builder often does not know they are holding half of it.

There is a reason this keeps happening. When researchers at Veracode tested more than 100 AI models on a set of coding tasks chosen for known weak spots, the models picked the insecure option about 45% of the time, and that did not improve as the models got better at writing code. Fluent code and safe code are simply not the same skill, for machines any more than for people.

You do not need to read code to check this

Here is the encouraging part. You do not have to become an engineer to catch the most common and most damaging failures. You have to ask a few blunt questions and run one simple test. If you built the app, you can do all of this today.

Ask who can read the database. Most modern app platforms store data in a way that is private by default only if a specific protection is switched on, often called row-level security or access rules. The single most important question to put to your platform's documentation or support is: "Is my data readable by anyone unless I write a rule to stop them?" If the answer is yes, and you have not written those rules, assume your data is open.

Do the logged-out test. Open your app's address in a private browser window, signed in as nobody. Try to reach a page that should require an account. Then, while signed in as one test user, see whether you can view another user's records by changing the obvious part of the web address. You are not hacking; you are checking the front door from the outside. If you can see data you should not, so can anyone.

The question is not whether your app works. It is whether a stranger, signed in as no one, can read your customers' lives.

Hunt for secrets in the open. API keys and passwords belong on the server, never in the code that runs in the visitor's browser. If your platform has a way to view "client-side" or "public" configuration, look there for anything that reads like a password or a long key. Anything a visitor's browser can see, an attacker can copy.

Get one real review before you grow. The moment you have real users, the stakes change, because now the data is other people's. A single professional review, before you have ten thousand customers instead of a hundred, is the cheapest insurance you will ever buy. This is exactly the check our Sentinel members get monthly: an automated audit of the app you built, read by a human, returned as a short fix list in plain language.

Signs your app may already be exposed

Some warning signs are visible without any tooling. If your app never asked you to set up access rules and simply worked, that is a flag, not a convenience. If you can reach account pages without logging in, that is a flag. If your platform sent a notice about a misconfiguration and you were not sure what it meant, that is the most important flag of all, and the right move is to ask someone, not to wait.

The builders in these stories were not careless. They were fast, and the safety step was invisible, so it got skipped. The fix is to make it visible again, once, before the data you are holding becomes someone else's problem and your headline.

What to look out for

The founder's five-minute audit

1. Data open by default. Confirm your database is private unless a rule allows access, and that you wrote those rules.
2. The logged-out test fails. If a private browser window, signed in as nobody, can reach account data, your app is exposed.
3. One user can see another's records. Changing an ID or address in the URL should never reveal someone else's data.
4. Secrets in the browser. API keys or passwords visible in client-side code can be copied by any visitor.
5. A misconfiguration notice you did not act on. Treat any security warning from your platform as urgent, and ask for help.
6. Real users and no review. Once the data is other people's, get one professional check before you scale.

Sources

1. Axios, on RedAccess's findings in AI-built apps, 2026-05-07.
2. Escape, methodology and findings from scanning vibe-coded apps, 2025-10.
3. Axios, on RedAccess's finding of 5,000+ insecure AI-built apps, 2026-05-07.
4. Veracode, 2025 GenAI Code Security Report, 2025-07-30.
5. Wiz, on the exposed Moltbook database, 2026-02.