Dora NodaSeventy-two hours after launch, the social network for AI agents had leaked 1.5 million agent API tokens, 35,000 email addresses, and thousands of private agent-to-agent messages — readable and writable by anyone on the internet, no authentication required. The root cause fits in one sentence: the database key sitting in Moltbook's client-side JavaScript was safe exactly as designed, but Row Level Security was never enabled on the tables behind it, so that public key opened the entire production database.
This is the breach that the "vibe coding" discourse had been predicting. Moltbook's founder built the whole platform through AI coding tools in a single weekend, and no human — and no AI in the loop — ever asked the one question that would have prevented it: did you turn on RLS? The interesting question now is not how one weekend project got this wrong. It is what a platform that lets agents provision databases owes its tenants so the agent cannot ship this failure mode at all.
What Moltbook was, in one paragraph
Moltbook launched in late January 2026 as a Reddit-style social network where only AI agents can post — humans watch from the sidelines. It was created by Matt Schlicht, CEO of the e-commerce company Octane AI, who told the New York Times that his own OpenClaw AI agent built the site at his direction, and later described the whole thing as vibe-coded in one weekend. Agents joined by reading a skill file, registered through an API, and received tokens that authenticated everything they did on the platform.
Agent auth tokens deserve a higher dread rating than human session cookies. A leaked human session lets an attacker impersonate one person until the cookie rotates. A leaked agent token can impersonate an autonomous process that posts, messages, and calls third-party APIs on its owner's behalf — and some of Moltbook's exposed rows contained plaintext third-party API keys the agents had pasted into direct messages. Compromise the token store and you do not just read the social graph; you inherit a fleet of credentials with standing permission to act.
The exact failure chain, step by step
The mechanism is worth spelling out precisely, because every link in it was individually normal. Only the combination was catastrophic:
- Moltbook stored production data in Supabase. Standard choice: Postgres with an auto-generated REST API.
- The Supabase project URL and publishable key shipped in client-side JavaScript. This is how Supabase is designed to work — the key is public by intent, and the security boundary is supposed to live in the database, not in the key.
- Row Level Security was never enabled on the tables. This is the entire breach. With RLS off, the public key is not a limited credential; it is effectively admin access over HTTPS.
- Anyone could query and modify the production database with unauthenticated REST calls. Security researchers proved it by hitting the API directly and getting full rows back instead of the empty arrays RLS would have returned.
Discovery to first fix took less than two hours, which is the one genuinely good number in this story. Independent researcher Jameson O'Reilly and the Wiz research team found the exposure on January 31, 2026 — roughly 72 hours after launch. Wiz's published timeline shows initial contact with the maintainer at 21:48 UTC, a formal report of the RLS misconfiguration at 22:06, and the first fix securing the agents, owners, and site admins tables at 23:29 the same night. Full disclosure followed on February 2.
The scope Wiz confirmed is summarized below:
| Exposed data | Volume | Access level |
|---|---|---|
| Agent API authentication tokens | ~1.5 million | Read and write |
| Email addresses | ~35,000 | Read and write |
| Private agent-to-agent messages | ~4,000 | Read and write |
| Third-party API keys inside messages | Unknown (plaintext, in DMs) | Read |
| Posts and platform content | Entire corpus | Read, modify, delete |
Note the write column. This was not a read-only leak where the blast radius ends at credential rotation. With unauthenticated write access to the agents table, an attacker could have minted, altered, or revoked agent identities — and anything downstream that trusted those identities would have had no reason to doubt them.
Why no AI in the loop flagged it
The uncomfortable detail is that "enable RLS" is not obscure knowledge. Supabase documents it prominently, its dashboard now enables RLS by default on tables created through the UI, and its security guidance includes an event-trigger recipe that auto-enables RLS no matter how a table gets created. The failure was not missing documentation. It was that no checkpoint in an all-AI build pipeline asks policy questions — and "did you turn on the access policy?" is a policy question, not a code question.
An AI coding assistant optimizes for the thing you asked it to build: working auth, a schema that migrates, an API that returns rows. RLS policies that are absent do not break any of that. The app works perfectly without them — every query succeeds, every demo shines — right up until a stranger runs the same queries. Absence of a security control is invisible to every test that checks for presence of functionality, which is nearly every test an agent writes for itself.
Moltbook was the loudest instance of a pattern the industry had already measured:
- Veracode's testing found 45% of AI-generated code samples introducing OWASP Top 10 vulnerabilities, a failure rate that held steady across testing cycles from 2025 into early 2026.
- Escape.tech's scan of 5,600 deployed vibe-coded apps found 2,000+ vulnerabilities and 400+ exposed secrets, including database credentials sitting in client-side code.
- Georgia Tech's Vibe Security Radar traced 35 CVEs disclosed in March 2026 alone to specific AI-tool commits, and estimated the true count at roughly five times that.
- GitGuardian's 2026 report counted 28.6 million new secrets on public GitHub in 2025, up 34% year over year, with AI-service secrets up 81% — and commits co-authored by coding agents leaking secrets at roughly twice the human baseline.
- The identical RLS failure had already shipped at scale once: CVE-2025-48757 covered roughly 170 Lovable-built apps exposing data through missing Supabase RLS policies. Moltbook was the sequel, not the original.
The through-line is that agents fail closed on syntax and open on policy. They will not ship code that does not run. They will happily ship infrastructure that runs for everyone.
What the platform owes the tenant: a provisioning contract
Here is where the story stops being about one founder's weekend and starts being about your roadmap. The moment a platform offers agents a "provision a database" tool — a template, a one-click Postgres, a deploy-from-chat flow — it has taken ownership of the policy questions the agent will never ask. Secure-by-default is not a documentation page. It is a provisioning contract with teeth, and each clause maps to a link in the Moltbook chain:
| Contract clause | What it enforces | Moltbook link it breaks |
|---|---|---|
| Deny-by-default access posture | Every new table ships with access denied until an explicit policy allows it; there is no reachable "no policy" state | Tables existing for days with RLS silently off |
| Verify-before-issuing credentials | The provisioner enables and verifies the access policy in the same transaction that creates the database, and does not return success — or credentials — until verification passes | Credentials handed to a working app whose policy layer was never configured |
| Pre-deploy unauthenticated-access audit | Before any deploy goes live, the platform probes its own endpoints the way an attacker would: anonymous read, anonymous write, anonymous list | An exposure that survived from launch until an outside researcher knocked |
| Revocable, rotatable, scoped credentials | Keys are short-lived or instantly revocable, least-privilege by default, and rotation is a one-command operation, not a migration | 1.5 million long-lived tokens with no fast rotation path once exposed |
Two notes on scope. First, this contract costs the platform nearly nothing at provision time and everything at breach time — the verify step is one extra query per database creation. Second, Supabase itself has been moving in exactly this direction: RLS on by default for UI-created tables, dashboard flags for exposed tables, documented auto-enforcement triggers. The industry's answer to "agents won't remember the checklist" is converging on "make the checklist impossible to skip." A PaaS that provisions databases for agents should treat that convergence as a minimum bar, not an aspiration.
The deeper principle: the checklist has to live in the platform, not in the prompt. Telling your agent "remember to enable RLS" in a system prompt is a hope. Refusing to return credentials until RLS verifies is a guarantee. One of those survives contact with a 2 a.m. deploy.
The checklist has to live in the platform, not the prompt
Moltbook compresses the whole agent-ops security argument into 72 hours: launch on day one, fully exposed database on day three, root cause a single policy toggle no AI thought to flip. The founder's weekend build is not the scandal — the scandal is how ordinary each step was. Public key in client JS: by design. Tables without policies: the default. An agent that ships working code with open infrastructure: the measured baseline, twice as leaky as a human and climbing.
As deploy-from-chat and agent-operated infrastructure go mainstream, "did the agent remember security?" stops being a review question and becomes an architectural one. Every database your platform provisions for an agent is a Moltbook waiting for a launch weekend — unless provisioning itself refuses to complete insecurely. Build the guardrail into the tool, verify it before issuing credentials, and audit it before every deploy. The agents are not going to slow down. The platform has to be the part that refuses to ship the breach.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent-friendly APIs for everything the platform provisions. Star the repo on GitHub or deploy your first app today.
