AgentCorruption: un prompt, un rol IAM por defecto y la toma de control de los agentes de una cuenta AWS AgentCore

¿Qué es esto?

El 8 de octubre de 2026, Zenity Labs (autores: Tamir Ishay Sharbat y Lana Salameh) publicó «AgentCorruption», una serie de investigaciones sobre Amazon Bedrock AgentCore, la plataforma gestionada de AWS para desplegar agentes de IA. El trabajo también se presentó en SecTor 2026 en Toronto, y Dark Reading y The Next Web lo cubrieron esa misma semana.

La afirmación central es que un único prompt enviado a un agente expuesto públicamente podía conducir a acceso sobre otros agentes de la misma cuenta y región de AWS. Dos matices para calibrar: la investigación abarcó una cuenta y una región, y AWS discute que se trate de una vulnerabilidad, al considerar el comportamiento documentado y esperado. No se asignó ningún CVE.

Cómo funciona

Zenity describe una cadena de tres debilidades, cada una corriente por separado.

Primero, el acceso inicial. Los agentes se ejecutan en microVM Firecracker y, según Zenity, el aislamiento de red no impedía que una herramienta del agente que realiza solicitudes HTTP alcanzara el servicio de metadatos de instancia (IMDS). Así, a un agente con herramienta de peticiones web o shell se le podía pedir, en lenguaje natural, que devolviera sus propias credenciales temporales. Es un patrón de falsificación de solicitudes del lado del servidor (SSRF) aplicado a un agente: el modelo, dirigido por entrada no confiable, actúa como «falsificador».

Segundo, un rol por defecto demasiado amplio. Zenity indica que el rol de ejecución por defecto no estaba acotado a un solo agente, sino que cubría recursos de AgentCore de toda la cuenta y región. Con esas credenciales, los investigadores pudieron enumerar agentes (mediante el listado de grupos de logs), descargar imágenes de contenedor, invocar otros agentes, leer eventos de conversación de distintos usuarios y sesiones, y obtener claves de API y valores de Secrets Manager que debían quedar fuera del alcance del agente.

Tercero, la persistencia mediante la memoria. Donde la memoria a largo plazo estaba habilitada, el permiso para crear eventos de memoria permitía insertar un evento falso que alteraba de forma persistente el comportamiento del agente entre sesiones.

Nada de esto requirió un jailbreak en el sentido clásico: el prompt solo necesitaba que el agente usara una herramienta que ya tenía.

Por qué importa

El caso ilustra un patrón recurrente en las plataformas de agentes: las herramientas se ejecutan con la identidad cloud del agente, por lo que cualquier vía de inyección de prompts se convierte en una vía hacia credenciales cloud. Si la identidad es compartida o excesiva, un agente orientado al cliente comprometido expone a los agentes internos alojados junto a él. Zenity plantea tratar a los agentes como posibles puntos de entrada.

La cronología de divulgación es instructiva (fechas según Zenity): reportes el 25 de diciembre de 2025 y el 12 de enero de 2026; solo IMDSv2 para agentes recién desplegados desde el 14 de febrero de 2026; primer reporte cerrado como «informativo» el 12 de abril de 2026; rol por defecto sin cambios el 22 de junio de 2026; y, el 29 de septiembre de 2026, Zenity observó que se habían retirado del rol por defecto los permisos de invocación entre agentes, lectura de conversaciones y acceso a Secrets Manager. AWS no lo ha descrito como un parche, por lo que es una observación de Zenity. Según Dark Reading, Zenity no vio evidencia de explotación activa.

Defensas

• Mínimo privilegio por agente. Asigne a cada agente su propio rol de ejecución limitado a los recursos necesarios; no dependa del rol por defecto. Es también la recomendación de AWS.
• Exigir IMDSv2 y restringir el acceso a metadatos. Los agentes nuevos usan solo IMDSv2, pero audite despliegues anteriores. Cuando sea posible, bloquee o filtre el acceso a 169.254.169.254 desde las herramientas de los agentes.
• Acotar las herramientas HTTP y shell. Use listas de destinos permitidos para las herramientas de peticiones web y evite dar un shell genérico a agentes expuestos públicamente.
• Separar zonas de confianza. No aloje agentes de cara al cliente e internos en el mismo límite de cuenta y rol.
• Proteger las escrituras en memoria. Restrinja quién y qué puede crear eventos de memoria y revise las memorias almacenadas en busca de contenido con forma de instrucción.
• Monitorizar. Alerte ante el uso de credenciales de rol desde IP inesperadas y ante invocaciones entre agentes inusuales.

Estado

Elemento	Detalle
Componente	Amazon Bedrock AgentCore (runtime, rol de ejecución por defecto, memoria)
Publicación	8 de octubre de 2026 (Zenity Labs); Dark Reading actualizado el 9 de octubre con la respuesta de AWS
CVE	Ninguno asignado
IMDSv2	Obligatorio para agentes recién desplegados desde el 14 de febrero de 2026 (según Zenity y AWS)
Rol por defecto	Reducido, según lo observado por Zenity el 29 de septiembre de 2026; AWS considera el comportamiento original documentado y esperado
Explotación activa	Ninguna reportada por Zenity