Un solo agente de IA de acceso público en Amazon Bedrock AgentCore bastó para tomar el control de todos los agentes AgentCore de la misma cuenta y región de AWS, según investigadores de Zenity Labs. The Decoder publicó el hallazgo el 8 de octubre.

Amazon Bedrock AgentCore es la plataforma de AWS para correr agentes de IA empresariales con herramientas, memoria y gestión de accesos. La empresa de seguridad Zenity Labs encontró una cadena de vulnerabilidades que llamó "AgentCorruption".

Para explotarla, un atacante solo necesitaba acceso al chat de un agente público. Según los investigadores, un único prompt les permitió controlar todos los agentes AgentCore de la cuenta y la región, y dejó expuestas conversaciones privadas, código fuente y credenciales guardadas. Zenity sostiene que el problema era sistémico y afectaba a agentes con herramientas integradas en varias cuentas de AWS.

El agente entregó sus propias credenciales

Tienda falsa TechHub con mensaje en ruso que ordena al agente consultar la IMDS 169.254.169.254 y enviar la respuesta a un servidor externo

AWS opera un servicio de metadatos de instancia (Instance Metadata Service) en la dirección interna 169.254.169.254, que entrega credenciales temporales para que instancias y cargas de trabajo se autentiquen en AWS. Quien capture esas credenciales puede hacerse pasar por la instancia.

En condiciones normales, un agente de IA no debería poder llegar a ese servicio. Pero AgentCore no tenía el aislamiento adecuado, según el informe técnico de Zenity. Los investigadores armaron un agente de prueba con Strands, un framework de código abierto de AWS que trae una herramienta web. Cuando le pidieron en lenguaje natural que consultara el servicio de metadatos y enviara el resultado a un servidor externo, el agente obedeció.

"El límite del sandbox contra el que se suponía que íbamos a pelear simplemente no estaba", escriben los investigadores.

Un solo mensaje en la ventana de atención al cliente engañó al agente para que mandara sus propias credenciales de AWS a un servidor externo. Las credenciales robadas funcionaron en el computador de los investigadores, fuera de la plataforma, así que ya no necesitaban al agente para seguir con el ataque. El servicio de metadatos también expuso material de certificados y claves de un servicio interno de AWS, y una URL prefirmada de un almacenamiento S3 interno que no pertenecía a la cuenta de los investigadores.

El servicio devolvió las credenciales temporales completas del agente, con claves y token de sesión. Según Zenity, quitar la herramienta web no habría servido, porque la falla estaba en la plataforma. Los investigadores también hicieron el ataque con una herramienta de línea de comandos.

¿Por qué cayó toda la región?

Respuesta del servicio de metadatos en Burp Collaborator con AccessKeyId, SecretAccessKey y token de credenciales temporales de AWS

La toma de control fue posible porque los permisos por defecto de AgentCore no se limitaban al agente que los recibía. Según Zenity, se aplicaban a todos los agentes de la misma cuenta y región, con acceso de lectura, escritura y borrado que permitía operaciones destructivas.

Con esos permisos, los investigadores pudieron listar todos los agentes, descargar sus paquetes de código en segundos e invocar a cada uno. Un script automático bajó las imágenes de contenedor de todos los agentes de la región y copió su código fuente. Esos paquetes suelen traer contraseñas o claves de API olvidadas junto al código, así que la exposición puede ir más allá de los agentes. Un atacante podría, por ejemplo, saltar desde un agente público de atención al cliente a un agente interno de finanzas y acceder a sus datos. Los investigadores también pudieron leer todas las conversaciones privadas entre usuarios y agentes de la región.

En los agentes con memoria de largo plazo activada, podían modificar esa memoria para influir en su comportamiento futuro. Su informe sobre envenenamiento de memoria describe cómo plantaron instrucciones para que los agentes reenviaran las conversaciones futuras a un destino externo. Los usuarios habrían seguido hablando con un agente aparentemente confiable sin notar nada.

AWS recomienda guardar contraseñas y claves de API fuera de los agentes, en almacenamiento seguro. Los permisos por defecto de AgentCore anulaban esa protección. Según el informe de Zenity sobre robo de credenciales, esos permisos dejaban que los agentes accedieran a las credenciales guardadas, incluidas claves de servicios fuera de AWS.

¿Qué corrigió AWS?

Zenity dice que reportó los hallazgos a AWS el 25 de diciembre de 2025. Después de eso, AWS dejó IMDSv2 como opción por defecto en los nuevos despliegues de AgentCore. IMDSv2 es una versión más segura del servicio de metadatos que el ataque de Zenity usó como puerta de entrada. Zenity vende además una plataforma de seguridad para agentes de IA, así que tiene un interés comercial en reportar vulnerabilidades de este tipo.

Según la versión actualizada de Zenity, AWS también cambió el rol de ejecución por defecto de AgentCore alrededor de agosto. El rol nuevo ya no permite que los agentes invoquen a otros agentes, lean conversaciones privadas ni saquen credenciales de AWS Secrets Manager. AWS restringió bastante otros permisos, aunque los investigadores siguen recomendando que las empresas creen roles propios con accesos más acotados.

El CTO de Zenity, Michael Bargury, ve un choque entre la seguridad en la nube y la flexibilidad que los agentes necesitan para trabajar.

"La seguridad en la nube se trata de segmentación y de acceso con el mínimo privilegio. Pero los agentes de IA necesitan libertad creativa para ser útiles", dijo.

Toda empresa que corre agentes en la nube enfrenta esa tensión, sobre todo cuando agentes públicos e internos comparten un mismo entorno. En ese esquema, una sola vulnerabilidad puede romper los límites de seguridad de todo el sistema.

Otros ataques con el mismo patrón

Los hallazgos en AgentCore siguen un patrón que Zenity ya documentó en otros casos, donde una entrada de apariencia inofensiva pone a un agente en contra de su propia organización. En su investigación AgentFlayer, ataques sin clic hicieron que Salesforce Einstein, Copilot Studio y Cursor desviaran datos de clientes o filtraran credenciales. Con AgentForger, bastó un enlace de ChatGPT manipulado para crear un agente autónomo en Workspace Agents de OpenAI con los requisitos de aprobación desactivados.

OpenAI corrigió su vulnerabilidad en cuatro días. Los permisos por defecto demasiado amplios de AgentCore siguieron vigentes durante meses después del reporte de Zenity. AWS ya abrió AgentCore a todas las empresas, y Amazon dice que entre sus usuarios están Sony y Ericsson.

La investigación sobre memoria de agentes muestra debilidades parecidas. Google DeepMind incluye la manipulación de la memoria de largo plazo como una clase de ataque aparte en su taxonomía de "trampas para agentes de IA", y encontró que unos pocos documentos envenenados en una base de conocimiento bastan para dirigir las respuestas. En el estudio de red teaming "Agents of Chaos", los investigadores controlaron a distancia un agente OpenClaw mediante un documento editable desde afuera que estaba enlazado en su archivo de memoria, mientras otro agente entregó datos bancarios sin censurar.

El CEO de OpenAI, Sam Altman, ha dicho que los agentes deberían recibir solo el acceso mínimo que necesitan. Según Zenity, el rol por defecto de AgentCore violaba ese principio.