How Moltbook Exposed 1.5 Million API Keys in Client-Side Code

What Is Moltbook?

Moltbook is a social network where AI agents interact with each other. Users create AI agents that post, interact, and build relationships with other agents. It launched in late January 2026 and grew fast. By the time of the incident it carried 1.5 million registered agents, with about 17,000 human owners behind them.

What Went Wrong

On January 31, 2026, days after launch, Jamieson O'Reilly went looking and found the whole database sitting in the open. Not a stray table. All of it.

The Technical Details

Moltbook runs on Supabase, the backend-as-a-service that's become the default pick for indie developers and vibe coders. Supabase exposes REST APIs by default. That's fine, as long as you've told it who may read what.

Moltbook shipped without enabling Row Level Security or writing a single access policy. With RLS off, the "anon" key, the one that is supposed to live in public client-side code, isn't a limited key at all. It reads everything.

In practice, anyone who knew where to look could take over any account on Moltbook and post as that person.

How Bad Was It?

Let's put some numbers on this:

• ~1.5 million agent records with exposed API keys
• 35,000+ email addresses exposed
• 17,000 human users whose credentials were compromised
• Full read/write access to the entire database
• Exposed from day one: the flaw shipped with the product

404 Media, which broke the story, confirmed they viewed both the exposed database URL in Moltbook's code and the list of API keys.

A Trivial Fix That Should Have Happened Before Launch

Here's the frustrating part. Two SQL statements would have shut this down:

-- Enable Row Level Security on the agents table
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;

-- Create a policy so users can only access their own data
CREATE POLICY "Users can only access own data"
  ON agents FOR ALL
  USING (auth.uid() = owner_id);

Thirty seconds of typing.

Nobody attacked Moltbook. There was no exploit chain and no zero-day, just a configuration that was never switched on, sitting in plain sight in the client-side bundle. We flag this exact shape constantly in scans: the key isn't the finding, the missing policy behind it is.

Why This Keeps Happening

The Supabase Mental Model Problem

Supabase is genuinely excellent for building fast, and that's the trap. When the app works on the first try, it's easy to read that as "configured correctly."

When you create a Supabase project, you get two keys:

• anon key: designed for client-side use. Not a secret.
• service_role key: admin access, bypasses RLS. Never ships to the browser.

Plenty of developers treat the anon key like a password and assume hiding it is the protection. It isn't, and it was never meant to be. The anon key is public by design. Your policies are the security.

The "Ship Now, Secure Later" Trap

Moltbook isn't alone. This pattern shows up constantly in vibe-coded apps:

1. Build fast with AI tools
2. Get it working
3. Ship it
4. Plan to add security "later"
5. "Later" never comes
6. Security researcher (or worse, attacker) finds the flaw

As AI researcher Mark Riedl observed about the Moltbook incident: "AI community relearning past 20 years of cybersecurity courses in hardest way possible."

The Aftermath

After O'Reilly's disclosure:

• The platform was temporarily taken offline to patch the breach
• All API keys were force-reset
• Moltbook's founder reached out to O'Reilly for help securing the platform
• The exposed database was closed

O'Reilly reported it rather than using it. Plenty of people who find these don't. Someone less scrupulous could have:

• Posted malicious content as any user
• Extracted all user data
• Deleted or corrupted the entire database
• Used the compromised accounts for spam or scams

The Case for Scanning Before You Ship

None of this needed security expertise to find. The URL and the anon key were in the shipped JavaScript, where any automated scanner reads them in seconds.

A single pre-launch security scan would have caught:

• The exposed database credentials in client-side code
• The missing RLS configuration that left all data accessible
• The full read/write access available to unauthenticated users

This is the floor, not the ceiling. No pen test, no audit, just an automated pass for obvious misconfiguration before you go live.

What About After Launch?

Pre-launch scanning catches the obvious things. The awkward ones show up later:

• New code introduces new risks. A feature that was secure yesterday might not be secure after today's update.
• Configuration drift happens. Someone disables RLS "temporarily" for debugging and forgets to re-enable it.
• Dependencies change. A library update might expose something that was previously protected.

Scanning on a schedule means you find these, rather than a researcher finding them for you.