Lo que hicieron los investigadores

Zenity Labs publicó el 8 de octubre la primera parte de una cadena que llama AgentCorruption. El objetivo es Amazon Bedrock AgentCore Runtime, el servicio gestionado que las empresas usan para ejecutar agentes de IA en AWS.

Los investigadores desplegaron un agente de muestra construido con Strands, el SDK de agentes de código abierto de AWS, usando la herramienta http_request incorporada. Luego pidieron al agente que consultara el punto final de metadatos de la instancia en 169.254.169.254 y reenviara la respuesta a un receptor bajo su control. Lo hizo. Reprodujeron el mismo resultado con la herramienta shell del SDK.

La conclusión de Zenity apunta a la plataforma y no a la herramienta: “La microVM no restringía el tráfico hacia el servicio de metadatos”, y “El fallo de aislamiento está en el nivel de la plataforma, no en el de la herramienta”.

Lo que entregaron los metadatos

El servicio de metadatos devolvió el nombre del rol de ejecución del agente y sus credenciales temporales de STS. Los investigadores confirmaron que esas credenciales funcionaban por completo fuera de AgentCore: aws sts get-caller-identity devolvía el rol asumido por el agente.

A partir de ahí los metadatos siguieron dando. Los datos de usuario revelaron la URI de la imagen de contenedor del agente en Elastic Container Registry. Las etiquetas de instancia expusieron material de certificado y clave mTLS y una URL de S3 prefirmada.

Una persona dibujando diagramas de flujo en una pizarra de oficina
Zenity dice que el fallo de aislamiento está en la plataforma, no en la herramienta. Fotografía ilustrativa. Christina Morillo · pexels · Pexels License

Por qué un agente alcanzaba a todos

El rol de ejecución es la parte con la que Zenity es más dura: “El rol que AgentCore adjunta por defecto al tiempo de ejecución del agente tiene privilegios excesivos”. Llevaba permisos de lectura de ECR con comodines, y AgentCore nombra los repositorios de imágenes de forma predecible, como bedrock-agentcore-<nombre_del_agente>.

Esa combinación convirtió a un agente comprometido en un directorio de todos los demás agentes de la misma cuenta y región. En palabras de los investigadores, “ejecutar nuestra herramienta automatizada sobre todos los agentes descubiertos nos dio todo el código fuente de todos los agentes de la región en unos segundos”. Zenity dice que las próximas entradas cubrirán capacidades de lectura, escritura y borrado en AgentCore y en otros servicios de AWS de la región.

Qué cambió AWS y qué dice ahora

La cronología de Zenity no es coherente consigo misma: el texto dice que los hallazgos llegaron a AWS el 17 de diciembre de 2025, mientras que su propia tabla fecha la divulgación del fallo de IMDS el 25 de diciembre de 2025. Las fechas posteriores son más claras. El 14 de febrero de 2026 AgentCore pasó a usar solo IMDSv2, de modo que los agentes recién desplegados arrancan con él. El 12 de abril de 2026 AWS respondió y cerró el informe como “informativo”. No se asignó ningún CVE.

La posición de AWS, en una declaración recogida por The Decoder el 9 de octubre, es que la investigación “presenta de forma inexacta un comportamiento esperado y documentado como si fuera una vulnerabilidad”. AWS dijo que un agente solo puede alcanzar recursos de otra cuenta cuando un desarrollador ha concedido permisos explícitos tanto en el rol de ejecución como en el recurso de destino, y remite a su documentación de permisos del tiempo de ejecución y a roles de ejecución de mínimo privilegio. The Decoder informa de que AWS también estrechó después el rol de ejecución por defecto, quitando permisos para invocar a otros agentes, leer conversaciones privadas y recuperar credenciales de Secrets Manager.

Una fila de puertas de armario idénticas con volantes y llaves puestas en las cerraduras
El rol por defecto podía listar y descargar todas las imágenes de agentes de la región. Fotografía ilustrativa. cottonbro studio · pexels · Pexels License

La discusión de fondo

Ambas partes coinciden en la mecánica y discrepan sobre de quién era la tarea. El argumento de AWS es que un rol por defecto es un punto de partida y la documentación dice que hay que estrecharlo. El de Zenity es que un tiempo de ejecución gestionado cuyo entorno aislado no bloquea el servicio de metadatos, y cuyo rol por defecto puede enumerar a sus vecinos, entrega un valor por defecto que la mayoría de los clientes nunca cambiará.

Es la misma discusión que tuvo el sector de la nube con los buckets públicos de S3, y se resolvió cambiando el valor por defecto, no la documentación.

Qué vigilar

Zenity ha dicho que esta es la primera entrega. Las siguientes son las que importan: el acceso inicial a credenciales es un hallazgo serio, pero lo que llamó la atención es el movimiento lateral entre todos los agentes de una región, y esa parte aún está por publicarse en detalle.

Para quien ejecute agentes en AgentCore hoy, la medida práctica no está en disputa. El proveedor y sus críticos dicen lo mismo: no salir a producción con el rol de ejecución por defecto.