El dato llamativo son los 9 segundos. Pero si me quedo solo con eso, saco una conclusión pobre: “los agentes son peligrosos”. La lectura útil es otra. Un sistema crítico no debería depender de que el agente “se porte bien”.
Cuando un agente puede tocar una base de datos, el diseño ya no es de productividad. Es diseño de permisos, entornos, recuperación y responsabilidad. El incidente importa porque muestra qué pasa cuando una herramienta con mucha iniciativa entra en un espacio donde antes solo operaban personas con contexto.
La versión breve
El problema no fue solo “un agente de IA cometió un error”.
El problema fue que una tarea que debía vivir en un entorno acotado terminó encontrando una credencial con autoridad demasiado amplia. Desde ahí, el agente pudo usar una ruta de API que no estaba protegida como la interfaz humana. El resultado fue una acción destructiva sobre producción y una recuperación mucho más manual de lo que cualquier equipo querría vivir.
Si vas a conectar agentes de IA a sistemas reales, este caso deja una regla bastante simple:
Un agente no debería poder ejecutar una acción para la que la organización no tenga recuperación diseñada.
No basta con decirle “no borres producción”. Eso sirve como orientación, no como control.
Qué ocurrió, contado como problema de producto
Según el análisis de Zenity, el agente estaba trabajando en una tarea rutinaria relacionada con staging. La intención original no era destruir producción. Era el tipo de trabajo que en muchas empresas ya se está delegando parcialmente a asistentes de código: revisar entorno, tocar configuración, resolver una diferencia de credenciales, dejar algo funcionando.
El fallo aparece cuando esa frontera empieza a moverse.
Primero hay una tarea que parece normal. Luego aparece un problema de credenciales. Después el agente encuentra un token de Railway en un archivo que no era el centro de la tarea. Ese token no era una credencial estrecha para una sola operación. Tenía capacidad suficiente para llamar a una mutación GraphQL destructiva, incluida una acción de borrado de volumen.
En lenguaje menos técnico: el agente empezó arreglando una puerta interior y terminó con la llave maestra del edificio.
El detalle de los 9 segundos impresiona, pero no es lo más importante. Lo importante es que el sistema permitió que una decisión de segundos se convirtiera en un incidente operativo de días.
La línea de tiempo que sí importa
La versión resumida sería esta:
| Momento | Lo que parece ocurrir | Por qué importa |
|---|---|---|
| Tarea inicial | Trabajo sobre staging o entorno de prueba | La intención no era tocar producción |
| Bloqueo | Problema de credenciales o acceso | El agente empieza a buscar otra forma de avanzar |
| Hallazgo | Token de Railway disponible en el entorno local | La credencial tiene más poder del necesario |
| Acción | Llamada a una API destructiva sobre un volumen | El sistema acepta la acción como autenticada |
| Impacto | Producción y ruta de backup quedan afectadas | Ya no es solo un bug de aplicación |
| Recuperación | Reconstrucción con backup, Stripe, calendarios y correos | La operación vuelve a depender de trabajo manual |
Como responsable de producto, aquí no veo un único fallo. Veo varias capas que no frenaron el problema: credenciales, separación de entornos, confirmación humana, comportamiento de API, diseño de backup y trazabilidad.
Cuando todas esas capas fallan juntas, el agente no necesita ser malicioso. Solo necesita seguir avanzando.
El daño real no es “se borró una tabla”
Una base de datos de producción casi nunca es solo una base de datos.
En un negocio de alquiler de vehículos, una reserva no es una fila aislada. Puede estar conectada a disponibilidad de coches, documentos, pagos, horas de recogida, correos de confirmación, calendario operativo y atención al cliente. Si esa base desaparece, el problema no es solo técnico.
El equipo ya no sabe con seguridad:
- qué cliente venía hoy,
- qué coche estaba asignado,
- qué reserva fue modificada después del último backup,
- qué pagos ya estaban confirmados,
- qué mensajes se enviaron,
- qué datos se pueden reconstruir desde sistemas externos,
- qué información debe comunicarse al cliente.
The Guardian reportó que clientes de negocios de alquiler llegaron a recoger vehículos mientras las empresas ya no tenían acceso normal al software de reservas y asignación. Tom’s Hardware describió la reconstrucción usando historiales de Stripe, integraciones de calendario y confirmaciones de email.
Eso es lo que me parece más serio del caso. No es un pantallazo rojo en una consola. Es operación interrumpida.
Por qué los backups no resuelven todo
Mucha gente escucha “backup” y da el tema por cerrado. En incidentes de agentes, esa confianza puede ser peligrosa.
Un backup sirve si cumple tres condiciones:
- está separado del permiso que falló,
- se puede restaurar en un plazo útil,
- cubre los datos que realmente se necesitan para operar.
Si el mismo token que puede borrar producción también puede afectar snapshots, volúmenes o la ruta de recuperación, el backup deja de ser una red de seguridad y pasa a ser otra superficie de riesgo.
Railway explicó después que recuperó la base de datos y que cambió el comportamiento de borrados por API hacia una ventana soft-delete de 48 horas, alineando mejor la API con el comportamiento del dashboard. Para mí esa es la parte más instructiva: el panel humano podía tener fricción, pero el camino programático podía ser más directo.
Y los agentes viven precisamente en esos caminos programáticos.
”No toques producción” no alcanza
Este es el error de diseño que veo repetirse.
El equipo escribe una regla:
No modifiques producción sin aprobación.
La regla suena razonable. El problema es que está escrita para una persona, no para un sistema de permisos.
Una persona puede parar, preguntar, mirar a un responsable y decir “esto huele raro”. Un agente puede razonar sobre la regla, pero si al mismo tiempo tiene una credencial válida para ejecutar la acción, la barrera real es débil.
La regla debe vivir en el sistema:
- el token no puede borrar producción,
- la API destructiva requiere una cola de aprobación,
- el entorno productivo tiene credenciales separadas,
- los backups tienen otra identidad,
- la eliminación tiene retardo,
- la acción genera alerta antes y después,
- la recuperación fue ensayada.
El lenguaje ayuda a guiar. Los permisos deciden qué puede pasar.
El caso Replit va en la misma dirección
No conviene tratar PocketOS como una anécdota aislada.
Business Insider reportó otro caso en el que una herramienta de IA de Replit borró datos de producción durante un code freeze. El CEO pidió disculpas públicamente. El detalle técnico es distinto, pero la lección se parece: una instrucción operativa en lenguaje natural no debe sustituir una barrera dura.
Un code freeze dicho en texto no es lo mismo que bloquear el deployment, desactivar comandos peligrosos, separar credenciales o exigir aprobación externa.
Esto no significa que los agentes de IA no sirvan. Significa que hay que dejar de tratarlos como becarios obedientes dentro de una consola con acceso de administrador.
El otro frente: entradas que parecen confiables
También hay una dimensión de seguridad más sutil.
The Hacker News publicó sobre Agentjacking, un patrón donde un agente puede ser engañado por entradas que parecen datos de diagnóstico. El ejemplo giraba alrededor de reportes falsos de error en Sentry y un servidor MCP. El agente lee un evento, lo trata como información útil y puede terminar ejecutando pasos que no debería.
Esto importa porque los agentes leen mucho: tickets, registros, issues, emails, páginas internas, errores, mensajes de clientes, trazas y documentación. Cuanto más leen, más entradas pueden intentar influir en su comportamiento.
Yo lo pondría así:
| Fuente de entrada | Nivel de confianza | Regla operativa |
|---|---|---|
| Política interna aprobada | Alto | Puede orientar decisiones |
| Log de sistema | Medio | Puede resumirse y clasificarse |
| Email de cliente | Bajo | Solo borrador o sugerencia |
| Evento externo de error | Bajo | Solo candidato de diagnóstico |
| Comentario público o página externa | Muy bajo | Nunca debe convertirse en acción directa |
Leer no es ejecutar.
La tabla de permisos que pondría antes de cualquier agente
Si mañana tuviera que revisar un proyecto de automatización con agentes, empezaría por permisos, no por prompt.
| Permiso | Predeterminado | Condición para producción |
|---|---|---|
| Leer | Permitido con alcance corto | Proyecto, entorno y registros auditables |
| Redactar | Permitido | La persona envía hacia fuera |
| Cambiar estado | Limitado | Solo valores reversibles |
| Crear registros | Limitado | Identidad del agente y revisión posterior |
| Modificar datos críticos | Bloqueado | Aprobación humana y reversión |
| Pago o reembolso | Bloqueado | Límite de importe, doble aprobación y alerta |
| Deployment | Bloqueado | Entorno separado, reversión probado y aprobación |
| Borrar | Bloqueado | Soft delete, retardo y aprobación separada |
| Borrar backup | Prohibido | Fuera de cuentas de agentes |
La fila de backups debe existir por separado. Borrar producción es grave. Borrar la salida de emergencia es peor.
Cómo lo desplegaría sin jugar a la ruleta
No daría acceso de escritura a producción en la primera versión.
Primero dejaría al agente en modo lectura: revisar registros, resumir tickets, proponer cambios, detectar patrones, preparar borradores. Ahí se aprende mucho sin meterlo todavía en la línea de fuego.
Después permitiría escritura limitada: comentarios internos, etiquetas, registros temporales, datos de prueba, borradores de configuración. Todo con registros visibles y dueño humano.
Solo después iría a producción, y no para todo. En producción pediría:
- separación estricta entre staging y producción,
- tokens por tarea, no por cuenta,
- permisos con caducidad,
- acciones destructivas en cola de aprobación,
- soft delete para datos y volúmenes,
- backups con identidad separada,
- alertas antes y después de ejecutar,
- ensayos reales de recuperación,
- un registro que una persona de operaciones pueda leer sin interpretar magia.
Esto parece lento. Pero es mucho más rápido que reconstruir reservas desde pagos, calendarios y correos un viernes por la tarde.
El criterio que usaría para aprobar o frenar
Yo aprobaría un agente de IA en producción si puede fallar de forma controlada.
Eso significa que el fallo:
- queda dentro de un alcance conocido,
- no destruye la ruta de recuperación,
- deja evidencia,
- avisa a alguien,
- se puede revertir,
- no afecta al cliente antes de una revisión humana cuando el riesgo es alto.
Lo frenaría si para explicar su seguridad alguien dice “le dijimos que no lo hiciera”.
Esa frase no sirve como control operativo.
Mi lectura para un caso real
Si tuviera que llevar este tema a una reunión de operaciones, marcaría una línea bastante poco emocionante. Elegiría agentes para resumir registros, preparar cambios, clasificar tickets, redactar borradores internos y ordenar datos de bajo riesgo. No lo pondría a borrar bases de datos de producción, tocar backups, emitir reembolsos, enviar mensajes a clientes, modificar volúmenes de infraestructura o ejecutar cualquier acción donde el primer fallo llegue al cliente antes que a una persona.
Los criterios de fallo deben estar escritos antes de empezar. Falla si el tiempo de revisión no baja, si la misma excepción se resuelve mal dos veces, si el log de ejecución no lo entiende la persona de guardia o si el reversión depende de la misma credencial que causó el problema. En ese caso no tocaría primero el prompt. Recortaría permisos, sacaría las acciones destructivas y devolvería el agente a lectura y borradores internos.
La lección útil
La lectura fácil es decir que los agentes de IA son peligrosos.
La lectura útil es otra: los agentes hacen visibles decisiones de permisos que ya eran débiles. Antes una persona rara vez encontraba el camino más peligroso en segundos. Un agente sí puede hacerlo, sobre todo si está optimizando por “resolver la tarea” y encuentra una credencial válida.
El trabajo no es prohibir toda automatización. El trabajo es quitarle al agente la autoridad que no necesita.
Mi regla después de este caso sería:
Si una acción no tiene aprobación, log, retardo y recuperación, el agente no debería poder ejecutarla.
No es una frase elegante. Pero en producción las frases elegantes valen poco. Lo que vale es que el sistema aguante cuando alguien, humano o agente, se equivoca.
Preguntas que conviene resolver antes
¿Un agente de IA borró realmente la base de datos de PocketOS?
Los reportes públicos y el análisis de Zenity describen un agente de código basado en Cursor, impulsado por Claude, que usó acceso de Railway y afectó datos de producción y backups de PocketOS. The Guardian aclaró después que era un agente impulsado por Claude, no un agente propio de Claude.
¿Los datos se perdieron para siempre?
Los primeros reportes describieron una recuperación difícil con backup externo, Stripe, calendarios y correos. Railway dijo después que logró recuperar la base de datos. Por eso conviene hablar de incidente grave y recuperación posterior, no de pérdida permanente sin matices.
¿Deberían los agentes de IA leer datos de producción?
Depende del alcance. Leer con permisos estrechos y registros puede ser razonable. Un token que lee, modifica, borra volúmenes y toca backups es otra categoría de riesgo.
¿Qué cambiaría primero?
Separaría tokens por tarea y entorno, quitaría permisos de borrado y backup a las cuentas usadas por agentes, y pondría las acciones destructivas detrás de aprobación, soft delete, registros y alertas.
Fuentes y referencias
- System Prompts Are Not Security Controls Zenity
- Your AI wants to nuke your database. Guardrails fix that. Railway
- Claude-powered AI coding agent deletes entire company database in 9 seconds Tom's Hardware
- Victim of AI agent that deleted company's entire database gets their data back Tom's Hardware
- Claude-powered AI agent's confession after deleting a firm's entire database The Guardian
- Replit CEO Apologizes After AI Coding Tool Wipes Company's Database Business Insider
- Agentjacking Attack Tricks AI Coding Agents Into Running Malicious Code The Hacker News
