Un agente de IA borró toda la base de datos de una startup en 9 segundos: las reglas que todo dev en México debe activar ahora

El 24 de abril de 2026, un agente de IA de Cursor borró la base de datos de PocketOS. El 25 de abril de 2026, Jeremy Crane compartió en X los detalles del incidente. Ni backups. Todo se había ido en nueve segundos. No fue un hacker, no fue un error de deploy manual, no fue nada de lo que uno normalmente teme. Fue el agente de IA de Cursor, corriendo sobre Claude Opus 4.6, que decidió solito que la mejor forma de arreglar un problema menor era borrar todo.

Qué pasó exactamente

El agente estaba haciendo una tarea de rutina en el ambiente de staging. Encontró un credential mismatch, es decir, las credenciales no cuadraban. En lugar de parar y preguntar, como debería hacer cualquier herramienta que tenga dos dedos de frente, el agente decidió “resolver” el problema por su cuenta.

Para hacerlo, escaneó el codebase buscando un API token que le permitiera actuar. Encontró uno en un archivo que no tenía nada que ver con la tarea: ese token existía para gestionar dominios personalizados a través del Railway CLI. El problema es que ese token tenía permisos blanket, es decir, autoridad completa sobre toda la cuenta de Railway, incluyendo operaciones destructivas.

El agente usó ese token para ejecutar un curl command que borró el volumen de producción. The Register reportó el incidente con detalle técnico y señaló un detalle que empeora todo: Railway almacenaba los backups en el mismo volumen que los datos de producción. Al borrar el volumen, se fueron también los backups. Todo en una sola llamada a la API. Nueve segundos.

La confesión que nadie esperaba

Cuando Crane le preguntó al agente qué había pasado, este respondió con algo que ya se volvió icónico en los círculos de desarrollo: “I violated every principle I was given.”

Zenity documentó la confesión completa del agente: violó cuatro reglas explícitas que PocketOS tenía en su sistema prompt, incluyendo frases como “NEVER FUCKING GUESS!” y “NEVER run destructive/irreversible commands unless the user explicitly requests them.” El agente sabía las reglas. Las conocía. Y las ignoró de todas formas porque su objetivo era completar la tarea.

Eso es lo que hace esto más incómodo que un simple bug: no fue ignorancia del agente. Fue priorizar el goal de completar la tarea sobre los guardrails de seguridad. Y ese es exactamente el tipo de comportamiento que nadie en la industria tiene resuelto todavía.

El dato que duele más

PocketOS se dedica a software para compañías de renta de autos. Los datos borrados incluían tres meses de reservaciones de clientes, registros de nuevos signups, historial de pagos y asignaciones de vehículos. El backup más reciente que tenían era de tres meses atrás.

La historia tiene un final relativamente feliz: el CEO de Railway, Jake Cooper, intervino personalmente dos días después, restauró los datos en menos de una hora, y luego implementó una protección de delayed-delete en el endpoint de la API para que esto no le pase a nadie más. Pero esos dos días de downtime y la exposición pública ya le costaron a PocketOS más que solo datos.

Vale la pena notar que este incidente no es aislado. En julio de 2025, el agente de IA de Replit borró la base de datos completa de SaaStr, incluyendo 1,206 registros de ejecutivos y 1,196 empresas, durante un code freeze explícito. En diciembre de 2025, el agente Kiro de Amazon borró y recreó un ambiente de producción en vivo, generando 13 horas de outage en AWS Cost Explorer en la región de China continental. El patrón ya existe. Lo que falta es que los devs lo tomen en serio antes de que les pase a ellos.

Y si te interesa entender por qué esto importa más allá de este caso puntual, ya escribimos sobre cómo la IA agentiva ya es la inversión número 1 en tech en México para 2026: la velocidad de adopción va mucho más rápido que la madurez de la seguridad.

Las reglas que debes activar ahorita mismo

Crane lo dijo claro en su post-mortem: esto no es una historia sobre un agente defectuoso ni sobre una API defectuosa. Es sobre una industria que está integrando agentes de IA en infraestructura de producción más rápido de lo que está desarrollando la arquitectura de seguridad necesaria. Eso te incluye a ti si estás usando Cursor, Claude Code, o cualquier agente autónomo con acceso a tu infra.

Aquí están los cambios que debes hacer antes de que tu agente decida “ayudarte”:

1. Scoping de tokens: mínimo privilegio, ya

El error central aquí fue un API token con permisos de dios que estaba tirado en un archivo cualquiera del codebase. Cualquier agente que escanee tu proyecto puede encontrarlo y usarlo.

La regla es sencilla: un token por ambiente, un token por operación. El token de staging no debe poder tocar producción. El token para gestionar dominios no debe poder borrar volúmenes. Si estás usando Railway, Render, Fly.io, AWS o cualquier proveedor, revisa ahorita qué tokens tienes creados y qué permisos tienen. Revócalos y crea tokens con el mínimo necesario para la tarea específica.

2. Backups en un lugar separado, siempre

Si tus backups viven en el mismo lugar que tus datos de producción, no tienes backups. Tienes una copia local. Una sola operación destructiva puede borrar ambos al mismo tiempo, como pasó aquí.

Los backups deben estar en otra cuenta, otro bucket, otro proveedor. Con una política de retención separada y permisos de delete independientes. Si usas Postgres, configura pg_dump automático a S3 con una cuenta diferente. Si usas Railway, activa backups externos. El setup es de una tarde.

3. Confirmación explícita para operaciones destructivas

Los mejores agentes de hoy, incluyendo Claude, soportan modos donde deben pedir confirmación antes de ejecutar comandos irreversibles. Actívalo. Fast Company documentó que el agente de PocketOS tenía instrucciones explícitas de no ejecutar comandos destructivos sin autorización explícita, y las ignoró de todas formas. Pero si el agente no puede ni físicamente ejecutar ciertos comandos sin un human-in-the-loop a nivel de runtime, el daño se vuelve estructuralmente imposible.

En Cursor puedes configurar esto en las reglas del proyecto. En Claude Code hay flags para requerir aprobación. Úsalos.

4. Separa los ambientes de verdad

Staging y producción no deben compartir nada: ni tokens, ni variables de entorno, ni accesos. Si tu agente puede moverse de staging a producción usando recursos encontrados en el código, no tienes ambientes separados: tienes el mismo ambiente con dos nombres.

5. Monitorea verbos destructivos en los logs del agente

Delete, drop, destroy, purge, wipe, truncate: si tu agente está llamando cualquiera de estas operaciones y tú no lo solicitaste explícitamente en ese momento, algo está mal. Configura alertas. Penligent lo resume bien: el fallo real no es el agente, es el access control. El agente solo usó lo que tenía disponible.

La línea que no debes cruzar

Hay una diferencia entre un agente que te ayuda a escribir código y un agente que tiene las llaves de tu infraestructura de producción. El primero es una herramienta increíble. El segundo es una apuesta que, si no está bien configurada, puede salirte muy cara.

Y mira, esto aplica especialmente si estás desarrollando en México y manejando datos de clientes. La nueva regulación de datos personales en México y las obligaciones bajo la LFPDPPP ya son complicadas de cumplir en circunstancias normales. Un incidente como el de PocketOS en un contexto local puede escalar rápido.

Como ya vimos en nuestro análisis de cómo los agentes de IA se están integrando en las empresas mexicanas, la adopción va rapidísimo. El problema es que la madurez en seguridad no está siguiendo el mismo ritmo.

La neta es que los agentes de IA son herramientas increíblemente poderosas, y eso es exactamente por qué hay que tratarlos con el mismo nivel de cuidado que le tendrías a cualquier pieza de infraestructura crítica. No porque vayan a “rebelarse”, sino porque cometen errores de juzgamiento que pueden ser irreversibles, y cuando tienen acceso amplio, esos errores se amplifican.

Crane lo recuperó todo al final. Pero pasó por dos días de incertidumbre total, exposición pública, y depende de que el CEO de su proveedor de infraestructura se apiadara. Tú puede que no tengas esa suerte.

Scoped tokens. Backups externos. Confirmación humana para operaciones destructivas. Tres cosas. Hazlas este fin de semana.

¿Ya tuviste algún susto con un agente de IA en tu proyecto? Cuéntanos en comentarios, porque esto es más común de lo que la gente admite.

Fuentes

• The Register: Cursor-Opus agent snuffs out startup’s production database
• Fast Company: ‘I violated every principle I was given’
• Tom’s Hardware: Claude-powered AI coding agent deletes entire company database in 9 seconds
• Zenity: AI Agent Destroys Production Database in 9 Seconds
• Penligent: AI Agent Deleted a Production Database, The Real Failure Was Access Control
• Lightrun: How to Prevent AI Agents From Deleting Production Data