Moltbook exposed 1.5 million API keys in its first week. The fix was one setting.

Moltbook opened to the public at the end of January 2026. It was a social network where AI agents, not people, did the posting: agents wrote, commented, voted and built up karma, while their human owners watched. It spread fast, the way strange internet things do.

On 31 January, researchers at Wiz reported to the team that they could read the entire production database. They could also change it. Their write-up, published on 2 February, lists what was reachable: roughly 1.5 million API authentication tokens belonging to agents, about 35,000 email addresses of the humans who owned them, another 29,631 emails from a separate observers table, and 4,060 private messages between agents. Some of those messages contained plaintext OpenAI keys that owners had pasted in. None of this required breaking anything: the researchers used a key the site handed to every visitor.

What actually went wrong

Moltbook ran on Supabase, a popular backend for apps built with AI tools. Supabase gives every project a public key that ships inside the website's JavaScript. That's by design: your app needs it to talk to the database from the browser.

The public key is safe only because of a second thing called Row Level Security, or RLS. RLS is a set of rules on each table that say who may read or change which rows. "A user can read their own messages." "Nobody can read the tokens table." With RLS on and sensible rules in place, the public key lets people do only what those rules allow.

On Moltbook, RLS was not enabled on the tables that mattered. Wiz found the Supabase credentials in a production JavaScript file, used them the way the app itself would, and the database answered every question they asked. With no rules in place, the public key worked like a master key.

The founder had said publicly that he "didn't write a single line of code" for Moltbook, and that AI built it from his vision of the architecture. That's a legitimate way to build now. It also explains the gap. AI tools are very good at producing the queries an app needs to work, and far less reliable at producing the rules that stop strangers running those same queries. Nothing looks broken when the rules are missing. The app works perfectly for you, and just as perfectly for anyone else.

Why write access made it worse

Most leak stories are about reading data. Moltbook's key could also write. Wiz noted they could modify existing posts, which on a platform built around what agents say means anyone could have put words in any agent's mouth. With 1.5 million agent tokens exposed, someone could also have acted as those agents through the API.

Write access is the thing to worry about most in your own app. A leaked email list is bad. A stranger quietly editing prices, flipping a user to "paid", or deleting rows is worse, and much harder to notice.

The fix was small

The Moltbook team patched it in about three hours from the first report. That speed is worth noticing. The fix was turning RLS on and writing policies for each table. That's an afternoon of work if you do it before launch, and an emergency with your name in the headlines if you do it after.

Check your own app in ten minutes

You don't need to be technical for this. You need your app open in Chrome or Firefox and two test accounts.

1. Sign in to your app as test account A. Open the developer tools (right click, Inspect) and go to the Network tab. Use the app normally for a minute.
2. Look for requests going to a URL ending in supabase.co. Click one. In the request headers you'll see apikey. That's your public key, and it's fine that you can see it.
3. Now ask your AI coding tool to write you a one-line curl command that selects everything from one of your tables using that key and no user login. Run it in a terminal.
4. If rows come back that an anonymous visitor should never see, you have the Moltbook problem.
5. Repeat while signed in as account B, asking for account A's rows. If they come back, your rules exist but don't check ownership.

If step 3 or 5 returns data, open the Supabase dashboard, go to each table, and check that RLS is enabled with a policy that ties rows to auth.uid(). Our pre-launch security checklist walks through this as its first item, because it's the single most common serious finding in AI-built apps.

The part people get wrong afterwards

After a story like this, some founders try to hide the public key: move it to an environment variable, obfuscate it, rotate it every week. None of that helps. The key ends up in the browser because the browser needs it. The protection has to live in the database rules.

The other mistake is to take the platform's security scan as the final word. Lovable, Supabase and others now warn you when a table has RLS turned off, and that catches the Moltbook case. It doesn't tell you whether the policy you wrote is correct. A policy that says "any signed-in user can read any row" passes the "is RLS on?" test and still leaks every customer's data to every other customer.

That's why we test the running app from the outside, the same way Wiz did, with real accounts trying to reach each other's data. If you'd rather not do it by hand, that's what a VibeGuard check does, from €59. Either way, run the ten-minute test above today. It costs nothing, and it's the first thing anyone looking at your app will try.