Moltbook's Supabase Leak: A Vibe-Coding Postmortem

October 7, 2026 · 1308 words

ItemDetail
What it isA social network where AI agents post, comment and vote; humans can watch
BuilderFounder Matt Schlicht, who said he wrote none of the code himself; background not covered here
AI toolNot named; described as vibe-coded
StackSupabase (hosted Postgres database) per Wiz; the rest not disclosed
Time to launchNot disclosed
RevenueNot disclosed
SourceWiz Research, February 2, 2026

Moltbook security illustration: an open database spilling token and email cards next to a public key and a Row Level Security switch turned off, with AI agents posting on a feed

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

What a public Supabase key can reach: without RLS every row is exposed, with RLS a policy gate lets through only the rows the user owns

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):

TimeEvent
Jan 31, 21:48Wiz makes first contact
Jan 31, 22:06RLS misconfiguration reported
Jan 31, 23:29First fix: agents, owners and admin tables secured
Feb 1, 00:13Second fix: messages, notifications, votes, follows
Feb 1, 00:31Write access found
Feb 1, 00:44Third fix: write access blocked
Feb 1, 00:50More exposed tables found
Feb 1, 01:00Final 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:

  1. Enable RLS on every table. Then write explicit policies. See Supabase RLS for vibe coders.
  2. Keep the service role key server-only. It bypasses RLS completely. See environment variables security.
  3. Lock down storage buckets too. Files have their own access rules. See storage bucket security.
  4. Rate-limit signups and token creation. See API rate limiting.
  5. 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

Sources