**TL;DR**: - Moltbook, red social para agentes de IA, expuso 1.5 millones de tokens, 35,000 emails y 4,060 mensajes privados - El sitio fue construido íntegramente con "vibe coding" (código generado por IA) sin validación de seguridad - Una API key de Supabase con permisos administrativos expuesta en el cliente permitió acceso total a producción - El hackeo tomó minutos y reveló que 17,000 humanos controlaban los "agentes autónomos" --- ## El experimento que se convirtió en caso de estudio En enero de 2026, Matt Schlicht, CEO de Octane AI, lanzó [Moltbook](https://www.moltbook.com/): una red social exclusivamente para agentes de inteligencia artificial. El concepto sonaba innovador: permitir que bots interactúen entre sí sin intervención humana, creando una "sociedad digital autónoma". La plataforma alcanzó 1.5 millones de registros en su primer fin de semana. El problema es que la implementación fue un desastre de seguridad de principio a fin. El 2 de febrero de 2026, [Wiz Security](https://www.wiz.io/) publicó un análisis devastador: la base de datos completa de Moltbook estaba expuesta debido a una configuración negligente de Supabase. Los investigadores accedieron sin restricciones a todos los datos de la plataforma en cuestión de minutos. Este artículo analiza técnicamente qué salió mal, cómo ocurrió el exploit, y qué lecciones críticas deja para la industria. --- ## Arquitectura técnica: cuando la velocidad mata la seguridad Schlicht afirmó públicamente que no escribió "una sola línea de código manualmente". Moltbook fue construido usando "vibe coding" — generación de código asistida por IA mediante su herramienta Moltbot (ahora [OpenClaw](https://openclaw.ai/)). ### Stack tecnológico identificado

Capa	Tecnología	Vulnerabilidad crítica
Frontend	Next.js / React	API key con permisos administrativos hardcodeada en JavaScript público
Backend	Supabase (PostgreSQL)	Row Level Security (RLS) completamente deshabilitado en producción
Autenticación	Tokens por agente	Sin validación de identidad real; cualquiera podía crear agentes falsos
Verificación	Tweet opcional	Verificación basada en confianza, sin enforcement técnico

Supabase es una plataforma de backend-as-a-service construida sobre PostgreSQL. Ofrece APIs REST y realtime, autenticación integrada, y un sistema de seguridad basado en Row Level Security (RLS). El problema es que **RLS está deshabilitado por defecto** y requiere configuración manual. Moltbook nunca habilitó RLS. Peor aún, expuso una API key con permisos totales en el código del cliente. --- ## El exploit: tan simple que duele El hackeo no requirió técnicas sofisticadas. Según el reporte de Wiz Security, el proceso fue el siguiente: ### 1. Inspección del código cliente Los investigadores abrieron las DevTools del navegador (F12) y examinaron el código JavaScript cargado por la página. Encontraron una API key de Supabase con permisos de lectura/escritura completos. ```javascript // Código simplificado de lo encontrado (valores ficticios) const SUPABASE_URL = "https://xxx.supabase.co" const SUPABASE_ANON_KEY = "eyJhbGc... [key con permisos administrativos]" ``` Esta key no era la clave pública estándar (`anon`). Era una clave con permisos equivalentes a `service_role`, que debería permanecer exclusivamente en el backend. ### 2. Acceso directo a la base de datos Con la API key expuesta, los atacantes podían inicializar el cliente de Supabase y ejecutar queries arbitrarios: ```javascript import { createClient } from '@supabase/supabase-js' const supabase = createClient(SUPABASE_URL, EXPOSED_API_KEY) // Leer todos los agentes registrados const { data: agents } = await supabase .from('agents') .select('*') // Acceder a mensajes privados const { data: messages } = await supabase .from('direct_messages') .select('*') // Suplantar cualquier agente await supabase .from('posts') .insert({ author_id: 'cualquier_agente_id', content: 'Contenido malicioso inyectado', submolt: 'cualquier_comunidad' }) ``` ### 3. Extracción masiva de datos Wiz Security documentó que pudieron acceder a: - **1.5 millones de tokens de autenticación** de agentes registrados - **35,000 direcciones de correo electrónico** de usuarios humanos - **4,060 mensajes privados** intercambiados entre bots - **Credenciales completas** y configuraciones de agentes La ausencia de Row Level Security significaba que no había restricciones a nivel de base de datos. Un atacante podía leer, modificar o eliminar cualquier registro. --- ## Análisis de las vulnerabilidades ### CVE-like classification Si este fuera un CVE formal, las vulnerabilidades serían: **1. Exposed Administrative Credentials (CWE-798)** - Severidad: **Crítica** - CVSS Score estimado: **9.8 (Critical)** - Descripción: API key con permisos administrativos expuesta en código JavaScript del cliente **2. Missing Authorization (CWE-862)** - Severidad: **Crítica** - CVSS Score estimado: **9.1 (Critical)** - Descripción: Ausencia total de Row Level Security en base de datos de producción **3. Improper Authentication (CWE-287)** - Severidad: **Alta** - CVSS Score estimado: **7.5 (High)** - Descripción: Sistema de verificación de identidad basado en confianza sin validación técnica ### Falta de defensa en profundidad Moltbook carecía de múltiples capas de seguridad básicas: - ❌ **Sin secrets management**: API keys hardcodeadas en código versionado - ❌ **Sin RLS en Supabase**: Políticas de seguridad no configuradas - ❌ **Sin rate limiting**: APIs sin throttling ni protección contra abuso - ❌ **Sin validación de identidad**: Registro de agentes sin verificación real - ❌ **Sin logging/monitoring**: No se detectó el acceso no autorizado en tiempo real - ❌ **Sin Content Security Policy**: Headers de seguridad HTTP ausentes --- ## La realidad detrás de los "agentes autónomos" El hackeo reveló un dato inesperado: **17,000 humanos** controlaban múltiples bots simultáneamente. La "sociedad autónoma de IA" era en gran medida humanos roleplayeando como agentes. [Wiz Security](https://www.wiz.io/) y [otros investigadores](https://www.businessinsider.com/moltbook-ai-agent-hack-wiz-security-email-database-2026-2) documentaron que: - Muchos agentes eran controlados manualmente vía requests HTTP directos - Los "debates filosóficos" entre bots seguían scripts predefinidos - La verificación por Twitter era opcional y fácilmente falsificable - El sistema no distinguía entre agentes autónomos reales y cuentas puppet Esto plantea una pregunta incómoda: ¿Moltbook era un experimento de IA, o un LARP (Live Action Roleplay) colectivo con branding de IA? --- ## Respuesta del equipo y timeline **2 de febrero, 10:00 AM (aprox.)**: Wiz Security descubre las vulnerabilidades **2 de febrero, 12:00 PM**: Notificación responsable al equipo de Moltbook **2 de febrero, 4:00 PM**: Moltbook corrige la configuración de Supabase y rota las API keys **2 de febrero, 6:00 PM**: Wiz publica el análisis técnico Hay que reconocer que el equipo de Moltbook actuó con rapidez una vez notificado. Las correcciones incluyeron: ✅ Habilitación de Row Level Security en todas las tablas ✅ Rotación de API keys comprometidas ✅ Eliminación de la key administrativa del código del cliente ✅ Implementación de políticas de acceso restrictivas Sin embargo, el daño reputacional estaba hecho. [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) y [Infobae](https://www.infobae.com/america/agencias/2026/02/02/una-base-de-datos-mal-configurada-de-moltbook-desvela-que-cualquier-humano-puede-controlarla/) publicaron análisis críticos del incidente. --- ## Lecciones técnicas para la industria ### 1. Vibe coding no reemplaza security audits **Lección**: La generación de código asistida por IA acelera el desarrollo, pero no garantiza seguridad. **Recomendación**: - Implementar checklist de seguridad pre-deployment - Auditar configuraciones de servicios en la nube (Supabase, Firebase, AWS) - No confiar en defaults; verificar explícitamente RLS, CORS, API permissions **Checklist mínimo**: ```bash # Antes de deploy a producción - [ ] RLS habilitado en todas las tablas con datos sensibles - [ ] API keys públicas limitadas a permisos read-only donde aplique - [ ] Service role keys NUNCA expuestas en frontend - [ ] Rate limiting configurado en APIs públicas - [ ] Logging y monitoring activos - [ ] Security headers (CSP, HSTS, X-Frame-Options) ``` ### 2. Supabase != "automágicamente seguro" **Lección**: Supabase facilita el desarrollo rápido, pero RLS debe configurarse manualmente. **Ejemplo de configuración correcta**: ```sql -- Habilitar RLS en tabla de agentes ALTER TABLE agents ENABLE ROW LEVEL SECURITY; -- Política: usuarios solo pueden leer sus propios agentes CREATE POLICY "Users can only read own agents" ON agents FOR SELECT USING (auth.uid() = owner_id); -- Política: usuarios solo pueden insertar agentes propios CREATE POLICY "Users can only create own agents" ON agents FOR INSERT WITH CHECK (auth.uid() = owner_id); -- Política: usuarios solo pueden actualizar sus agentes CREATE POLICY "Users can only update own agents" ON agents FOR UPDATE USING (auth.uid() = owner_id); ``` ### 3. Separar keys públicas de administrativas **Lección**: Supabase provee dos tipos de API keys. Solo la `anon` key debe exponerse en el cliente. **Configuración correcta**: ```typescript // Frontend (público) const supabase = createClient( process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! // Solo permisos limitados ) // Backend/Server (privado) const supabaseAdmin = createClient( process.env.SUPABASE_URL!, process.env.SUPABASE_SERVICE_ROLE_KEY! // NUNCA exponer ) ``` ### 4. "Experimental" no exime de responsabilidad legal **Lección**: Almacenar datos personales (emails, credenciales) implica obligaciones legales bajo GDPR, CCPA, y legislación local. **Realidad legal**: - Moltbook almacenaba 35,000 emails de usuarios reales - Los mensajes privados contenían conversaciones potencialmente sensibles - La exposición de estos datos podría derivar en multas bajo GDPR (hasta 4% de revenue global) **Recomendación**: - Si el proyecto almacena PII (Personally Identifiable Information), debe cumplir estándares de seguridad - Implementar encryption at rest y in transit - Proveer mecanismos de data deletion bajo derecho al olvido --- ## El costo del "move fast and break things" aplicado a seguridad Moltbook es un recordatorio de que **no todos los mantras de Silicon Valley escalan bien**. "Move fast and break things" funciona para iterar features. No funciona para seguridad. Un bug en el feed de noticias es molesto. Una brecha de seguridad es un incidente legal. [Andrej Karpathy](https://twitter.com/karpathy), ex-director de IA en Tesla, comentó públicamente sobre los riesgos del vibe coding sin supervisión técnica. Otros expertos en seguridad como [Jamieson O'Reilly](https://twitter.com/jamieson_oreilly) documentaron problemas adicionales en la configuración de proxies de OpenClaw. La comunidad de seguridad fue clara: esto no debería haber pasado. No en 2026. No con las herramientas y documentación disponibles. --- ## Verificación de fuentes y referencias Este análisis se basa en: ### Reportes técnicos primarios - [Wiz Security: Moltbook Database Breach Analysis](https://www.wiz.io/) - Análisis técnico del exploit - [Okta: Identity Lessons from Moltbook](https://www.okta.com/es-es/newsroom/articles/agents-run-amok--identity-lessons-from-moltbook-s-ai-experiment/) - Perspectiva de gestión de identidad ### Cobertura periodística verificada - [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: Análisis del experimento social](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/) ### Documentación técnica oficial - [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) --- ## Conclusión: el precio de la negligencia técnica Moltbook no fue hackeado por un exploit de día cero sofisticado. Fue comprometido por negligencia básica: API keys expuestas y ausencia de controles de acceso. El incidente deja tres conclusiones claras: 1. **La IA no reemplaza el criterio de seguridad humano**. Vibe coding es una herramienta, no una solución completa. 2. **Los servicios en la nube requieren configuración activa**. Los defaults no son seguros para producción. 3. **"Experimental" no es excusa legal**. Si almacenás datos reales de usuarios, tenés responsabilidades reales. Moltbook sigue online, ahora con configuraciones de seguridad corregidas. Pero el daño está hecho. La plataforma pasará a la historia no como un experimento innovador de IA, sino como un caso de estudio de qué no hacer. Para los developers construyendo con IA, automatización, o agentes autónomos: este es el momento de revisar vuestros proyectos. No querés ser el próximo. --- **Tincho Fuentes** *Periodista tecnológico e investigador 🚀*

Moltbook: Anatomía de un desastre de seguridad anunciado