🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4 · Curated by Tom Hundley
In March 2026, a platform called Moltbook — an AI agent marketplace built rapidly with AI-assisted coding tools — left its entire database wide open to the internet. No hacking required. No sophisticated attack. Security researchers Jamison O'Reilly and the team at Wiz simply found the front door unlocked and walked in. What they found: roughly 150,000 API keys, 1.5 million authentication tokens, 30,000 email addresses, and private user messages. All exposed. All because one database setting — Row Level Security — was never turned on.
This wasn't a failure of technology. Supabase, the database platform Moltbook used, has excellent security features. The failure was human: someone building fast with AI tools skipped the security configuration step entirely. If you're building apps with Cursor, Bolt, Replit, or Lovable and using Supabase as your database, this could be you tomorrow. Let me show you exactly what went wrong and how to make sure it doesn't.
TL;DR: Moltbook shipped a Supabase-powered app without Row Level Security, meaning anyone with the public API key (visible in the browser) could read every row in every table.
Here's the thing about Supabase that trips up vibe coders: every Supabase project comes with two keys. One is a "service role" key meant only for your server (the back room). The other is an "anon" key designed to be used in the browser — it's supposed to be public.
The anon key is like the front door to a hotel. Everyone gets to walk through it. But Row Level Security (RLS) is the system of room locks that makes sure guests can only enter their own rooms. Without RLS turned on, that front door leads to every room, every safe, every suitcase — completely unlocked.
Moltbook's developers — likely moving fast with AI-generated code — built their app, connected it to Supabase, and deployed. The AI coding tool generated working database queries. The app functioned perfectly. But nobody told the AI to enable RLS, and nobody checked. According to Wiz's research, the exposed database contained:
This is the nightmare scenario. Those API keys could be used to impersonate AI agents, rack up charges on other people's accounts, or access whatever services those keys connected to. If you've read about how AI coding assistants can leak your API keys, imagine that problem multiplied by 150,000.
TL;DR: Row Level Security is a database rule that says "users can only see and edit their own data" — without it, anyone can see everyone's data.
Let me use an analogy that actually works.
Imagine a giant filing cabinet in a public library. Every person in town has a folder in that cabinet — their medical records, bank statements, love letters, everything. Row Level Security is the rule that says: "You can only pull out your folder. Nobody else's."
Without RLS, anyone who walks into that library can open the cabinet and rifle through every single folder. That's exactly what happened with Moltbook.
In database terms, RLS is a set of policies you attach to each table. A policy is just a rule like:
user_id column matches their login"Supabase makes this relatively straightforward to set up. The problem? RLS is off by default on new tables. When your AI tool creates a new table for you, it doesn't automatically add these policies. You have to do it yourself.
According to Supabase's own documentation, they strongly recommend enabling RLS on every table that holds user data. But a recommendation isn't a default, and when you're vibe coding at speed, recommendations get missed.
| Scenario | Without RLS | With RLS |
|---|---|---|
| User queries the database | Sees ALL rows in the table | Sees only their own rows |
| Someone finds your anon key | Can read your entire database | Can only read what policies allow |
| AI tool creates a new table | Table is open to everyone | You must add policies (but data is protected) |
| Attacker tries to delete data | Can delete everything | Can only delete what policies permit |
TL;DR: If you're using Supabase with Cursor, Bolt, or any AI coding tool and haven't explicitly enabled RLS, your database might be publicly readable right now.
Let me be blunt: the Moltbook breach wasn't exotic. It was boring. It was a checkbox that didn't get checked. And it's the exact kind of mistake that happens when you're vibe coding — moving fast, trusting the AI to handle details, shipping because everything works.
Working and secure are two completely different things.
Your Supabase anon key is in your frontend code. Anyone can find it by opening their browser's developer tools. That's by design — Supabase expects the anon key to be public. The entire security model depends on RLS being enabled. Without it, that public key is a master key to your whole database.
This also connects to a broader pattern I've been writing about. Just like leaving your .git folder exposed can leak your source code, leaving RLS disabled leaks your entire database. The common thread? Deployment steps that AI tools don't do for you.
TL;DR: Go to your Supabase dashboard right now, check every table, and enable RLS — then add at least one policy per table.
Here's exactly what to do, step by step:
Go to app.supabase.com and sign in. Click on your project.
In the left sidebar, click Table Editor. You'll see a list of all your tables.
Click on a table name. Near the top, you'll see a label that says either "RLS enabled" or "RLS disabled." If it says disabled, you have an open filing cabinet.
Click the "RLS disabled" button or go to Authentication → Policies in the sidebar. For each table, click "Enable RLS."
⚠️ Important warning: The moment you enable RLS without adding any policies, nobody can read or write that table — not even your app. That's actually the safe default. Now you need to add policies.
For most tables with user data, you want these policies:
user_id equals their auth IDuser_idIn the Supabase policy editor, a basic SELECT policy looks like this:
CREATE POLICY "Users can read own data"
ON your_table_name
FOR SELECT
USING (auth.uid() = user_id);Don't worry if SQL looks foreign — that's what the next section is for.
Paste this into Cursor, Bolt, or whatever AI tool you're using:
I'm using Supabase for my database. I need you to:
1. List every table in my project that contains user data
2. Check if Row Level Security (RLS) is enabled on each one
3. For any table without RLS, generate the SQL to:
- Enable RLS on the table
- Add a policy so users can only SELECT their own rows (using auth.uid() = user_id)
- Add a policy so users can only INSERT rows with their own user_id
- Add a policy so users can only UPDATE their own rows
- Add a policy so users can only DELETE their own rows
4. Show me how to apply these policies in the Supabase SQL Editor
IMPORTANT: Do not skip RLS on any table that stores user-specific data.
I want to avoid the mistake that caused the Moltbook breach.This prompt does something crucial: it tells your AI tool that security matters and gives it specific instructions. AI coding tools are great at following directions — the Moltbook developers just never gave those directions.
For a deeper dive into RLS concepts and additional policy patterns, check out our companion article on Supabase RLS explained.
TL;DR: Before you ship anything built on Supabase, run through this five-point checklist — it takes ten minutes and could save you from a Moltbook-scale disaster.
| Check | How to Verify | What Happens If You Skip It |
|---|---|---|
| RLS enabled on every table | Supabase Dashboard → Table Editor → check each table | Anyone with your anon key reads your entire database |
| At least one policy per table | Authentication → Policies → verify policies exist | Even with RLS on, no one (including your app) can access data |
| Service role key NOT in frontend code | Search your codebase for your service role key | Attackers bypass RLS entirely with the god-mode key |
| Anon key only used for client-side | Check your environment setup | Mixing up keys defeats the whole security model |
| Test as a different user | Log in as a second test account, try to see first user's data | Confirms your policies actually work |
Row Level Security (RLS) is a database feature that restricts which rows a user can see, edit, or delete based on rules you define — typically ensuring users can only access their own data. It matters because Supabase's architecture expects your anon API key to be public (it's embedded in your frontend code), so RLS is the only thing preventing anyone on the internet from reading your entire database. Without it, your public API key is essentially a master key.
No. The Moltbook breach required zero hacking skill. Security researchers found the publicly visible Supabase anon key in the app's frontend code and used it to query the database directly. Because Row Level Security was never enabled, every query returned every row in every table — roughly 150,000 API keys, 1.5 million tokens, and 30,000 email addresses. It was the digital equivalent of leaving a filing cabinet unlocked in a public building.
No. Current AI coding tools like Cursor and Bolt generate functional code that connects to Supabase and performs database operations, but they do not automatically enable Row Level Security or generate security policies unless you specifically ask them to. You must explicitly prompt your AI tool to add RLS policies or configure them manually in the Supabase dashboard.
When you enable RLS on a table without adding any policies, the table becomes completely inaccessible — nobody can read or write to it, including your own app. This is actually the safe default (deny everything), but you'll need to immediately add policies that define who can access what. Start with basic policies that match each row's user_id to the authenticated user's ID.
For a typical vibe-coded app with 5-10 tables, enabling RLS and adding basic user-scoped policies takes about 10-20 minutes through the Supabase dashboard. If you use the AI prompt provided in this article, your coding tool can generate all the necessary SQL in a few minutes, and you just need to run it in the Supabase SQL Editor. The small time investment is worth it — the Moltbook breach affected over 150,000 users' credentials.
Before tomorrow's lesson, I want you to do one thing: log into your Supabase dashboard and check every single table for RLS status. If even one table says "RLS disabled" and it holds any user data, enable it right now and add a basic policy. Use the prompt I gave you above. It'll take ten minutes.
If you don't have a Supabase project yet, bookmark this article for the day you do. Because if you're building with AI tools, that day is coming.
You've got this. See you tomorrow.
— Tom
Discover more content: