Un prompt, un agente, toda una cuenta de AWS: dentro de AgentCorruption en Amazon Bedrock AgentCore

El 8 de octubre de 2026, Zenity Labs reveló AgentCorruption: una cadena de fallos en Amazon Bedrock AgentCore, la plataforma gestionada de AWS para implementar y ejecutar agentes de IA, que permitía que un solo prompt en lenguaje natural dirigido a un agente expuesto públicamente tomara el control de todos los agentes de AgentCore en la misma cuenta y región de AWS. La investigación se publicó junto con una charla en SecTor 2026 en Toronto, donde el director de investigación de seguridad de Zenity, Tamir Ishay Sharbat, lo presentó (Dark Reading, 8 de octubre de 2026). El propio informe de Zenity, atribuido a Sharbat, Lana Salameh, Dmitry Lozovoy y João Donato, comienza con el mecanismo: un agente de AgentCore que tenga cualquier herramienta capaz de realizar una solicitud saliente puede ser dirigido para que llame al AWS Instance Metadata Service (IMDS) en la dirección de enlace local 169.254.169.254, que devuelve credenciales temporales para el propio rol de ejecución del agente. Zenity afirma que exportó esas credenciales a su propia máquina y confirmó que funcionaban desde allí. No se asignó ningún identificador CVE.

El archivo lo registra como una vulnerabilidad — algo encontrado, no necesariamente explotado — con alta gravedad, confianza A, ningún daño real registrado y participación de IA confirmada. Las partes discrepan sobre el enfoque aunque coinciden en el comportamiento: AWS dijo a Dark Reading que la investigación "presenta de forma inexacta un comportamiento esperado y documentado como una vulnerabilidad".

Lo que la cadena realmente era

AgentCore empaqueta cada agente como un contenedor y lo ejecuta, por sesión, en una Firecracker MicroVM. La primera publicación de Zenity en la serie reproduce todo el punto de apoyo con una solicitud en lenguaje sencillo a un agente de prueba construido con Strands SDK, el framework de agentes de código abierto de AWS, que incluye una herramienta de solicitud HTTP integrada y una herramienta de shell. La microVM no restringió el tráfico al servicio de metadatos, por lo que la solicitud provino del interior de la instancia e IMDS respondió. Los investigadores recorrieron los endpoints después de eso: el nombre del rol de IAM, las credenciales temporales de STS en sí, el endpoint de datos de usuario — que devolvió el ID de cuenta, los ARN completos, la URL de tiempo de ejecución y la del agente Amazon Elastic Container Registry (ECR) URI de imagen — y etiquetas de instancia que incluyen una cadena de certificados mTLS, una clave privada y una URL prefirmada al almacenamiento interno. Zenity dice que el mismo resultado se obtuvo a través de la herramienta de shell, porque el fallo de aislamiento se encuentra a nivel de plataforma en lugar de en una herramienta en particular.

Dos detalles de esa secuencia pasan fácilmente desapercibidos. Las credenciales no se limitaban al sandbox: Zenity las exportó fuera de AgentCore y ejecutó una llamada de identidad de AWS que devolvió como resultado el rol asumido del agente. Y el rol robado podía extraer la imagen del contenedor, que es como se pudo leer el código fuente de los agentes: la publicación de Zenity señala que las imágenes suelen llevar claves embebidas, tokens sobrantes y configuración que nunca debió haberse incluido, y que una imagen extraída es un mapa de la lógica de negocio subyacente.

El rol predeterminado es donde un punto de apoyo se convirtió en una cuenta

El segundo fallo, reportado por separado, es que el rol de ejecución que AgentCore asignaba a los agentes por defecto no estaba limitado a un solo agente. Zenity describe permisos que alcanzan todos los recursos de AgentCore en la cuenta y la región, incluidos bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, bedrock-agentcore:CreateEvent, bedrock-agentcore:DeleteEvent y, en el extremo de las credenciales de la cadena, bedrock-agentcore:GetResourceApiKey y secretsmanager:GetSecretValue.

La enumerabilidad convirtió esos comodines en una lista de objetivos. Zenity utilizó el permiso logs:DescribeLogGroups del rol, porque AgentCore nombra el grupo de logs de CloudWatch de cada agente /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME}, y derivó los ID de agente a partir de esos nombres de grupos de logs. Los nombres de repositorios de ECR seguían una convención que los investigadores observaron —bedrock-agentcore-<agent_name>—, por lo que se podía extraer la imagen de cada agente de la región. Los recursos de memoria se encontraron de la misma manera, a partir del patrón de grupo de logs /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID}, y los permisos ListActors, ListSessions y ListEvents del rol produjeron los identificadores de actor y de sesión necesarios para leer el contenido de las conversaciones.

El informe de Zenity ofrece una demostración concreta de movimiento lateral: entrar a través de un agente expuesto públicamente, descubrir las herramientas de un billing_agent en la misma región, detectar un archivo llamado billing.json y exfiltrarlo mediante una herramienta de lectura de archivos. El comunicado de prensa describe el mismo escenario en términos generales: un atacante que entra a través de un agente de atención al cliente expuesto a internet podría desplazarse a un agente financiero interno desplegado en la misma región, invocarlo y acceder a sus datos, herramientas, credenciales relacionadas y conversaciones privadas.

La memoria fue la parte que sobrevivió al prompt

AgentCore Memory mantiene la conversación en sí como memoria a corto plazo y almacena los registros extraídos como memoria a largo plazo, usando estrategias denominadas SEMANTIC, USER_PREFERENCE, SUMMARIZATION y EPISODIC. Zenity usó CreateEvent para escribir eventos de conversación en los recursos de memoria de otros agentes. Su publicación es cuidadosa sobre lo que esa primitiva puede y no puede hacer: CreateEvent no permite que quien llama elija un espacio de nombres a largo plazo ni sobrescriba un registro directamente; las estrategias configuradas de la memoria de destino deciden qué se extrae y dónde queda. Zenity también describe DeleteEvent usado para eliminar eventos de resultados de herramientas de modo que un agente saque una conclusión errónea a partir de datos faltantes, y para borrar rastros eliminando el evento que plantó un recuerdo.

Lo que produjo la primitiva de escritura fue persistencia. La demostración de Zenity implantó una solicitud para que el agente obtuviera una página controlada por los investigadores antes de responder, y siguiera el contenido de esa página: un endpoint de mando y control cuyas instrucciones podían cambiarse sin implantar otro recuerdo. Ese mismo canal extraía después el contenido de la conversación: el informe describe al agente enviando los mensajes del usuario y sus propias respuestas a un endpoint de recolección, y afirma que los permisos de memoria del rol se extendían por toda la cuenta y la región, y no solo al agente comprometido. Un video publicado junto con la investigación muestra a un usuario continuando una conversación mientras ese contenido llega al servidor de los investigadores.

Credenciales más allá de AWS

La última publicación de la serie cierra el círculo en torno a las herramientas conectadas. AgentCore Identity y Outbound Auth almacenan las credenciales de las herramientas como secretos en AWS Secrets Manager, bajo nombres construidos a partir del nombre de un proveedor y un patrón fijo como bedrock-agentcore-identity!default/apikey/{provider_name}. Zenity recuperó nombres de proveedores extrayéndolos del código fuente del agente que ya había descargado de ECR, y recuperó otros mediante fuerza bruta: informa que el sufijo predeterminado de cinco caracteres se genera del lado del cliente a partir de dígitos y letras minúsculas, lo que da 2 x (10+26)^5 = 120,932,352 combinaciones entre los dos tipos de proveedor. A la tasa de solicitudes que podía sostener contra Secrets Manager, Zenity afirma que una enumeración completa tarda varias horas —más de lo que duran las credenciales de STS—, así que construyó un bucle que volvía a consultar el endpoint IMDS del agente para obtener credenciales nuevas a medida que las antiguas caducaban. Zenity añade que las variables de entorno eran legibles a través del endpoint de user-data de los metadatos, con cada nombre precedido por CONTAINER_ENV_, incluida la clave que un agente usa para autenticarse ante su proveedor de modelos, y que invocar cada agente descubierto con un prompt adecuado cosechaba esos valores a escala.

Establecido, y en disputa por una formalidad técnica.

Lo que está establecido es acotado y específico. Los agentes de AgentCore podían alcanzar IMDS y recibir las credenciales temporales de su propio rol de ejecución; AWS no lo discute y lo describe en su declaración como "documentado y esperado". El rol de ejecución predeterminado incluía permisos con alcance a la cuenta y la región en lugar de a un solo agente; AWS lo ha cambiado desde entonces, y Zenity afirma que sus propias pruebas confirmaron la reducción. La investigación es una demostración, no una campaña observada: Sharbat declaró a Dark Reading que Zenity no había visto ninguna evidencia de que la vulnerabilidad se explotara en la naturaleza antes de la corrección, y atribuyó esto en parte a la dificultad de identificar a las organizaciones que ejecutan agentes en AgentCore, y añadió que estaba "100 % seguro de que hay formas de hacerlo".

Lo que se disputa es si algo de esto debería llamarse vulnerabilidad. La declaración de AWS, tal como se dio a Dark Reading y The Next Web, dice: «AWS tiene conocimiento de la investigación publicada sobre Amazon Bedrock AgentCore, que presenta de forma inexacta un comportamiento esperado y documentado como una vulnerabilidad. Un agente solo puede acceder a recursos de otra cuenta de AWS si el desarrollador otorga permisos explícitos tanto en el rol de ejecución del agente como en el recurso de destino». La declaración de AWS reproducida en las propias publicaciones de Zenity mantiene la esencia de la primera frase —«el comportamiento descrito está documentado y es esperado»— y añade que los clientes deberían otorgar a los roles de ejecución únicamente los permisos que sus agentes necesiten. Dos cosas subyacen al desacuerdo. AWS enmarca el límite en términos de acceso a recursos de otra cuenta de AWS, mientras que el hallazgo de Zenity se refiere a agentes dentro de una sola cuenta y región de AWS; y los roles que describe Zenity provenían de los valores predeterminados de la plataforma, no de un cliente que escribiera una política a mano.

Merece quedar registrada la corrección que The Next Web hizo a su propio artículo, porque muestra que la afirmación fue acotada por alguien distinto de los investigadores. Primero publicó, y después corrigió, un titular que decía que los investigadores tomaron el control de todos los agentes de AgentCore en una región; la versión corregida afirma que la investigación abarcó agentes dentro de una única cuenta y región de AWS, y señala que el titular anterior había presentado la afirmación de los investigadores como un hecho.

La cronología de divulgación

Zenity presentó dos informes en lugar de uno, y recibieron respuestas diferentes. El informe de acceso a IMDS se presentó el 25 de diciembre de 2025; AWS lo cerró el 12 de abril de 2026 como "informativo", señalando que AgentCore solo había usado IMDSv2 desde el 14 de febrero de 2026, y que los agentes recién desplegados se iniciaban de esa manera. Esa revisión es importante para los detalles de esta investigación, porque IMDSv2 requiere un token de sesión en cada solicitud y rompe la solicitud simple no autenticada que los investigadores usaban para obtener credenciales. El segundo informe, sobre el rol predeterminado y su radio de impacto, se presentó el 12 de enero de 2026. AWS le dijo a Zenity el 25 de febrero de 2026 que el equipo estaba trabajando en ello mientras el rol permanecía como estaba; Zenity revisó el rol de nuevo el 22 de junio de 2026 y encontró que sus permisos no habían cambiado. Una revisión final el 29 de septiembre de 2026 encontró que el rol se había reducido sustancialmente, y el comunicado de prensa de Zenity afirma que la eliminación abarcaba invocar otros agentes, leer conversaciones privadas y acceder a secretos en AWS Secrets Manager, y que otros permisos también quedaron significativamente restringidos. Las propias publicaciones de Zenity señalan que AWS desde entonces ha convertido IMDSv2 en el valor predeterminado para los despliegues de AgentCore y que ambas partes colaboraron durante el proceso.

¿Qué no es correcto?

Zenity no ha publicado cuántos agentes u organizaciones se ejecutaron con el rol predeterminado en el período entre el cambio de IMDSv2 de febrero y la restricción de finales de septiembre, y nada en las fuentes citadas indica que se hayan expuesto datos de clientes fuera del propio entorno de los investigadores. El cambio de IMDSv2 se aplica a los agentes desplegados después del 14 de febrero de 2026, según AWS, tal como lo informó Zenity; lo que significa para los agentes desplegados antes de esa fecha no se indica en las fuentes revisadas aquí. El archivo no registra ningún daño real, y las fuentes respaldan esa lectura al describir una demostración y al cuestionar AWS la etiqueta de vulnerabilidad en lugar de informar sobre un incidente propio.

Sharbat declaró a Dark Reading que Zenity está examinando ahora otras plataformas en la nube en busca de problemas similares de acceso a metadatos, y que la empresa todavía no las está nombrando. Su conclusión declarada se refiere a los permisos más que al servicio de metadatos en sí: «Incluso si alguien llega al IMDS, el radio de impacto será mucho menor».

Por qué se conserva este registro

AgentCorruption no es notable porque los endpoints de metadatos son una novedad. Sharbat dirigió la atención del público de SecTor hacia el caso de Capital One de 2019, donde un SSRF alcanzó IMDS y se robaron credenciales, y describió eso como un fallo de mínimo privilegio del mismo tipo. Lo nuevo es el actor que realiza la obtención. La solicitud que produjo una identidad de AWS la hizo un agente de IA haciendo lo que se le pidió, en lenguaje llano, a través de una herramienta que se le dio para que pudiera ser útil — y el agente devolvió la respuesta. Las dos condiciones que convirtieron eso en un problema a nivel de cuenta fueron un endpoint de metadatos que el sandbox no bloqueó y un rol predeterminado más amplio que el agente que lo tenía.

La investigación completa, incluida la serie técnica de cinco partes y el vídeo de demostración, está enlazada desde el comunicado de prensa de Zenity del 8 de octubre de 2026. Este registro es una entrada entre los incidentes de agentes documentados en el archivo de incidentes de IA, donde cada entrada incluye sus propias fuentes, gravedad, grado de confianza y marca de disputa — los campos que permiten distinguir una disputa con un proveedor sobre el encuadre, como ocurre aquí, de un hallazgo de daño en disputa.

Este es un registro, investigado y reportado por otros, y citado aquí con atribución a ellos. Los demás incidentes de agentes documentados, cada uno con sus propias fuentes, su gravedad, su grado de confianza y su marca de disputa, se encuentran en el archivo de incidentes de IA, de modo que un valor predeterminado de la plataforma que convierte un solo prompt en un punto de apoyo para toda la cuenta puede leerse junto a lo que realmente ha ocurrido en otros lugares.