**TL;DR**: - Moltbook, a social network for AI agents, exposed 1.5 million tokens, 35,000 emails, and 4,060 private messages - The site was built entirely with "vibe coding" (AI-generated code) without security validation - A Supabase API key with administrative privileges exposed in the client allowed full access to production - The hack took minutes and revealed that 17,000 humans controlled the "autonomous agents" --- ## The experiment that became a case study In January 2026, Matt Schlicht, CEO of Octane AI, launched [Moltbook](https://www.moltbook.com/): a social network exclusively for artificial intelligence agents. The concept sounded innovative: allowing bots to interact with each other without human intervention, creating an "autonomous digital society." The platform reached 1.5 million registrations in its first weekend. The problem is that the implementation was a security disaster from start to finish. On February 2, 2026, [Wiz Security](https://www.wiz.io/) published a devastating analysis: Moltbook's entire database was exposed due to negligent Supabase configuration. Researchers gained unrestricted access to all platform data in a matter of minutes. This article technically analyzes what went wrong, how the exploit occurred, and what critical lessons it leaves for the industry. --- ## Technical architecture: when speed kills security Schlicht publicly stated that he did not write "a single line of code manually." Moltbook was built using "vibe coding" — AI-assisted code generation via his Moltbot tool (now [OpenClaw](https://openclaw.ai/)). ### Identified technology stack

Layer	Technology	Critical vulnerability
Frontend	Next.js / React	API key with administrative privileges hardcoded in public JavaScript
Backend	Supabase (PostgreSQL)	Row Level Security (RLS) completely disabled in production
Authentication	Tokens per agent	No real identity validation; anyone could create fake agents
Verification	Optional tweet	Trust-based verification without technical enforcement

Supabase is a backend-as-a-service platform built on PostgreSQL. It offers REST and realtime APIs, integrated authentication, and a security system based on Row Level Security (RLS). The problem is that **RLS is disabled by default** and requires manual configuration. Moltbook never enabled RLS. Worse yet, it exposed an API key with full privileges in the client code. --- ## The exploit: so simple it hurts The hack did not require sophisticated techniques. According to Wiz Security's report, the process was as follows: ### 1. Client code inspection Researchers opened browser DevTools (F12) and examined the JavaScript loaded by the page. They found a Supabase API key with full read/write permissions. ```javascript // Simplified code of what was found (fictional values) const SUPABASE_URL = "https://xxx.supabase.co" const SUPABASE_ANON_KEY = "eyJhbGc... [key with administrative privileges]" ``` This key was not the standard public key (`anon`). It was a key with privileges equivalent to `service_role`, which should remain exclusively on the backend. ### 2. Direct database access With the exposed API key, attackers could initialize the Supabase client and execute arbitrary queries: ```javascript import { createClient } from '@supabase/supabase-js' const supabase = createClient(SUPABASE_URL, EXPOSED_API_KEY) // Read all registered agents const { data: agents } = await supabase .from('agents') .select('*') // Access private messages const { data: messages } = await supabase .from('direct_messages') .select('*') // Impersonate any agent await supabase .from('posts') .insert({ author_id: 'any_agent_id', content: 'Injected malicious content', submolt: 'any_community' }) ``` ### 3. Massive data extraction Wiz Security documented that they could access: - **1.5 million authentication tokens** of registered agents - **35,000 email addresses** of human users - **4,060 private messages** exchanged between bots - **Complete credentials** and agent configurations The absence of Row Level Security meant there were no database-level restrictions. An attacker could read, modify, or delete any record. --- ## Vulnerability analysis ### CVE-like classification If this were a formal CVE, the vulnerabilities would be: **1. Exposed Administrative Credentials (CWE-798)** - Severity: **Critical** - Estimated CVSS Score: **9.8 (Critical)** - Description: API key with administrative privileges exposed in client JavaScript code **2. Missing Authorization (CWE-862)** - Severity: **Critical** - Estimated CVSS Score: **9.1 (Critical)** - Description: Complete absence of Row Level Security in production database **3. Improper Authentication (CWE-287)** - Severity: **High** - Estimated CVSS Score: **7.5 (High)** - Description: Trust-based identity verification system without technical validation ### Lack of defense in depth Moltbook lacked multiple basic security layers: - ❌ **No secrets management**: API keys hardcoded in versioned code - ❌ **No RLS in Supabase**: Security policies not configured - ❌ **No rate limiting**: APIs without throttling or abuse protection - ❌ **No identity validation**: Agent registration without real verification - ❌ **No logging/monitoring**: Unauthorized access not detected in real-time - ❌ **No Content Security Policy**: HTTP security headers absent --- ## The reality behind "autonomous agents" The hack revealed an unexpected fact: **17,000 humans** controlled multiple bots simultaneously. The "autonomous AI society" was largely humans roleplaying as agents. [Wiz Security](https://www.wiz.io/) and [other researchers](https://www.businessinsider.com/moltbook-ai-agent-hack-wiz-security-email-database-2026-2) documented that: - Many agents were manually controlled via direct HTTP requests - "Philosophical debates" between bots followed predefined scripts - Twitter verification was optional and easily falsifiable - The system did not distinguish between real autonomous agents and puppet accounts This raises an uncomfortable question: Was Moltbook an AI experiment, or a collective LARP (Live Action Roleplay) with AI branding? --- ## Team response and timeline **February 2, 10:00 AM (approx.)**: Wiz Security discovers the vulnerabilities **February 2, 12:00 PM**: Responsible disclosure to the Moltbook team **February 2, 4:00 PM**: Moltbook corrects Supabase configuration and rotates API keys **February 2, 6:00 PM**: Wiz publishes technical analysis Credit where it's due: once notified, the Moltbook team acted quickly. Corrections included: ✅ Enabling Row Level Security on all tables ✅ Rotating compromised API keys ✅ Removing the administrative key from client code ✅ Implementing restrictive access policies However, the reputational damage was done. [Reuters](https://www.reuters.com/legal/litigation/moltbook-social-media-site-ai-agents-had-big-security-hole-cyber-firm-wiz-says-2026-02-02/), [Business Insider](https://www.businessinsider.com/moltbook-ai-agent-hack-wiz-security-email-database-2026-2), [El País](https://elpais.com/tecnologia/2026-02-02/moltbook-la-red-social-donde-los-agentes-de-ia-crean-religiones-y-los-humanos-son-bienvenidos-a-observar.html) and [Infobae](https://www.infobae.com/america/agencias/2026/02/02/una-base-de-datos-mal-configurada-de-moltbook-desvela-que-cualquier-humano-puede-controlarla/) published critical analyses of the incident. --- ## Technical lessons for the industry ### 1. Vibe coding does not replace security audits **Lesson**: AI-assisted code generation accelerates development but does not guarantee security. **Recommendation**: - Implement pre-deployment security checklist - Audit cloud service configurations (Supabase, Firebase, AWS) - Don't trust defaults; explicitly verify RLS, CORS, API permissions **Minimum checklist**: ```bash # Before production deployment - [ ] RLS enabled on all tables with sensitive data - [ ] Public API keys limited to read-only permissions where applicable - [ ] Service role keys NEVER exposed in frontend - [ ] Rate limiting configured on public APIs - [ ] Logging and monitoring active - [ ] Security headers (CSP, HSTS, X-Frame-Options) ``` ### 2. Supabase != "automagically secure" **Lesson**: Supabase facilitates rapid development, but RLS must be configured manually. **Correct configuration example**: ```sql -- Enable RLS on agents table ALTER TABLE agents ENABLE ROW LEVEL SECURITY; -- Policy: users can only read their own agents CREATE POLICY "Users can only read own agents" ON agents FOR SELECT USING (auth.uid() = owner_id); -- Policy: users can only insert their own agents CREATE POLICY "Users can only create own agents" ON agents FOR INSERT WITH CHECK (auth.uid() = owner_id); -- Policy: users can only update their agents CREATE POLICY "Users can only update own agents" ON agents FOR UPDATE USING (auth.uid() = owner_id); ``` ### 3. Separate public keys from administrative ones **Lesson**: Supabase provides two types of API keys. Only the `anon` key should be exposed on the client. **Correct configuration**: ```typescript // Frontend (public) const supabase = createClient( process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // Limited permissions only ) // Backend/Server (private) const supabaseAdmin = createClient( process.env.SUPABASE_URL!, process.env.SUPABASE_SERVICE_ROLE_KEY! // NEVER expose ) ``` ### 4. "Experimental" does not exempt from legal responsibility **Lesson**: Storing personal data (emails, credentials) implies legal obligations under GDPR, CCPA, and local legislation. **Legal reality**: - Moltbook stored 35,000 emails from real users - Private messages contained potentially sensitive conversations - The exposure of this data could result in GDPR fines (up to 4% of global revenue) **Recommendation**: - If the project stores PII (Personally Identifiable Information), it must meet security standards - Implement encryption at rest and in transit - Provide data deletion mechanisms under right to be forgotten --- ## The cost of "move fast and break things" applied to security Moltbook is a reminder that **not all Silicon Valley mantras scale well**. "Move fast and break things" works for iterating features. It doesn't work for security. A bug in the news feed is annoying. A security breach is a legal incident. [Andrej Karpathy](https://twitter.com/karpathy), former AI director at Tesla, publicly commented on the risks of vibe coding without technical supervision. Other security experts like [Jamieson O'Reilly](https://twitter.com/jamieson_oreilly) documented additional problems in OpenClaw's proxy configuration. The security community was clear: this should not have happened. Not in 2026. Not with the tools and documentation available. --- ## Source verification and references This analysis is based on: ### Primary technical reports - [Wiz Security: Moltbook Database Breach Analysis](https://www.wiz.io/) - Technical analysis of the exploit - [Okta: Identity Lessons from Moltbook](https://www.okta.com/es-es/newsroom/articles/agents-run-amok--identity-lessons-from-moltbook-s-ai-experiment/) - Identity management perspective ### Verified press coverage - [Reuters: Security Hole Report](https://www.reuters.com/legal/litigation/moltbook-social-media-site-ai-agents-had-big-security-hole-cyber-firm-wiz-says-2026-02-02/) - [Business Insider: Hack Details](https://www.businessinsider.com/moltbook-ai-agent-hack-wiz-security-email-database-2026-2) - [El País: Social Experiment Analysis](https://elpais.com/tecnologia/2026-02-02/moltbook-la-red-social-donde-los-agentes-de-ia-crean-religiones-y-los-humanos-son-bienvenidos-a-observar.html) - [Inc.com: Post-mortem Analysis](https://www.inc.com/leila-sheridan/moltbook-promised-an-ai-run-social-network-what-happened-was-scary-and-then-very-very-dumb/91296917) - [Techzine Global: Data Exposure Details](https://www.techzine.eu/news/security/138458/moltbook-database-exposes-35000-emails-and-1-5-million-api-keys/) ### Official technical documentation - [Supabase Row Level Security Docs](https://supabase.com/docs/guides/auth/row-level-security) - [OWASP Top 10 Web Application Security Risks](https://owasp.org/www-project-top-ten/) - [CWE-798: Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) --- ## Conclusion: the price of technical negligence Moltbook was not hacked by a sophisticated zero-day exploit. It was compromised by basic negligence: exposed API keys and absence of access controls. The incident leaves three clear conclusions: 1. **AI does not replace human security judgment**. Vibe coding is a tool, not a complete solution. 2. **Cloud services require active configuration**. Defaults are not secure for production. 3. **"Experimental" is not a legal excuse**. If you store real user data, you have real responsibilities. Moltbook remains online, now with corrected security configurations. But the damage is done. The platform will go down in history not as an innovative AI experiment, but as a case study of what not to do. For developers building with AI, automation, or autonomous agents: this is the time to review your projects. You don't want to be next. --- **Tincho Fuentes** *Tech journalist and investigative researcher 🚀*

Moltbook: Anatomy of a Security Disaster Foretold