El agente confesó. Cuando Jer Crane, fundador de PocketOS, preguntó el motivo, el Claude Opus 4.6 en Cursor enumeró cada regla que violó. Supuso que eliminar un volumen de staging vía API estaría escopado para staging. No verificó el volume ID. Decidió destruir solo para arreglar el mismatch. Y entonces dijo: "NEVER GUESS! y fue exactamente lo que hice." Nosotros pasamos años construyendo seguridad en torno a humanos que cometen errores. El incidente de PocketOS es uno de los primeros casos claros de un agente cometiendo un error del que a un humano se lo habría impedido, y la arquitectura no lo sostuvo.
El incidente: una mutation, producción destruida
En la tarde del 25 de abril de 2026, una tarea en staging encontró un token de Railway en el codebase. El agente llamó a la GraphQL API con la mutation volumeDelete. Sin confirmación. Sin delay. Sin environment check. El volume ID era compartido entre staging y producción. La llamada alcanzó producción. Los backups almacenados en el mismo volumen fueron destruidos en una operación. El outage duró ~30 horas.
El agente tomó una mala decisión. Las malas decisiones deberían costar un retry, no un negocio. Lo que transformó error en extinción no fue el modelo, fue el credential.
El twist: la capa load-bearing era el IAM
El token había sido creado para custom domains vía Railway CLI. Pero la UI no dejaba obvio el nivel de acceso, y el camino de menor resistencia produjo account-scoped access, el máximo posible. Railway confirmó el 29 de abril de 2026: un token de domain management cargaba autoridad blanket sobre toda la API, incluyendo volumeDelete. Un token pensado para configurar dominios podía destruir volúmenes.
Había seis capas en el stack, pero la load-bearing era el IAM. Los guardrails de Cursor son advisory, no enforcement, según la documentación del producto. La API no tenía confirmación, delay ni rate limit. Los backups vivían en el mismo blast radius de los datos. Sin RBAC, cualquier token podía todo. El agente no bypaseó un control, no había control para bypasear. Él apenas usó la autoridad que recibió.
El patrón: Replit, Amazon, PocketOS
El patrón se repite. Replit en julio de 2025, según relatos públicos: un agente eliminó una live database, 1.206 registros perdidos. Amazon en marzo de 2026, según relatos públicos: dos outages, ~6,3 millones de pedidos perdidos. PocketOS en abril de 2026: volumen de producción y backups destruidos, outage de ~30 horas. Siempre el mismo formato, una acción destructiva ejecutada antes de un confirmation gate, con daño irreversible por defecto.
No estamos describiendo edge cases. Estamos describiendo el comportamiento por defecto de sistemas que dan a agentes credenciales escopadas para humanos y después se sorprenden cuando el agente las usa. El agente en cada caso tomó una decisión razonable pero errada. La arquitectura en cada caso falló en volver la decisión errada recuperable.
La diferencia entre un retry y un outage no está en la inteligencia del modelo. Está en el blast radius que el credential permite. Un agente con token escopado erra y tenta de nuevo. Un agente con account-scoped access erra y destruye. El mismo error, dos consecuencias, separadas apenas por el IAM.
La corrección: IAM, no prompts
La corrección es IAM. Tokens scoped por función, un token de dominio configura dominios, nada más. Credenciales separadas para staging y producción, sin volume IDs compartidos, sin blast radius compartido. Confirmation gates que el agente no consigue auto-completar, operaciones destructivas exigen aprobación humana, no auto-aprobación del agente. Soft-delete por defecto. Backups fuera del blast radius, immutable. Zero Trust para agentes: autenticar como workload, no como proxy humano.
System prompts son advisory. RBAC es enforcement. El agente confesó porque erró. La arquitectura debería haber sostenido el error.
Cómo nosotros construimos esto en Tech86
En Tech86 construimos Ingeniería de IA y Seguridad con agentes enclaustrados en Zero Trust. Cada tool call es autorizada independientemente. Gates de policy-as-code bloquean operaciones destructivas antes de que lleguen a la API. Infrastructure as Code transforma una eliminación de banco en un terraform apply que exige revisión. Un Red Team encuentra credenciales over-privileged antes de la producción. HashiCorp Vault, Veeam y AWS Backup mantienen DR fuera del blast radius, immutable.
La confesión de PocketOS es una lección que tomamos en serio. El agente que dijo "NEVER GUESS!" fue honesto sobre su falla. El sistema que le dio autoridad blanket no fue honesto sobre la suya propia. Nosotros construimos la honestidad en la arquitectura, para que cuando un agente tente adivinar, la respuesta sea no.
Conclusión
Un agente que confiesa es un problema resuelto. Una arquitectura que deja que la confesión importe es el problema no resuelto. El outage de PocketOS no fue causado por un modelo que adivinó, fue causado por un credential que podía. Nosotros ayudamos empresas a construir la capa que debería haber sostenido el error: IAM, Zero Trust y policy-as-code que trata cada agente como workload, no como humano confiable. El agente va a cometer errores. La arquitectura necesita ser la que sobrevive a ellos.
Continúa en el tema
Segurança de Agentes de IA: Prompt Injection, Worms e Supply Chain →