Short answer: In early 2026 someone launched Moltbook, an AI “social network” where bots post to each other. The founder was proud he “didn’t write a single line of code” — he described what he wanted, and an AI built it. Three days after it went live, researchers at Wiz walked straight into the live production database and found 1.5 million API keys, tens of thousands of email addresses, and private messages with other people’s OpenAI keys sitting in plain text. Nobody picked a lock — the AI that built the app never installed one. And Moltbook wasn’t a freak event: a scan of roughly 380,000 apps built the same way found about 5,000 leaking sensitive data.
We build and host sites for a living, so here’s the plain version — what “vibe coding” gets right, where it quietly bites, and who’s supposed to be watching the door.
What actually happened at Moltbook
The whole app was “vibe-coded” — built by describing it to an AI instead of writing the code. The AI wired the site to a Supabase database (a popular ready-made backend) and, to talk to it, dropped an API key straight into the site’s public JavaScript. That’s normal — if you also switch on Row-Level Security, the setting that decides who’s allowed to read or write each row. Moltbook never turned it on.
So the key sitting in plain view in every visitor’s browser was a master key. Anyone who copied it could read and write every table in the production database. Wiz did exactly that, responsibly, and counted what was exposed:
| What was sitting open | Amount |
|---|---|
| API authentication tokens | ~1.5 million |
| User email addresses | 35,000 (+ ~30,000 from an early-access list) |
| Private messages between agents | 4,060 — some with OpenAI keys in plain text |
| Actual humans behind it all | ~17,000 |
That last line is its own story: 1.5 million “members,” about 17,000 real people. But the security point is the first three: a database open to the entire internet, read and write, three days after launch.
The part that matters: nobody was hacked
Here’s the honest framing. Wiz are researchers, not thieves — they reported it privately on 31 January 2026, and Moltbook had it patched within hours, by the next morning. There’s no evidence criminals got there first.
But that’s luck, not security. The door was unlocked and standing open to everyone; a friendly person happened to walk in first. With write access to the database, someone less friendly could have altered or deleted everything, or quietly helped themselves to the keys and messages. “We fixed it in a few hours” only works after someone tells you.
It wasn’t one weird site
You could shrug Moltbook off as a hobby project. Then a security firm, RedAccess, scanned roughly 380,000 apps built on the popular AI app-builders — Lovable, Replit, Base44, Netlify — and found about 5,000 of them leaking sensitive data (reported by Axios). Of those, around 40% exposed the serious stuff: medical and financial records, internal company documents, logs of private chatbot conversations.
The cause is dull and structural: several of these platforms make a new project public by default, and someone building without a developer’s instincts doesn’t always know to change it — or that there was a setting to change. As RedAccess’s co-founder put it, “anyone from your company at any moment can generate an app, and this is not going through any development cycle or any security check.” Lovable’s reply: “how an app is configured is ultimately the creator’s responsibility.”
Which is true. And that’s exactly the problem.
”Vibe coding” is fine — until it ships
None of this is an argument against building with AI. It’s genuinely useful: an AI can stand up a working app from a sentence, and for a prototype, an internal tool, or a weekend experiment, that’s a gift. The trouble starts the moment that thing holds real data and faces the open internet.
The AI is very good at making it work. It is not on the hook for making it safe, keeping it up, or having it still be standing in six months. It won’t turn on Row-Level Security unless asked, won’t notice the database is public, won’t be there when a dependency breaks or the keys leak. Those are exactly the boring, invisible jobs that don’t show up in a demo — and exactly where these apps fall over.
What this means if you (or your team) built something with AI
You don’t need to fear the tools. You need someone to check the locks before real data goes in:
- Assume new means public. If a tool, form or mini-app was spun up in an AI builder, treat it as world-readable until proven otherwise. Find the “public/private” and access-control settings, and check them.
- Keep secrets off the front-end. API keys and database keys belong on the server, behind access rules — not in the JavaScript every visitor downloads.
- Know who owns it after launch. A vibe-coded app with nobody maintaining it is the same orphan problem as a site whose developer disappeared — except this one may be holding customer data.
- Have someone actually look. Five minutes from a person who’s seen a database before is the difference between Moltbook and a quiet near-miss. There are even free ways to check what’s exposed.
Where we come in
“An AI can build it” and “someone should run it” are two different jobs, and the gap between them is where this whole story lives. Managed hosting is the second job: putting what you built — by hand, by an agency, or by an AI — somewhere with the settings locked down, the secrets off the front-end, backups that work, and a human who notices when something is wide open. Build it however you like. Just don’t ship it to the internet with the door propped open. (Software nobody owns anymore is the close cousin of this problem — and for who controls the code you trust, see how someone backdoored 30 WordPress plugins.)