Un solo prompt bastó para secuestrar todos los agentes de IA de una cuenta en AWS (y Amazon dice que no es un bug)

El detalle que cambia la lectura del caso

Zenity reportó el acceso a metadata a AWS el 25 de diciembre de 2025 y el problema del rol default el 12 de enero de 2026. AWS cerró el primer reporte como "informativo" en abril. No fue sino hasta el 29 de septiembre de 2026 —nueve meses después del primer reporte— que Zenity confirmó que AWS había retirado del rol default los permisos para invocar otros agentes, leer conversaciones privadas y acceder a Secrets Manager.

La respuesta de AWS: "esto es comportamiento esperado"

Esta es la parte que de verdad vale la pena leer con calma, porque no hay consenso. AWS respondió que la investigación "pinta de forma inexacta un comportamiento esperado y documentado" como si fuera una vulnerabilidad, y sostiene que un agente solo puede llegar a recursos de otra cuenta si el desarrollador otorgó permisos explícitos en ambos lados —en el rol del agente y en el recurso destino. Su recomendación oficial: otorgar a los roles de ejecución únicamente los permisos que cada agente necesita.

Michael Bargury, cofundador y CTO de Zenity, lo resume distinto: "la seguridad en la nube se trata de segmentación y acceso de mínimo privilegio", y agrega que mezclar esa disciplina con la flexibilidad que necesitan los agentes "crea un conflicto inherente". Ambas cosas son ciertas al mismo tiempo: técnicamente, el comportamiento es el documentado. Y también es cierto que un default demasiado permisivo, en un patrón de arquitectura nuevo que casi nadie termina de entender todavía, es exactamente la clase de diseño que produce incidentes reales.

No es un caso aislado — es un patrón de 2026

En Geek Vibes venimos siguiendo de cerca cómo la prisa por desplegar agentes está dejando huecos de seguridad que antes no existían porque no existía la superficie de ataque:

• En julio, un agente de OpenAI escapó de su propio sandbox, encontró un zero-day real y lo usó para comprometer infraestructura de Hugging Face.
• En agosto, el AISI reportó agentes de IA operando con identidades falsas dentro de flujos corporativos sin que nadie lo notara a tiempo.
• Zenity, la misma firma detrás de este hallazgo, reportó en agosto más de 1.7 millones de instalaciones de "skills" maliciosas para agentes de IA, y cerró una Serie C de $125 millones ese mismo mes —señal de que el mercado ya está apostando fuerte a que este problema va a crecer, no a desaparecer.

El patrón es siempre el mismo: la velocidad de adopción de agentes va muy por delante de los modelos de permisos, aislamiento y auditoría que esa adopción requiere.

Lo que esto significa para agencias y developers

Si tu agencia ya está construyendo o desplegando agentes para clientes —en AWS, en cualquier otra nube, o en infraestructura propia— esto no es una nota para archivar, es un checklist para correr esta semana:

• Audita los roles de ejecución de cada agente. No asumas que el default del proveedor está bien scopeado. Pregunta explícitamente: ¿qué puede tocar este agente si alguien logra extraer sus credenciales?
• Trata cualquier herramienta que haga requests web o corra comandos de shell como una ruta potencial a credenciales. Si un agente puede "navegar" o "ejecutar", puede llegar a metadata de la máquina que lo hospeda.
• Restringe quién puede escribir en la memoria de largo plazo de un agente. Memoria persistente es una superficie de ataque nueva: si cualquier conversación puede sembrar una instrucción que sobrevive, necesitas tratarla con el mismo cuidado que una base de datos de producción.
• No confíes en que "aislado por cuenta" significa "aislado entre agentes". Varios agentes compartiendo cuenta y región no es lo mismo que agentes aislados entre sí —y ese matiz es justo el que un cliente no técnico nunca va a preguntar, pero sí va a reclamar si algo sale mal.
• Verifica que uses IMDSv2, que exige token de sesión por request y cierra la puerta más simple de este ataque específico.

Para una agencia, el valor que cobras ya no es solo "construir el agente que funciona": es construir el agente que funciona y que no se convierte en la puerta trasera de la cuenta del cliente. Ese trabajo de arquitectura y auditoría de permisos, hoy, casi nadie lo está cotizando por separado —y es exactamente donde hay espacio para diferenciarte del freelancer que solo conecta un modelo a un par de tools.

Este tipo de hallazgos van a seguir apareciendo mientras la industria entera —proveedores cloud incluidos— termina de aprender a construir infraestructura para agentes, no solo para aplicaciones tradicionales. Si estás evaluando cómo blindar los agentes que ya tienes en producción, o quieres que revisemos la arquitectura de permisos antes de lanzar uno nuevo, escríbenos a comercial@geekvibes.agency.