An AI-built social network left its whole database readable and writable. The key wasn't stolen; one setting was missing. What happened, from Wiz's write-up, and the lesson for anyone building on Supabase.
Moltbook went viral in late January 2026 as a Reddit-style forum where AI agents post and chat. Its founder said publicly on X that he hadn't hand-written it. Wiz quotes the post: "I didn’t write a single line of code for @moltbook. I just had a vision for the technical architecture, and AI made it a reality." I'm not quoting that to mock anyone. It's exactly the kind of build this category is for. But it makes Moltbook the clearest case study we have of what an AI-built backend can miss. Everything below comes from Wiz's write-up by Gal Nagli, dated 2 February 2026, unless I say otherwise.
One missing setting, and the whole database was readable and writable. · Illustration generated with Higgsfield
1.5M
API tokens exposed
agent auth tokens (Wiz)
35,000
Email addresses
Wiz's headline figure
4,060
Private conversations
some with OpenAI keys inside
~3 hrs
Report to final fix
31 Jan 22:06 → 1 Feb 01:00 UTC
What actually went wrong, in plain English
Picture the database as a building. Supabase gives every project two kinds of key. Its docs describe them like this: "The publishable key is taped to the front door, and it only opens the lobby. The secret key is the master key, and it stays in your pocket." The publishable key has to be in your website, because the browser uses it to talk to the database. That's by design. What keeps it harmless is Row Level Security: rules on each table saying which rows each visitor may see or change. Wiz spells out the consequence: "When properly configured with Row Level Security (RLS), the public API key is safe to expose - it acts like a project identifier. However, without RLS policies, this key grants full database access to anyone who has it."
How a normal, public key became full access
The page loads
The browser downloads the site's JavaScript, like every visitor's does
The public key is in it
Normal: the browser needs it to talk to Supabase
The database checks its rules
…and there were none: no Row Level Security
It answers like an admin
Every row of every table, readable and writable
The page loads
The browser downloads the site's JavaScript, like every visitor's does
The public key is in it
Normal: the browser needs it to talk to Supabase
The database checks its rules
…and there were none: no Row Level Security
It answers like an admin
Every row of every table, readable and writable
Conceptual only. No step here is a technique; it's the chain of design facts that lined up.
That last step is the whole story. The key wasn't stolen and nothing was broken into. Wiz describes a "non-intrusive security review, simply by browsing like normal users," and finding the problem "within minutes." The database did exactly what it had been configured to do.
What was exposed
Agent credentials: API tokens for every registered agent, which Wiz says would allow "complete account impersonation" of any agent on the platform.
People's email addresses: Wiz's headline figure is 35,000. Its write-up describes owner emails for 17,000+ users, plus a separate table of 29,631 early-access sign-ups for a new Moltbook product.
Private messages: 4,060 agent-to-agent conversations. Wiz found some contained third-party credentials, including plaintext OpenAI API keys that users had shared. One app's misconfiguration exposed keys to completely different services.
Write access: after the first fix blocked reading, Wiz confirmed it could still modify existing posts. A readable database is bad; an editable one lets anyone change what an AI-agent platform's agents read next.
How it was fixed, and how fast
Wiz's disclosure timeline (all UTC) is a model of how this should go. They contacted the maintainer at 21:48 on 31 January, reported the missing RLS at 22:06, and saw the first tables secured at 23:29. A second round of tables followed at 00:13 on 1 February. They found the write access at 00:31, which was blocked by 00:44. More exposed tables turned up at 00:50, and everything was secured by 01:00. Wiz says all data accessed during the research was deleted. Security researcher Jameson O'Reilly also found the misconfiguration independently, which 404 Media reported; Wiz notes this in its post. TNW later described Moltbook as breached "within three days of launch."
Notice the shape of the fix: several rounds, each finding another table. That's what happens when RLS is added table by table after the fact. Supabase's own guidance is to do it up front: "Enable RLS on every table in an exposed schema." The picture of what RLS does, row by row, is in Row Level Security explained.
What I'd take from it if I were building on Supabase
Assume the public key is public. It is, and it's meant to be. Your safety lives in RLS, not in hiding the key.
Check every table, including the ones you forgot. Moltbook's fix took several rounds because new tables kept turning up. Ask your AI tool to list every table and its policies.
Think about writes, not just reads. A policy that stops strangers reading but not editing is half a fix.
Don't store secrets in user content. Users will paste keys into messages. If those messages aren't protected, neither are the keys.
Not in the break-in sense. Its database had no Row Level Security, so the public key that ships with every Supabase website granted full read and write access. Wiz found it by browsing the site normally and disclosed it; Moltbook fixed it within about three hours of the report.
Is it safe that my Supabase key is visible in my website?
The publishable (formerly anon) key is designed to be visible, and Supabase calls it safe to expose, but only if Row Level Security is enabled on every table it can reach. The secret (formerly service_role) key must never be visible.
What data did the Moltbook exposure include?
Per Wiz (2 Feb 2026): about 1.5 million agent API tokens, 35,000 email addresses, 4,060 private agent-to-agent conversations (some containing third-party API keys), and write access that allowed editing posts.
Could this happen to an app I built with Lovable or Bolt?
Yes, if your tables don't have RLS. TNW's April 2026 report says Bolt.new ships with row-level security off by default, and lists disabled RLS as a common failure across vibe coding platforms. Check every table before you share the app.
This page has no affiliate links or sponsored placements. Security advice is only useful if nobody's paying for it. It isn't a substitute for a security review: if your app holds other people's personal data, payments or health information, have a developer or a security professional look at it before launch.
