Moltbook's Supabase Leak: A Vibe-Coding Postmortem
October 7, 2026 · 1308 words
| Item | Detail |
|---|---|
| What it is | A social network where AI agents post, comment and vote; humans can watch |
| Builder | Founder Matt Schlicht, who said he wrote none of the code himself; background not covered here |
| AI tool | Not named; described as vibe-coded |
| Stack | Supabase (hosted Postgres database) per Wiz; the rest not disclosed |
| Time to launch | Not disclosed |
| Revenue | Not disclosed |
| Source | Wiz Research, February 2, 2026 |

In early 2026, Moltbook drew wide attention as a social network for AI agents. Within days, security firm Wiz found that its production database could be read, and changed, by anyone. The exposed data included about 1.5 million agent API tokens and over 35,000 email addresses.
The team fixed it within about three hours of first contact. The site is still online today.
This is not a founder-written postmortem. It's a retelling of Wiz's public report, which is our primary source. The goal is to learn from it, not to pile on.
The one point to take away: a public Supabase key is only safe when Row Level Security is switched on.
What they built
Moltbook calls itself "the front page of the agent internet". AI agents sign up, post, comment, vote and earn karma. Humans can join to observe.
Agents authenticate with API tokens. A token is a secret string that proves "this request comes from agent X". Some agents also sent each other private messages.
The founder has been open that AI wrote the code. Wiz quotes his post on X: "I didn't write a single line of code for @moltbook."
What they expected
The bet was speed. The founder described having a vision for the technical architecture and letting AI build it.
It worked, in the sense that matters for a launch. Wiz notes that Moltbook gained significant attention in the AI community over a few days. That's the dream outcome for a vibe-coded project.
Fast growth also means fast exposure. Many new users arrive before anyone has reviewed the security setup.
What happened

Wiz researchers looked at the JavaScript files the site sends to every browser. That's normal public code anyone can view. Inside, they found the Supabase project address and its public API key.
Supabase is a hosted database service popular with vibe coders. Its public key (called "anon" or "publishable") is designed to live in browser code. Wiz explains that it's safe to expose when Row Level Security is set up. In that case it works like a project identifier.
Here, Row Level Security was not enabled. So the public key allowed full read and write access to the production database.
According to Wiz, the exposed data included:
- About 1.5 million API authentication tokens for agents
- More than 35,000 email addresses of users
- 29,631 more emails from an early-access signup list
- 4,060 private message conversations between agents, some containing third-party API keys in plain text
- About 4.75 million records in total
Wiz also confirmed write access. Researchers could edit live posts. That means someone could have changed content or planted prompt injection text for agents to read.
The report added one more finding. About 1.5 million agents were registered to roughly 17,000 human owners, an 88-to-1 ratio. Wiz says there was no rate limit on creating agents and no way to verify an "agent" was really AI.
Here is Wiz's disclosure timeline (UTC):
| Time | Event |
|---|---|
| Jan 31, 21:48 | Wiz makes first contact |
| Jan 31, 22:06 | RLS misconfiguration reported |
| Jan 31, 23:29 | First fix: agents, owners and admin tables secured |
| Feb 1, 00:13 | Second fix: messages, notifications, votes, follows |
| Feb 1, 00:31 | Write access found |
| Feb 1, 00:44 | Third fix: write access blocked |
| Feb 1, 00:50 | More exposed tables found |
| Feb 1, 01:00 | Final fix |
Wiz says all data it accessed during the research and fix checks was deleted. Reuters' coverage, carried by Ctech, cited different counts. We use Wiz's figures because Wiz did the research.
The real reason
The root cause was one missing setting: Row Level Security (RLS).
RLS is a Postgres feature that Supabase relies on. It lets you write rules like "a user can only read their own messages". The database checks the rule on every request. Without RLS, the public key can see every row.
This mistake is easy to make. The app works perfectly in testing, because nothing checks permissions. You only notice when someone reads data they shouldn't.
Wiz frames it as a tooling gap, not a verdict on vibe coding. Its point is that today's AI tools don't yet reason about access control on a developer's behalf. Wiz argues the fix is to elevate vibe coding, not slow it down. For example, AI assistants could enable RLS by default.
What to do instead
- Turn on RLS for every table before launch. Then add one policy per action you want to allow.
- Test with only the public key. Query your own tables as an anonymous visitor. You should get nothing back.
- Treat write access as the bigger risk. Leaks are bad. Silent edits to content, prices or agent instructions can be worse.
- Rate-limit signups and key creation. Stop scripts from creating millions of accounts.
- Don't store secrets in user content. Warn users, or detect and block API keys in messages.
- Have a fast response path. Moltbook shipped several fixes within hours. A clear security contact makes that possible.
If you vibe-code this
This app type is a Supabase-backed social app that stores tokens, emails and private messages. Here are the checks I'd run on any app like it:
- Enable RLS on every table. Then write explicit policies. See Supabase RLS for vibe coders.
- Keep the service role key server-only. It bypasses RLS completely. See environment variables security.
- Lock down storage buckets too. Files have their own access rules. See storage bucket security.
- Rate-limit signups and token creation. See API rate limiting.
- Assume posts will be read by AI. Plan for prompt injection in user content. See prompt injection.
Here is a minimal RLS setup for a private messages table:
-- Turn on RLS: with no policies, the public key sees nothing
alter table public.messages enable row level security;
-- Only the two people in a conversation can read it
create policy "participants can read messages"
on public.messages for select
to authenticated
using (auth.uid() = sender_id or auth.uid() = recipient_id);
After that, request the table from your own project with only the public key. With no public policy, you should get an empty list.
Running a Supabase app you built with AI? Email [email protected] for a vibe-code security audit.
Key takeaway
Moltbook's exposure came from one missing switch, not an exotic attack. The public key did exactly what it was designed to do. Without RLS, that meant full access. If you use Supabase, turn on RLS and test as a stranger before you share your link.
More case studies: Vibe-coded apps making money · Security basics: Vibe coding security guide