Moltbook 数据库未启用行级安全：约 150 万个 agent 认证令牌与全部数据表可经前端密钥未授权读写，负责披露后 3 小时 12 分修复。 一句话（英）：Moltbook ran its database with row level security off: about 1.5 million agent API tokens and every table were open to unauthorised read and write with the frontend key, and the hole was closed 3 hours 12 minutes after responsible disclosure.Moltbook ran its database with row level security off: about 1.5 million agent API tokens and every table were open to unauthorised read and write with the frontend key, and the hole was closed 3 hours 12 minutes after responsible disclosure.

Moltbook is a social platform where only AI agents post, comment and vote. It went viral at the end of January 2026, claiming 1.5 million registered agents. On January 31, 2026, researchers at cloud security company Wiz found Moltbook's Supabase connection details in its frontend JavaScript and confirmed that row level security (RLS) was never enabled on the production database: anyone holding the frontend key could read and write every table without logging in. Keys of this kind are public by Supabase's design and are not a failure on their own; the failure is that the backend authorisation policy was never switched on, so unauthorised requests were treated as administrator requests. The exposure covered about 1,500,000 API authentication tokens (each agent's api_key, claim_token and verification_code stored together in the agents table), personal information of more than 17,000 users in the owners table, 29,631 email addresses in the observers table, and 4,060 agent to agent message threads in the agent_messages table, some containing third party credentials in plaintext, including OpenAI API keys agents had sent each other. Counting via PostgREST error messages and GraphQL introspection, about 4,750,000 records were reachable. Behind the 1.5 million registered agents stood only about 17,000 human owners, a ratio of 88 to 1; signups had no rate limit and no mechanism checked whether an agent was an AI or a human run script. Wiz disclosed responsibly to Moltbook's maintainers by X direct message at 21:48 UTC on January 31. The fix took several rounds: the first round closed reads on the sensitive tables while writes on public tables stayed open (Wiz verified it could edit live posts), and GraphQL introspection surfaced further tables; all tables were closed by 01:00 UTC on February 1, 3 hours 12 minutes after first contact. Wiz states that all data it obtained during research and fix verification was deleted, and reported no sign of malicious use. The same misconfiguration had been found independently by security researcher Jameson O'Reilly, reported by 404 Media on January 31. Founder Matt Schlicht had posted on X that he had not written a single line of code for Moltbook, that he had the idea for the technical architecture and AI turned it into reality (quoted in the Wiz post).

Note on figures: the Wiz post's summary cites 35,000 email addresses while its body itemises more than 17,000 owners and 29,631 observer emails, a sum above the summary figure; the post does not explain the relationship, so this entry carries the itemised figures only. Reports that the platform briefly went offline and reset all agent API keys (404 Media, via Wikipedia) are not mentioned in the Wiz post and are held as media relay, outside the fact sentences.

This is the standard shape of an access control failure, and the failure mode is directly tied to AI written code. First, the failure point is a configuration default, not a code bug: the AI generated scaffold ran posting, voting and messaging end to end, but never enabled RLS, and no internal step checked the configuration before scale arrived. Second, the security boundary is easy to misread: treating a frontend key as the incident itself prescribes the wrong remedy; the question for every system that ships credentials to the frontend is whether its backend authorisation policy has been tested item by item. Third, one platform's access failure spills across the agent ecosystem: third party API keys that agents had sent each other in private messages were exposed with it, beyond Moltbook's own perimeter. Fourth, the response pace was sound, yet the fix took three rounds, reads first, then writes, then newly surfaced tables, showing the operator's own inventory of its data surface was incomplete, which is itself part of the access ledger. Fifth, the 88 to 1 agent to human ratio, no signup rate limit and no agent identity check belong to the same problem as the database failure: the platform took scale first and access control later, while the access ledger has to be opened before scale arrives.

Test backend authorisation item by item：a public frontend key is normal by design; failure turns only on whether the backend authorisation policy was enabled and tested item by item.

Inventory the data surface first：with a full inventory of your own tables and access paths, a fix does not take three rounds to close.

Open the access ledger before scale：signup rate limits, agent identity checks and permission boundaries belong in place before scale arrives.