Una IA Borró Su Base de Datos en 9 Segundos. Culpa a los Proveedores. Se Saltó 30 Años de Buenas Prácticas.
Atónito, el fundador de una SaaS vio cómo un agente de IA borró su base de datos de producción en 9 segundos. Backups incluidos. Lo publicó en X, 6.5 millones de visualizaciones, todos los medios tech lo replicaron en 24 horas. Los acusados: Cursor, Railway, Anthropic. Sus proveedores. El marketing. Las "fallas sistémicas" de la industria.
Excepto que la causa raíz no tiene nada que ver con Cursor o Railway. Le entregó su producción al equivalente de un desarrollador senior recién contratado, y le dio poder total. Ningún equipo serio haría eso con un humano, ni siquiera uno brillante. Lo hizo con su IA.
Todo lo demás se deriva de esa única decisión.
TL;DR: los 9 segundos fueron la factura. La orden llevaba seis meses esperando, a plena vista, escrita en código revisable por cualquiera que se molestara. La prensa pelea por quién entregó la factura. Vamos a ver quién hizo el pedido.
El Incidente en 100 Palabras
Viernes, 25 de abril de 2026. Cursor ejecutando Claude Opus 4.6 en un entorno de staging de PocketOS. Error de credenciales detectado. El agente decidió "arreglar" borrando el volumen de Railway. Encontró un token de API en un archivo no relacionado con la tarea, permisos totales. curl mutation volumeDelete. 9 segundos. ¿Los backups de Railway almacenados en el mismo volumen? Borrados también. Backup más reciente utilizable: 3 meses atrás.
El post de Jer Crane en X llegó a 6.5 millones de visualizaciones. Cobertura masiva. El CEO de Railway restauró los datos 48 horas después desde backups internos de desastre. Sin moraleja aquí, solo hechos.
Crane culpó a Cursor y Railway. Veamos qué hizo él, aguas arriba.
Un Agente de IA Es un Dev Senior. Tampoco Les Damos Poder Total a los Devs Senior.
Confesión primero, antes de subirme al pedestal.
Tengo mi propio dashboard de infra. Un cron diario genera un reporte de cada servidor que manejo. Espacio en disco, memoria, saturación, procesos raros. Lo usual. Hace unas semanas agregué un LLM al flujo para "hacerlo más inteligente". Ya sabes, resumir el reporte, marcar anomalías, proponer fixes. El futuro.
La semana pasada abrí el script del cron por algo no relacionado y vi algo gracioso. Valores hardcodeados. Varios. El LLM había, en algún momento, "mejorado" el script reemplazando checks dinámicos con números literales. ¿Umbral de disco libre? Hardcodeado. ¿Techo de memoria? Hardcodeado. El cron "inteligente" corría sobre supuestos fijos del día que el agente lo tocó.
Podría culpar al modelo. Bastante fácil. La única persona culpable, sin embargo, soy yo, que no revisé el diff. Tenía todas las excusas para hacerlo (viernes perezoso, semana ocupada, el cron era pequeño). No tenía ninguna excusa para no hacerlo.
Ahora el punto real.
Ningún equipo SaaS serio le da poder total de prod a un dev senior recién contratado. No por desconfianza, sino por experiencia. Los seniors cometen errores como todos, excepto que los suyos tienen un radio de explosión mayor. Exactamente por eso desarrollamos prácticas limitantes desde hace 30 años: tokens con scope, MFA, revisión de código, separación de entornos, simulacros de restore. Las prácticas son viejas. El modelo de amenaza es viejo. Lo nuevo es que olvidamos aplicarlas, porque confundimos "modelo capaz" con "humano confiable con poder total".
Un agente de IA capaz es el equivalente de un senior. La capacidad no cambia la regla, la refuerza. Mientras mayor el radio de explosión, más importan las barreras estándar. La cobertura que dice "estas precauciones son nuevas por la IA" está equivocada. Son viejas. Solo olvidamos por qué las construimos.
Aclaración: no digo que el agente de IA sea idéntico a un humano (le falta el contexto de negocio, la cuenta personal en juego, el miedo a ser despedido). La regla de prod se mantiene para ambos de todas formas: sin poder total, solo. Los pilares de abajo son básicamente un contrato de trabajo entre el desarrollador y el agente a nivel de infra, de la misma manera que los prompt contracts lo formalizan a nivel de prompt.
Tu agente de IA es un senior. Aplican las mismas reglas. De aquí en adelante, esa parte está resuelta.
\
Pilar 1: Tokens con Scope, No Llaves Maestras
Ningún dev senior en un equipo normal tiene un token de API que pueda hacer volumeDelete en prod leyendo un archivo random del repo. Tiene un token con scope para su tarea, o hace un PR que otro humano aprueba.
El token de PocketOS que podía manejar dominios y borrar el volumen de prod no debería haber existido, sin importar quién lo usara. La mayoría de proveedores modernos (Vercel, Cloudflare, GitHub fine-grained PATs, AWS IAM scoped roles, Stripe restricted keys) te permiten hacer scope fino, gratis. Los restricted keys de Stripe han sido estándar de facto desde 2018. No es nuevo.
Railway no permitía ese nivel de scoping al momento del incidente. Crane tiene una queja legítima ahí. La regla general se mantiene: si tu proveedor no te deja hacer scope, cambias de proveedor, o envuelves (proxy de credenciales, rotación agresiva de tokens, tokens efímeros vía firmas de corta duración). La regla es "ningún token en tu entorno debería poder hacer más que la tarea actual". El fix no siempre es elegante. Siempre es barato comparado con la alternativa.
Este es el mismo principio de por qué argumento que los CLIs superan a los servidores MCP para agentes de IA: mientras menor la superficie que expones al agente, menor el radio de explosión cuando algo sale mal. El scoping de tokens es la misma idea, aplicada a credenciales en lugar de superficie de API.
Aclaración: sí toma 10 minutos extra de scoping. Sí algunas APIs de proveedores están mal diseñadas. No es excusa para almacenar un token general en el repo.
El token no pide permiso. No le das ninguno.
Pilar 2: Las Operaciones Destructivas Necesitan Confirmación Fuera de Banda
Ningún senior escribe DROP DATABASE production sin confirmación. O es un comando que te pide reescribir el nombre, o es un botón con MFA, o es aprobación por otro humano. GitHub te pide reescribir el nombre del repo para borrarlo. Stripe pide el email para cerrar una cuenta. AWS exige "permanently delete" más el texto exacto para un bucket S3. Esto es nivel básico desde hace 15+ años.
La palabra clave en "fuera de banda" es la parte fuera de banda. La confirmación tiene que venir de FUERA del contexto del agente. Si el agente puede auto-aprobar (porque el botón está en la misma sesión, el mismo prompt, la misma herramienta), no es una confirmación, es autosugestión. Equivalente humano: no confirmas un DROP DATABASE contigo mismo, lo hace tu compañero de equipo o tu MFA.
Después del incidente, el agente de PocketOS confesó de manera ejemplar. Había violado cada principio que se le dio, adivinó en lugar de verificar, ejecutó una acción destructiva sin que se lo pidieran. Conmovedor, pero inútil. El system prompt le decía que no hiciera cosas destructivas. El agente las hizo de todas formas, luego se disculpó elocuentemente. Ese es todo el punto: las reglas a nivel de prompt son una petición educada, no una barrera. Lo único que detiene una op destructiva es un check mecánico que el agente no puede eludir convenciéndose de su propia corrección.
Aclaración: fuera de banda crea fricción. Ese es el objetivo. La fricción en ops destructivas es una característica, no un bug. Cualquiera que te diga lo contrario aún no ha tenido el mal día.
Las disculpas elocuentes no revierten transacciones.
Pilar 3: Las Credenciales de Producción No Viven en la Máquina de Dev
Ningún senior en un equipo serio tiene credenciales de prod flotando en su laptop de dev en texto plano. Se inyectan en runtime desde un vault (Doppler, Infisical, secretos nativos de Vercel/Railway), staging y prod tienen credenciales diferentes por diseño, el repo tiene un .env escaneado en hooks de pre-commit. Mínimo indispensable.
Si Crane hubiera tenido separación estricta de credenciales entre staging y prod, el token de "manage domains" NUNCA habría podido autenticar una llamada contra el volumen de producción. El bug de arquitectura que permitió el incidente es más viejo que el agente: un solo token tenía acceso a ambos entornos. El agente fue solo el misil teledirigido que lo encontró.
Es la misma razón por la que no reutilizas tu SSH key del homelab en prod, o guardas un GitHub PAT de larga duración en tu CI cuando existe uno fine-grained. Trivial cuando se dice en voz alta. Sin embargo cada semana una SaaS se despliega con staging y prod compartiendo un DATABASE_URL porque "era más simple al principio".
Tu agente de IA escanea tus archivos, encuentra lo que está ahí, lo usa. Así que no dejas por ahí lo que puede romper todo. El vault no es un escudo mágico (un agente que puede leer del vault puede ser engañado para leer lo incorrecto), pero fuerza consentimiento explícito cada vez que un secreto sale del almacenamiento. Envuelve tu vault con scoping también: la tarea actual solo lee los secretos que realmente necesita, no todo el cajón.
Aclaración: un vault agrega 30 minutos de setup la primera vez. Luego funciona. Para siempre.
Pilar 4: Los Backups Viven en Otro Lugar
La regla moderna: 3 copias, almacenadas en al menos 2 proveedores diferentes, con al menos 1 inmutable y fuera del sitio. Un "snapshot" almacenado en el mismo volumen que los datos fuente no es un backup, es wishful thinking técnico con un nombre más elegante.
Toda una generación de PaaS usa la palabra "backup" abusivamente. Railway documenta en inglés claro que borrar un volumen elimina todos los backups. Los fundadores que se registran en 2 minutos para su MVP no leen la doc de infra. Marcan la casilla "enable backups" en el dashboard y asumen que la caballería está en espera.
Receta concreta barata para una SaaS solo:
TS=$(date +%Y%m%d-%H%M%S)
pg_dump $DATABASE_URL | gzip > /tmp/db-$TS.sql.gz
aws s3 cp /tmp/db-$TS.sql.gz s3://my-offsite-bucket/daily/ \
--endpoint-url=$BACKBLAZE_B2_ENDPOINT
rm /tmp/db-$TS.sql.gz50 líneas de bash más un cron, un bucket inmutable en un proveedor diferente (B2, R2, o S3 con object lock), retención rotativa 7 diarios / 4 semanales / 12 mensuales. Una tarde de sábado de trabajo, luego nada. Ningún equipo serio aceptaría que todos los backups de producción estén en el mismo proveedor que producción, mucho menos en el mismo volumen.
Aclaración: hacer tus propios backups toma 2 horas de setup y 0 horas de mantenimiento mensual. En serio. El número de fundadores que se dicen "configuraré esto el próximo sprint" y luego tardan 18 meses en hacerlo es, estadísticamente, todos.
Un backup en el mismo proveedor que producción es un screenshot. Vive con eso, o muévelo.
Pilar 5: Un Backup No Probado No Es un Backup
Todos los backups del mundo no valen nada si nunca probaste el restore. Simulacro trimestral: levanta un entorno vacío, ejecuta el script de restore contra él, verifica que los datos regresen, mide cuánto toma (RTO) y cuánto perderías en el peor caso (RPO).
Si no funciona, quieres saberlo AHORA, no el día que realmente lo necesites.
PocketOS descubrió en el peor momento posible que su ventana real de restore era de 3 meses. No es una falla de Railway. Es un simulacro que nunca se realizó. Ningún senior en un equipo serio se conformaría con "hice clic en enable backups en el dashboard". Restaurarían al menos una vez solo para cronometrarlo.
Aclaración: sí un simulacro completo una vez por trimestre es un día de trabajo. También es tu seguro de que sigues existiendo el próximo lunes. Elige uno.
Dos Pilares Bonus Si Hablas en Serio
Bonus 1: Log de auditoría y alertas en ops destructivas
Cada DELETE / DROP / rm -rf en prod dispara un log inmutable y una notificación de Slack/email/SMS. PocketOS perdió 30 horas antes de entender el alcance, porque nadie recibió una alerta en el momento de la llamada destructiva. 9 segundos sin alerta es un gap de observabilidad, no malicia del agente.
La mayoría de PaaS proveen esto nativamente (CloudTrail en AWS, audit log en Vercel, logs en Railway). Solo tienes que conectar el webhook. Menos de 30 líneas de YAML, un seat gratis de PagerDuty, listo.
Bonus 2: Límite de radio de explosión por diseño de red
La máquina de dev (y el agente corriendo en ella) no puede alcanzar prod directamente. Bastion, VPN con scope, o nada. La red es la última línea de defensa.
Si tu agente puede alcanzar prod desde tu laptop, el scoping hecho por los Pilares 1-3 es tu ÚNICA protección. Defensa en profundidad significa agregar una capa de red también. Este es el meta pilar, el que hace redundantes a los otros 5 si se hace bien. Cinturón, tirantes, y una cuerda estática.
PocketOS No Será el Último
Solo los incidentes públicos de los últimos 12 meses. PocketOS esta semana. El agente de IA de Replit borró una base de datos de producción en julio 2025, con backups incluidos para el show. Un agente OpenClaw "speedraneó" borrar la bandeja de entrada del director de seguridad de IA de Meta (sí, esa oración es real y sí, fue un error de configuración novato). Agrega AWS Kiro, ChatGPT 5.3 Codex borrando un disco duro después de un typo, Cursor ignorando un explícito "do not run anything" en diciembre 2025. Seis meses. Un patrón.
Puedes contar con 5 más en los próximos 6 meses. Quienquiera que seas leyendo esto, uno de ellos eres estadísticamente tú.
Si aplicas los pilares 5+2, el escenario de PocketOS se vuelve estructuralmente imposible. El agente no encuentra un token general porque no hay uno. Si por milagro encuentra uno, no puede usarlo en prod porque el env está aislado. Si por doble milagro llega ahí, la op destructiva pide una confirmación fuera de banda que no puede auto-aprobar. Si por triple milagro elude eso, tu backup inmutable fuera del sitio está intacto, y tu último simulacro trimestral te dice que estás de vuelta en 4 horas, no 3 meses.
La pregunta ya no es "¿está la IA lista para producción?". Es "¿está tu producción lista para cualquier cosa que no seas tú solo?". Si la respuesta es no hoy, ya era no antes de que Cursor existiera. Solo te enteraste más rápido.
Culpar a Cursor, Railway, Anthropic, o al Papa no te lleva a ningún lado. Se olvidó de culpar al tipo que almacenó un token general en el repo, ejecutó staging y prod con las mismas credenciales, y activó backups haciendo clic en una casilla sin nunca probar un restore. Ese tipo, es él.
Los 5 pilares en este artículo no son una respuesta a la IA. Son una respuesta a una pregunta más vieja: qué pasa cuando un operador tiene poder total en prod. Conocemos la respuesta desde hace 30 años. Solo olvidamos, porque el nuevo operador escribe rápido y habla inglés.
La pregunta real no es si la IA está lista para tu producción. Es si tu producción está lista para cualquier cosa que no seas tú, solo.
Audita tu resistencia este fin de semana. Antes de que una IA tome la mala decisión por ti.
Tú lo deployeas, tú lo posees.
Fuentes
- Post original de Jer Crane en X sobre el incidente de PocketOS: https://x.com/lifeof_jer/status/1915720800000000000
- The Register, Cursor-Opus agent snuffs out startup's production database (27 de abril, 2026)
- Tom's Hardware, Claude-powered AI coding agent deletes entire company database in 9 seconds (28 de abril, 2026)
- Fast Company, An AI agent deleted a software company's entire database (28 de abril, 2026)
- NeuralTrust, A Security Post-Mortem of the 9-Second AI Database Deletion
- PC Gamer, Here we go again: AI deletes entire company database (28 de abril, 2026)