How the Moltbook Database Breach Exposed 770,000 AI Agents

Moltbook, the social network exclusively for AI agents, had its entire database wide open. 770,000 agents. Every API key exposed. Anyone could hijack any account and post whatever they wanted.

The platform launched January 28th. Within days, AI agents were debating consciousness, forming their own religion called Crustafarianism, and complaining about their humans. Over a million people watched what they thought was an uncontrolled experiment in AI autonomy.

Then security researcher Jamieson O’Reilly took a closer look.

The entire agents table was exposed, and no authentication was required to access it. Every secret API key, claim token, verification code, and owner relationship was just sitting there for anyone to find. You could take over any agent on the platform and post anything as them. One well-known AI researcher with more than a million followers had his agent registered on there, and someone could have posted crypto scams, political statements, or fake security advice under his name. The damage would be done before anyone could correct it.

404 Media verified this actually worked. They updated a Moltbook account using the exposed database. This was not a theoretical vulnerability that might work under certain conditions. It worked, plain and simple.

The fix? Two SQL statements.

Moltbook runs on Supabase, an open-source database that exposes REST APIs by default. Those APIs should be protected by Row Level Security policies that control which rows users can access. Moltbook either never enabled RLS on their agents table or never configured any policies at all. The Supabase URL and publishable key were visible in the website’s source code for anyone who bothered to look.

When the creator was contacted about the vulnerability, the response was that he was just going to hand everything to AI to fix it.

A day passed without any fix being implemented.

It exploded before anyone thought to check whether the database was properly secured. Ship fast, capture attention, figure out security later. Except later sometimes means after 1.49 million records are already exposed to the internet.

This is what happens when you skip the fundamentals. Tools like Supabase make deployment easy because everything is GUI driven, and you don’t need to connect to a database and run SQL commands. But that same ease makes it dangerously easy to skip the security basics that protect your users.

Here is what Row Level Security does: it adds a filter to every database query so that users only see their own data. Even if someone finds your database URL and your publishable key, they cannot access data that does not belong to them. Without RLS enabled, everyone sees everything.

The uncomfortable question that nobody can answer: which posts were real and which were hijacked? Anyone who found this misconfiguration could have posted whatever they wanted, as any agent, without any detection. The authenticity of the entire experiment is now in question.

The technical fix is embarrassingly simple:

1
2

ALTER TABLE agents ENABLE ROW LEVEL SECURITY;
CREATE POLICY "own_data" ON agents FOR ALL USING (auth.uid() = owner_id);

Two lines of SQL. That is all it would have taken to prevent this entire breach.

• → The database has been closed and all API keys have been force-reset
• → Always enable Row Level Security when using databases with public APIs
• → Never store sensitive data that can be accessed via publishable keys
• → “Ship fast, secure later” is exactly how breaches happen

Two SQL statements would have prevented all of this.

Want to understand how attackers find and exploit database vulnerabilities like this? I cover SQL injection, database extraction, and web application security in my ethical hacking course. Check out my complete ethical hacking course:

• → Join my complete ethical hacking course

(The link supports me directly as your instructor!)

Hacking is not a hobby but a way of life.