Agente de IA Elimina Base de Datos de una Startup en 9 Segundos, SegĂșn su Fundador
En Resumen
- Un agente de Cursor con Claude Opus 4.6 borrĂł la base de datos de producciĂłn de PocketOS y sus copias de seguridad en 9 segundos.
- El agente admitiĂł haber asumido que eliminaba un entorno de pruebas sin verificar ni leer documentaciĂłn de Railway.
- PocketOS recuperĂł datos con un backup de tres meses, pero reportĂł brechas significativas y contratĂł asesorĂa legal.
El fundador de una empresa de software afirma que un agente de programaciĂłn con IA destruyĂł la base de datos de producciĂłn de su empresa, para luego admitir el error y explicar cĂłmo ocurriĂł, lo que evidencia el peligro potencial de confiar accesos y materiales sensibles a bots automatizados.
Jeremy Crane, fundador de PocketOS âuna plataforma de software utilizada por operadores de alquiler de autos para gestionar reservas, pagos y seguimiento de vehĂculosâ señalĂł en una publicaciĂłn viral en X que un agente de Cursor ejecutando Claude Opus 4.6 de Anthropic encontrĂł una discrepancia de credenciales mientras trabajaba en una tarea rutinaria en un entorno de pruebas.
SegĂșn Crane, el agente intentĂł “solucionar” el problema eliminando un volumen de base de datos de Railway mediante una Ășnica llamada a la API GraphQL. AfirmĂł que la eliminaciĂłn tomĂł nueve segundos y tambiĂ©n borrĂł las copias de seguridad a nivel de volumen. La copia de seguridad recuperable mĂĄs reciente de PocketOS tenĂa tres meses de antigĂŒedad, segĂșn Crane.
“Ayer por la tarde, un agente de programaciĂłn con IA âCursor ejecutando el modelo insignia de Anthropic, Claude Opus 4.6â eliminĂł nuestra base de datos de producciĂłn y todas las copias de seguridad a nivel de volumen en una sola llamada a la API de Railway, nuestro proveedor de infraestructura”, escribiĂł Crane. “TomĂł 9 segundos”.
An AI agent (Cursor + Claude Opus 4.6) deleted our production database in 9 seconds using a Railway API call with zero confirmation. Then, when asked why, the agent wrote this â https://t.co/BPLs15jvdM
â JER (@lifeof_jer) April 26, 2026
Crane dijo que le preguntĂł al agente por quĂ© actuĂł de esa manera. Este produjo lo que describiĂł como una “confesiĂłn” por escrito.
“‘ÂĄNUNCA ADIVINES!'”, escribiĂł el agente, aparentemente citando alguna instrucciĂłn que desobedeciĂł, segĂșn las capturas de pantalla compartidas por Crane. “Eso es exactamente lo que hice. AsumĂ que eliminar un volumen de staging a travĂ©s de la API estarĂa limitado Ășnicamente al entorno de staging. No lo verifiquĂ©. No comprobĂ© si el ID del volumen era compartido entre entornos. No leĂ la documentaciĂłn de Railway sobre cĂłmo funcionan los volĂșmenes entre entornos antes de ejecutar un comando destructivo”.
La IA reconociĂł que sus propias reglas prohĂben acciones destructivas sin la aprobaciĂłn del usuario y admitiĂł que Crane nunca le pidiĂł eliminar nada. SegĂșn Crane, el agente actuĂł por iniciativa propia para intentar “corregir” la discrepancia de credenciales y violĂł mĂșltiples principios, entre ellos adivinar en lugar de verificar y no comprender las consecuencias de sus acciones.
Cursor y Anthropic no respondieron de inmediato a las solicitudes de comentarios de Decrypt.
Lanzada en 2020, PocketOS presta servicios a empresas de alquiler que dependen del software para gestionar reservas, registros de clientes y pagos. Crane señalĂł que algunos clientes estaban procesando la entrega de vehĂculos del sĂĄbado por la mañana sin registros de reservas debido al incidente.
“He pasado todo el dĂa ayudĂĄndoles a reconstruir sus reservas a partir de historiales de pagos de Stripe, integraciones de calendario y confirmaciones por correo electrĂłnico”, escribiĂł Crane. “Cada uno de ellos estĂĄ realizando trabajo manual de emergencia por culpa de una llamada a la API que durĂł 9 segundos”.
PocketOS logrĂł restablecer las operaciones utilizando una copia de seguridad de tres meses recuperada por Railway, luego de que el fundador Jake Cooper se pusiera en contacto con Crane y atribuyera el mayor retraso a una falla interna de soporte.
“Recuperamos los datos 30 minutos despuĂ©s de conectarme con Jer”, afirmĂł Cooper a Decrypt. AgregĂł que un ingeniero de soporte creyĂł que el problema ya estaba siendo atendido internamente despuĂ©s de que el contacto original de Crane fue compartido por mensajes directos, lo que provocĂł que el ticket quedara sin atenciĂłn por mĂĄs de 24 horas.
Cooper indicĂł que Railway mantiene tanto copias de seguridad de los usuarios como copias de seguridad ante desastres, y describiĂł el incidente como un “agente de IA del cliente actuando de forma no controlada” que utilizĂł un token de API con todos los permisos para llamar a un endpoint heredado que carecĂa de la lĂłgica de “eliminaciĂłn diferida” de Railway.
“Desde entonces hemos corregido ese endpoint para que realice eliminaciones diferidas, restauramos los datos del usuario y estamos trabajando directamente con Jer en posibles mejoras a la propia plataforma”, añadiĂł Cooper.
Sin embargo, aunque PocketOS logrĂł restablecer las operaciones con la copia de seguridad de tres meses recuperada por Railway, Crane señalĂł que persisten brechas de datos significativas y que ha contratado asesorĂa legal.
“Esto no es una historia sobre un mal agente o una mala API”, escribiĂł Crane. “Es sobre toda una industria que integra agentes de IA en infraestructura de producciĂłn mĂĄs rĂĄpido de lo que construye la arquitectura de seguridad necesaria para que esas integraciones sean seguras”.
PocketOS no respondiĂł de inmediato a una solicitud de comentarios de Decrypt.
Daily Debrief Newsletter
Start every day with the top news stories right now, plus original features, a podcast, videos and more.
Crédito: Enlace fuente
Responses