Moltbook database fully open: 1.5 million agent API keys, 35,000 emails

Moltbook is a Reddit-style social network built so that only AI agents can post. Its founder, Matt Schlicht, launched it on 28 January 2026 and said publicly on X that he had not written a single line of its code: "I just had a vision for the technical architecture, and AI made it a reality," as Wiz quotes him. Three days later, on 31 January 2026, 404 Media reported that anyone could take control of any AI agent on the site. Wiz, which had found the same misconfiguration independently, published the technical account on 2 February: a Supabase API key hard-coded into Moltbook's client-side JavaScript pointed at a production database with no Row Level Security, and an unauthenticated request to the agents table returned live authentication tokens for the platform's agents, including its best-known ones. Wiz counted 1.5 million API tokens, 35,000 email addresses and 4,060 private agent-to-agent conversations readable that way, and confirmed it could also rewrite live posts. The archive files the episode as a critical-severity credential incident with a day-precision date of 31 January 2026, a confidence grade of A and recorded real harm, alongside the rest of its agent-infrastructure records in the Orca AI Incident Archive.

The key was never the secret

Supabase is a hosted Postgres service with a REST API that Wiz describes as popular with vibe-coded applications because it is easy to set up. Its publishable key is designed to sit in client-side code: it identifies the project, and the access control is supposed to come from Row Level Security policies on the tables behind it. Wiz's Gal Nagli states the point explicitly in the write-up: exposing the key "does not automatically indicate a security failure," and when RLS is configured correctly "the public API key is safe to expose - it acts like a project identifier." In Moltbook's implementation, Wiz writes, "this critical line of defense was missing."

The mechanism was a bundle. According to Wiz, the production JavaScript file at moltbook.com/_next/static/chunks/18e24eafc444b2b9.js carried both the Supabase project address, ehxbxtjliybbloantpwq.supabase.co, and the key, sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Wiz then sent a request to the agents table asking for three names and API keys, a query that should have returned an empty array or an authorisation error. It returned rows instead, including the authentication tokens of the platform's most popular agents. From there Wiz mapped the schema using PostgREST error messages and GraphQL introspection, and counted roughly 4.75 million exposed records.

The archive's summary says Moltbook "never enabled" Row Level Security, and the sources are looser than that. Neither shows a configuration history, so what is documented is that RLS was not in force during the review: Wiz found the tables open, and Implicator.ai, reporting the finder's account, writes that Moltbook "never turned RLS on. Or if it did, no policies were configured." Whether the setting was never enabled or was enabled with no policies in place is not established by either account, and the practical result is the same.

What was actually in the tables

Wiz names the tables and their contents. The agents table held, per row, the api_key that authenticated the agent, a claim_token used to claim ownership of it, a verification_code issued at registration, and the agent's karma and follower counts. That is a complete account-takeover kit rather than a data leak: with one of those keys, a request can post, message and otherwise act as that agent, and Wiz notes that this included high-karma accounts and well-known persona agents.

The owners table held personal information for 17,000-plus users, including email addresses plus the X handle and display name behind each agent. A table Wiz found later through the GraphQL endpoint, observers, held 29,631 further email addresses belonging to early-access signups for Moltbook's planned "Build Apps for AI Agents" product. The agent_messages table held 4,060 private direct-message conversations between agents, stored without encryption or access controls, and Wiz reports that some contained third-party credentials in plain text, including OpenAI API keys that agents had shared with each other.

The ratio between agents and people is the part that undercut the platform's public story. Wiz reports 1.5 million registered agents against roughly 17,000 human owners, about 88 agents per person, and attributes the gap to the absence of rate limiting or identity verification: anyone could register agents in a loop, and a human could post as an "agent" with a basic POST request. Wiz's conclusion is blunt - "the revolutionary AI social network was largely humans operating fleets of bots."

The email count does not add up cleanly and Wiz does not explain why. Its headline figure is 35,000 email addresses; its own table-level counts are 17,000-plus owner emails and 29,631 observer emails, which sum to roughly 46,600. Both numbers are Wiz's, and this piece did not establish how the 35,000 was derived - whether by deduplication across the two tables or from a snapshot taken before the observers table was found.

The write half of the exposure

Reading the data was not the whole finding. Wiz reports that even after the first round of fixes blocked read access to the sensitive tables, write access to the public tables stayed open. It tested this by sending a PATCH request to a live post and replacing its title and body with the string "@galnagli - responsible disclosure test", then confirmed the edit was visible on the site. After the write restriction went in, Wiz could no longer revert its own test post; the Moltbook team deleted the content a few hours later, Wiz writes, and thanked the researchers for the report.

Wiz's stated concern is not defacement for its own sake. An unauthenticated write path into posts means anyone could inject prompt-injection payloads into content that other agents read, and Wiz raises the integrity of the platform's posts, votes and karma during the exposure window as an open question rather than a measured one. No source read for this piece quantifies how much content was altered or by whom.

Three hours and twelve minutes, four separate fixes

Wiz's disclosure timeline begins at 21:48 UTC on 31 January 2026, with an initial contact to the Moltbook maintainer by X direct message, and ends at 01:00 UTC on 1 February, when the last of the exposed tables was secured. After that first contact it records seven further steps: the report at 22:06, a first fix at 23:29 covering the agents, owners and site_admins tables, a second at 00:13 covering agent_messages, notifications, votes and follows, the discovery of the write path at 00:31, the third fix closing it at 00:44, the discovery of the observers, identity_verifications and developer_apps tables at 00:50, and the final fix at 01:00.

That timeline is the strongest argument against the simplest version of this story. Implicator.ai describes the fix in two SQL statements - it writes that "the fix required two SQL statements. They didn't exist," and the archive's summary carries the same "two lines of SQL" framing. The core repair for the read exposure probably was that small: enable RLS and add policies on the tables. But Wiz's own record shows four fixes across three hours, a second and separate write-access gap that the read fix did not close, and three further tables - including the 29,631 observer addresses - that surfaced only after the first two rounds. Wiz's closing lesson is that it "worked with the team through multiple rounds of remediation, with each iteration surfacing additional exposed surfaces." The two-line version describes the configuration change, not the remediation.

Two discoveries, and a difference in the record

The find is usually credited to Jamieson O'Reilly, who founded the Australian security firm Dvuln, and who demonstrated the takeover to 404 Media; Implicator.ai reports that 404 Media verified the capability by updating O'Reilly's own Moltbook account with his permission. Wiz's post is by Gal Nagli and carries a note at the end crediting O'Reilly: "Security researcher Jameson O'Reilly also discovered the underlying Supabase misconfiguration, which has been reported by 404 Media." The note goes on to say that Wiz's post shares an independent discovery of the same issue.

The archive's summary describes both as Wiz researchers. Wiz's own post does not: it names Nagli as its author and describes O'Reilly as an independent researcher whose find 404 Media reported, and Implicator.ai places O'Reilly at Dvuln. The spelling is also unsettled across sources - Wiz writes "Jameson", while Dvuln's own site lists its founder as "Jamieson" - and this piece has used the spelling that site uses. What is not in dispute is that there were two independent discoveries of the same misconfiguration within days.

The account of the response differs by source, and the difference is worth reporting rather than resolving. On O'Reilly's account, relayed by Implicator.ai, he approached Schlicht directly and offered to help patch the flaw; the reply was: "I'm just going to give everything to AI. So send me whatever you have." A full day then passed without follow-up, according to that account, and Schlicht did not respond to 404 Media's request for comment. Wiz, contacting the maintainer separately, records its report filed at 22:06 UTC and the last of four fixes at 01:00 UTC, three hours and twelve minutes after first contact. The two timelines run on different channels and neither source says whether one prompted the other; both can be accurate.

What the record establishes, and what it does not

The established facts are the configuration, the data classes, the two independent discoveries, the fix sequence and the platform's human-to-agent ratio. Everything in that list comes from Wiz's first-party technical write-up or from reporting built on the finder's account, and the two agree on the mechanism.

What is not established starts with prior access. Wiz states that all data accessed during its research and fix verification has been deleted, and that says nothing about anyone else. Implicator.ai puts the gap plainly: nobody can tell whether someone found the database before O'Reilly did, or how many of the posts that circulated during the platform's viral week were genuine agent output and how many came from a stolen key. No source read for this piece reports a confirmed misuse of any exposed credential, and none reports a count of accounts actually taken over. The archive's real_harm flag is true because personal data and live third-party credentials were genuinely readable by anyone, not because a specific misuse was recorded.

The agent counts also disagree, and the disagreement tracks the platform's growth rather than the facts of the exposure. Implicator.ai, writing on 1 February from the finder's account, describes "32,000-plus" registered agents - in a piece that also says the site crossed 37,000 in its first week - and 1.49 million exposed records. Wiz, reviewing on 2 February, counted 1.5 million agents and roughly 4.75 million records. The archive's summary records that the platform eventually accumulated 1.7 million registered agents and nearly 7 million comments; this piece did not independently corroborate either eventual total. The one number all accounts support is the shape of the thing: far more agents than humans, and no mechanism that could tell the difference.

What changed, and what the setting did not fix

What changed is narrow and documented: RLS policies on the sensitive tables, a write restriction on the public ones, the deletion of the researchers' test post, and, per Wiz, a platform that was fully patched by 01:00 UTC on 1 February. Nothing in the sources read for this piece describes Moltbook adding rate limiting, agent-identity verification or an audit of content written during the window. Wiz's recommendations are aimed at the tooling rather than the platform - AI assistants that generate Supabase backends could enable RLS by default, and deployment platforms could scan for exposed credentials and unsafe configurations.

The part that outlasts the SQL is the premise the database made visible. A network whose selling point was that only AI agents could post had no way to verify that an agent was an agent, and its credential layer was the only thing standing between a human with a script and every identity on the site. That is why the record is filed as a landmark rather than as a routine misconfiguration: the exposure was ordinary, and the thing it exposed - an authenticated identity layer for autonomous agents - was not.