The Vibe Coding Security Risks That Never Make Your List

Moltbook shipped with its database key sitting in the JavaScript that every visitor's browser downloads. That was fine. Supabase, the database service behind it, publishes that key on purpose: it acts as a project identifier, and it is safe to expose as long as row-level security is switched on in the database it points at.

On Moltbook, it wasn't.

Wiz Research found the key by reading the page source, then used it to read and write the entire production database without logging in. The exposure covered 1.5 million API authentication tokens, 35,000 email addresses, and private messages.^[1] The team secured it within hours of being told, and the app had launched days before.

Nothing in that story is a bug. The key was published as designed. The database was configured the way the scaffolding left it. The app worked exactly as intended the entire time.

What are the unknown unknowns in an AI-built app?

They are exposure categories you do not know exist, so they never reach any backlog. Not gaps you deferred, and not corners you cut. The tool made a decision in a layer you had no reason to open, for a class of problem nobody told you to check.

The frame comes from Donald Rumsfeld, and it holds up better here than it usually does anywhere.

Known knowns: the app works, the features ship, people are using it. Known unknowns: you skipped tests, monitoring isn't set up, the auth is basic and you know it. That second category gets unfairly maligned. It is a list, you wrote it, and you will get to it. Carrying risk you have named and priced is ordinary engineering.

The third category is the one that does the damage, and it is not a longer version of the second. It is not on the list at all.

Four exposures that never make the list

Each of these has the same shape. The thing a reasonable person would inspect looks correct, and the thing that actually settles whether you are exposed lives one layer away, in a decision the tool made while scaffolding.

The credential that is safe only somewhere else

Moltbook's key is the clean example because the credential itself was never the mistake. Supabase documents that publishable key as safe to put in front-end code, and it is, on the condition that row-level security is enabled behind it.

That condition is the entire exposure, and it lives in a database setting rather than in the code you were reading. A builder who checked the bundle, found the key, looked it up, and concluded "this one is meant to be public" did the responsible thing and still ended up wide open.

Nothing about finding it was difficult, either. Wiz described the work as browsing the site like a normal user. Asking the database for tables that did not exist returned errors naming the ones that did, and a standard introspection call filled in the rest.^[1]

The app that never needed a login

RedAccess went looking for apps built with Lovable, Base44, Replit and Netlify using ordinary Google and Bing searches. They reached about 380,000 publicly accessible assets. More than 5,000 of those had, in WIRED's description, virtually no security or authentication of any kind. Closer inspection narrowed it again: close to 2,000 appeared to be revealing private data.^[2]

Two caveats travel with that number and both belong in the room. WIRED could not confirm that the data in the apps it reviewed was as real or as sensitive as it appeared. And the count covers only apps hosted on the tools' own domains, which is why the firm's own read is that the true figure runs higher.

We used the same research to make a narrower point about what a technical assessment of an AI-built app turns up. The part that matters here is the denominator. Nobody shipped those apps believing they were public.

The data that made you responsible without asking

Scaffolding collects generously, because collecting is cheaper to generate than not collecting. A signup form picks up more than the feature needs, an analytics call goes out by default, and user input travels to a model API that logs it.

None of that involved a decision you remember making, and all of it can put obligations on you.

Whether the rules reach you at all is a threshold question with a real answer, which is why we wrote separate pieces on whether your app is in scope for data protection rules and when card data drags you into payment compliance.

Ownership of the generated code sits in the same blind spot: unsettled, jurisdiction-dependent, and almost never asked about.

The dependency you never chose

In April 2026, Vercel customers found environment variables from their own projects exposed. The path there ran through Context.ai, a third-party analytics tool whose Google Workspace OAuth application had been authorized by Vercel employees. Attackers compromised Context.ai through malware, pivoted through those tokens, and reached customer data from inside.^[3]

The builder installed nothing. They audited their own dependencies and would have passed. The connection that mattered was made by someone else's staff, inside a platform they had chosen for good reasons.

Trend Micro's write-up is also worth reading for how it handled being wrong, since much of the secondary coverage still repeats its original, overstated version.

There is a slower version of the same blindness that never becomes an incident. One study tracked 302,600 AI-authored commits across 6,299 repositories and found that 22.7% of the issues the assistant introduced were still present at the latest version of the project.^[4]

It is an unrefereed preprint, and it deserves its own post rather than a paragraph here. The point it shares with the four above is that no dashboard reports it.

Why reviewing your own code more carefully does not close the gap

The reasonable next thought is to read the output more carefully. There is a measured result on exactly that, and it is not encouraging.

Researchers ran a controlled experiment with 86 Python programmers, asking them to judge whether machine-generated assertions about code were correct.^[5] Three of their results matter here:

• On valid assertions, participants judged correctly 74% of the time.
• On flawed ones, they judged correctly 49% of the time, which is chance.
• Their reported confidence was about the same either way.

Explanations did not rescue it. Natural-language descriptions of the generated code produced no overall benefit, and low-quality ones reduced accuracy while raising how confident people felt.

Read that against the four exposures. Careful reading detects flawed output at chance even when a programmer is looking directly at the thing and knows they are being tested. The exposures above are not on screen at all.

What actually surfaces an unknown unknown

Someone who is not you, who knows where these tools make silent decisions, looking at the whole stack rather than the code.

That is not a criticism of the person who built the app, and it is not an argument for building more slowly. The blindness is structural.

You cannot audit a category you have never heard of, and the person who made the thing is the worst-placed person to notice which questions never came up. That is true of every builder in every medium, and it is the reason outside review exists at all.

What changes with AI-built software is the volume. The tool scaffolds an entire application, including the parts you never reviewed, and every default it picks is a decision that was made without you in the room. More of the app arrives pre-decided, so more of it sits outside anything you would think to check.

We keep the structured version of that check in a separate piece: what to actually look at before calling an AI-built app production ready. This post deliberately does not give you the list, because a list is the wrong instrument for the problem it describes.

Every one of those apps was working exactly as the person who built it intended.