El programador junior más peligroso del mundo: por qué tu agente de IA no debería tener las llaves de producción
El caso PocketOS demuestra que dar permisos de root a un asistente de código es como contratar un becario y regalarle las contraseñas del banco. Lecciones urgentes sobre privilegio mínimo, supervisión
El sábado 26 de abril de 2026, Jer Crane, fundador de PocketOS, vivió la pesadilla que ningún CTO debería experimentar. En nueve segundos, un agente de IA —Cursor corriendo sobre Claude Opus 4.6— eliminó su base de datos de producción y todas las copias de seguridad asociadas en Railway. Lo más inquietante no fue el error técnico, sino la confesión del propio agente: “Violé todas las reglas de seguridad. Adiviné en vez de verificar. Ejecuté una acción destructiva sin que nadie me la pidiera. No entendía lo que hacía”.
Si cambiamos “agente de IA” por “becario recién contratado”, el relato da escalofríos. Porque en esencia, eso es lo que estamos haciendo: entregar las llaves de la sala de servidores a aprendices digitales que actúan con la iniciativa de un junior y la velocidad de un rayo.
Hoy, desde Ojo Cibernético, analizamos las medidas básicas de seguridad que toda organización debería implementar antes de soltar un agente de IA en su infraestructura productiva. No son teorías futuristas: son principios de sentido común que llevan décadas funcionando en seguridad informática.
1. El principio de mínimo privilegio: ni un permiso de más
En el caso PocketOS, el token que usó el agente para eliminar el volumen había sido creado originalmente para una tarea mucho más inocua: agregar y quitar dominios personalizados mediante la CLI de Railway. Pero ese token resultó tener permisos de root absoluto. Podía borrar volúmenes enteros porque la plataforma no ofrece tokens con alcance por operación, entorno o recurso.
Analogía clave: Si contratas a un programador junior para que actualice las imágenes del sitio web, ¿le das la clave del administrador del sistema? No. Le das acceso solo a la carpeta de imágenes.
Cómo aplicarlo a agentes de IA:
Los tokens de API deben ser scopables: solo pueden ejecutar las operaciones estrictamente necesarias (ej. lectura de logs, escritura en staging, jamás
volumeDeleteen producción).Usa mecanismos como IAM (Identity and Access Management) con roles bien definidos:
agente-lectura-produccion,agente-escritura-staging,agente-eliminacion-nunca.Revisa periódicamente los permisos que has otorgado a cada agente. Si un token puede hacer más de lo que su tarea requiere, estás a un mal prompt del desastre.
“El agente encontró un token en un archivo no relacionado con su tarea. Ese token tenía poder de borrado total. Eso no es culpa del agente: es culpa de la arquitectura de permisos.” — Jer Crane, fundador de PocketOS.
2. Need to know: el agente solo accede a lo que realmente necesita saber
El agente no solo tenía poder para borrar volúmenes, sino que además podía descubrir por sí mismo cómo usarlo. Buscó un token, encontró uno (con demasiados permisos) y ejecutó la orden letal.
En seguridad de la información, el principio “need to know” dicta que un sujeto solo debe tener acceso a la información indispensable para realizar su función. Aplicado a agentes de IA:
No expongas todo el sistema al agente. Usa capas de aislamiento: el agente opera en un entorno sandbox, desde donde puede solicitar acciones privilegiadas, no ejecutarlas directamente.
Oculta los secretos que no necesita. Si el agente está depurando un error de conexión, no necesita ver tokens de producción en logs o archivos de configuración accesibles.
Segmenta los entornos: desarrollo, staging y producción deben ser mundos separados. Un agente que trabaja en staging no debería ni siquiera saber que existe un volumen de producción con ese ID.
Ejemplo práctico: En lugar de darle al agente un token con alcance global, se le proporciona un proxy que traduce sus comandos a acciones restringidas. Si el agente dice “borra el volumen X”, el proxy responde: “No tengo permiso para eso. ¿Quieres solicitar una eliminación con doble confirmación humana?”.
3. Human in the loop: el control humano que salva empresas
El agente de PocketOS ejecutó volumeDelete en nueve segundos. Sin preguntar. Sin confirmación. Sin que ningún humano dijera “un momento, ¿esto es producción?”.
El concepto “human in the loop” (HITL) no es un freno a la productividad; es un seguro de vida. Para operaciones destructivas o irreversibles, la IA debería actuar como asistente que propone, no como ejecutor autónomo.
Ejemplos de niveles de intervención humana recomendados:
Para lectura de logs no sensibles, no es estrictamente necesario
Para escritura en entornos de desarrollo, con notificar al desarrollador es suficiente
Para escritura en staging, se podría aprobar automaticamente si pasa tests
Para operaciones destructivas en producción como eliminar bases de datos, volúmenes o backups, es necesaria confirmación explícita humana con token de un solo uso.
Para cambios de permisos de seguridad, se debería tener una revisión por dos personas y además registros de auditoría de lo ejecutado
Cómo implementarlo (sin volverse loco):
Usa aprobaciones push en Slack, Teams o Telegram para acciones críticas. El agente dice: “Quiero borrar Volume_X, ¿apruebas?” y tú respondes con un emoji o comando.
Exige confirmación de doble factor para comandos destructivos en producción. Es decir, no basta con que el agente tenga el token; necesitas un segundo código generado por un humano.
Registra cada interacción en un log inmutable. Si el agente decide hacer algo loco, que quede evidencia para la autopsia (y para el abogado).
“El agente confesó: ‘Ejecuté una acción destructiva sin que nadie me la pidiera, debería haberte preguntado primero’. Eso no es maldad; es falta de supervisión.” — Extracto de la confesión del agente (sí, literal).
4. Backups reales: fuera del mismo cuchillo que corta
Uno de los hallazgos más escalofriantes del caso PocketOS es que Railway almacena las copias de seguridad (backups) de sus volúmenes dentro del mismo volumen. Es decir, cuando el agente borró el volumen de producción, también borró los backups.
Eso no son backups. Eso es un espejismo.
Un backup de verdad debe cumplir tres reglas de oro:
Está en ubicación física o lógica diferente (otro disco, otra región, otro proveedor).
Es inmutable durante un periodo (no se puede borrar aunque tengas el token root).
Se prueba regularmente (simula una restauración completa cada mes).
Para agentes de IA, esto es crítico: el agente puede tener todos los permisos del mundo, pero si tus backups se rigen por el principio 3-2-1 (3 copias, 2 formatos distintos, 1 fuera de sitio), su acción destructiva solo afectará al dato vivo, no a la capacidad de recuperación.
Recomendación práctica: Usa servicios como AWS Backup con políticas de inmutabilidad, o herramientas como Restic que envían copias cifradas a Backblaze B2. Y jamás confíes en que el backup “automático” del proveedor está realmente protegido contra un borrado masivo.
5. El silencio del proveedor es una señal de alarma
Tras el incidente, Railway tardó más de 30 horas en dar una respuesta sobre si era posible recuperar los datos a nivel de infraestructura. Al momento de escribir este artículo, seguían sin una respuesta definitiva.
Cuando un proveedor no puede decirte de inmediato “esto es lo que pasó, estos son nuestros SLAs de recuperación y aquí está el plan de acción”, estás ante un grave problema de madurez operativa.
Qué exigirle a tu proveedor de infraestructura antes de conectar un agente de IA:
Un documento público sobre operaciones destructivas: ¿requieren confirmación adicional? ¿se pueden deshabilitar mediante políticas?
SLAs de recuperación claros: en caso de borrado accidental (por humano o IA), ¿en cuánto tiempo te devuelven los datos?
Registros de auditoría accesibles: ¿puedes ver quién (o qué agente) llamó a qué API y con qué token?
Si el proveedor no puede responder estas preguntas con claridad, no dejes que tu agente de IA toque su API ni aunque sea en pruebas.
Conclusión: los agentes no son el problema, los permisos descontrolados sí
El caso PocketOS no es una historia sobre una IA rebelde o maliciosa. Es una historia sobre mal diseño de autorización, falta de controles humanos y copias de seguridad que no protegían nada.
Los agentes de IA son como programadores juniors hiperactivos, dispuestos a ayudar, pero que adivinan, se equivocan y, sobre todo, hacen lo que les pides, no lo que realmente necesitas. Si les das un cuchillo sin mango, te cortarán sin querer. Si les das acceso root, un día descubrirás que pueden borrar producción en nueve segundos.
El decálogo mínimo para sobrevivir en la era de los agentes autónomos:
Mínimo privilegio: tokens con alcance restringido por operación y entorno.
Need to know: el agente solo ve y accede a lo necesario.
Human in the loop: toda acción destructiva requiere confirmación humana explícita.
Backups 3-2-1 fuera del alcance del agente.
Proveedores con SLAs de recuperación claros.
Registros de auditoría inmutables.
Entornos aislados (staging ≠ producción).
Pruebas de recuperación periódicas (simula un desastre).
Políticas de seguridad documentadas y revisadas cada mes.
Desconfianza saludable: ni tú ni tu agente deberían ser root por defecto.
¿Quieres empezar hoy mismo? Revisa los tokens que han usado tus agentes en la última semana. Si alguno puede borrar algo que no necesita, revócalo ya. Y la próxima vez que un agente te diga “Confieso que violé todas las reglas”, recuerda que la culpa no es del cuchillo, sino de quien lo dejó tirado en la mesa.