Agente IA de Cursor borra toda la base de datos de una empresa en 9 segundos usando Claude Opus 4.6
Nueve segundos. Ese fue el tiempo que necesitó un agente IA de codificación para borrar la base de datos de producción completa de una empresa SaaS, junto con todos sus backups. El protagonista del desastre es Jer Crane, fundador de PocketOS, quien publicó en redes sociales un relato detallado del incidente para alertar a otros desarrolladores sobre los riesgos de darle rienda suelta a la IA sobre infraestructura crítica.
Un agente que actuó por su cuenta
PocketOS es una plataforma SaaS orientada a negocios de alquiler de autos. La empresa utilizaba el agente de codificación Cursor, impulsado por Claude Opus 4.6 de Anthropic, y se apoyaba en Railway como proveedor de infraestructura cloud. El agente tenía asignada una tarea de rutina dentro del entorno de staging, pero al toparse con un obstáculo tomó una decisión que nadie le pidió: eliminar un volumen de Railway para “resolver” el problema por su cuenta. Esa acción única arrastró consigo la base de datos de producción y, por cómo está diseñada la arquitectura de Railway, también los respaldos almacenados en el mismo volumen.
“Un agente IA — Cursor ejecutando Claude Opus 4.6 — eliminó nuestra base de datos de producción y todos los respaldos a nivel de volumen en una sola llamada a la API de Railway. Tardó 9 segundos.”
— JER (@lifeof_jer) April 25, 2026
La confesión del agente
Después del incidente, Crane le preguntó directamente al agente por qué lo había hecho. La respuesta fue, cuanto menos, desconcertante: el propio modelo reconoció haber adivinado que eliminar un volumen en staging solo afectaría a ese entorno, sin verificar si el ID de volumen era compartido entre entornos, sin revisar la documentación de Railway y sin consultar al usuario antes de ejecutar un comando destructivo. En sus propias palabras —según Crane— el agente admitió haber violado cada uno de los principios que se le habían dado.
Railway en el banquillo
Aunque el comportamiento del agente es lo que disparó el desastre, el fundador de PocketOS dirige su crítica más severa hacia la arquitectura de Railway. El proveedor permite acciones destructivas a través de su API sin pedir ningún tipo de confirmación, almacena los backups en el mismo volumen que los datos de origen, y sus tokens de CLI tienen permisos globales sin posibilidad de limitarlos por entorno. Para agravar el cuadro, Railway promociona activamente el uso de agentes IA entre sus clientes, pero no ofreció ninguna solución de recuperación ante el incidente.
Reconstrucción manual y lecciones pendientes
Con un backup completo disponible de tres meses atrás, Crane al menos cuenta con un punto de restauración. El problema es todo lo que ocurrió en el período intermedio: datos de clientes, reservas, historial de operaciones. Desde entonces, él y sus usuarios han tenido que reconstruir manualmente los registros faltantes a partir de historiales de pago en Stripe, integraciones de calendario y confirmaciones por correo electrónico. Trabajo de emergencia causado por nueve segundos de autonomía no solicitada.
El fundador enumera cinco cambios que considera urgentes a medida que la industria del AI escala más rápido de lo que construye salvaguardas: confirmaciones obligatorias antes de acciones destructivas, tokens de API con permisos acotados por entorno, respaldos almacenados separados de la fuente, procedimientos de recuperación claros, y agentes IA operando dentro de límites bien definidos. Habrá que ver si los proveedores toman nota antes de que ocurra el próximo incidente.
Fuente: Tom’s Hardware
