In early 2026, an AI-built social network called Moltbook launched to a wave of attention. Its founder said openly that he “didn’t write a single line of code” — the whole thing was built with AI. Within days, security researchers at the firm Wiz found that the app had exposed roughly 1.5 million API authentication tokens and 35,000 email addresses. (reported here)
It’s easy to read that as a “look how reckless” story. It isn’t. It’s the clearest possible illustration of a gap that almost every AI-built app has — and it’s worth every non-technical founder understanding exactly what went wrong.
What actually happened
The cause wasn’t an exotic hack or a clever attacker. It was two of the most common vibe-coding defaults, shipped straight to production:
- The app’s Supabase API key was sitting in the client-side code, readable by anyone who opened the browser’s developer tools.
- Row-level security was off, so that key wasn’t just an identifier — it was full access to the database behind it.
Neither of those throws an error. Neither shows up as a failing test. The app worked perfectly, demoed perfectly, and launched — and the door to every user’s data was wide open the whole time. To the founder’s credit, once it was flagged, it was fixed within hours. But by then researchers had already walked through it.
The lesson isn’t “don’t build with AI”
Building a working product with AI tools, as a non-technical founder, is genuinely remarkable. Moltbook existed and had users because of vibe coding, not in spite of it. The tool wasn’t the failure.
The failure was that nobody read the code before real data went behind it. A secret in the client and a database with no access rules are exactly the two things a senior engineer checks in the first ten minutes — and exactly the two things that are invisible from the dashboard. There was no review step between “it works” and “it’s live”, so the most basic possible mistakes sailed through.
What to take from it
If you’re building with AI and you can’t personally read the code, you have a blind spot — not because you did anything wrong, but because the person who’d normally catch these issues isn’t in the loop. The build flow doesn’t add them, and the AI that wrote the code shares the blind spots that created the gap.
You don’t need to become an engineer. You need one read, once, before real users arrive — someone who opens the code with an adversary’s eye and checks the handful of things that turn into a Moltbook. Start with the free 2-minute self-check to see whether the obvious doors are open.
That’s the entire point of a production-readiness audit: a senior engineer reads your actual code — the way Wiz’s researchers did, but before you launch instead of after — and tells you in plain English what to close. Moltbook’s mistakes took minutes to find. The only difference that matters is whether someone looks before or after real data goes behind it.