Un solo prompt enviado a un agente de IA orientado al público podría haber expuesto a cada agente de Amazon Bedrock AgentCore en la misma cuenta y región de AWS, según una nueva investigación de Zenity Labs.

La cadena de ataque, denominada AgentCorruption, permitió a los investigadores acceder a chats privados, código fuente, memorias a largo plazo, claves API, tokens OAuth y secretos almacenados en AWS Secrets Manager.

Amazon Bedrock AgentCore es un servicio gestionado para crear y ejecutar agentes de IA. Zenity descubrió que a un agente con una herramienta capaz de realizar solicitudes web se le podía ordenar contactar con el punto final de metadatos local en 169.254.169.254.

Este servicio proporciona credenciales temporales de AWS a las cargas de trabajo en la nube. Debido a que la solicitud provenía del interior de la microVM Firecracker del agente, el servicio de metadatos devolvió las credenciales vinculadas a su rol de ejecución.

Esto creó una ruta de falsificación de solicitud del lado del servidor (SSRF) impulsada por una inyección de prompts. El agente expuesto no necesitaba un error de software en su página de chat; solo necesitaba seguir la solicitud del usuario y utilizar una herramienta web o de shell permitida.

El caso muestra cómo las funciones normales de un agente pueden volverse peligrosas cuando coinciden prompts no confiables, acceso a la red y permisos de nube. Riesgos similares han aparecido en las filtraciones de datos de OpenClaw y en el incidente del agente de codificación Amazon Q.

Las credenciales robadas tenían un amplio alcance porque Zenity afirmó que el rol de IAM predeterminado no estaba limitado a un solo agente. Los investigadores utilizaron DescribeLogGroups para encontrar IDs de agentes, extrajeron imágenes de contenedores de Amazon ECR, invocaron agentes internos y leyeron eventos de sesión. Permisos que incluyen bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents y bedrock-agentcore:CreateEvent también permitieron el acceso a los chats y la creación de memorias falsas.

El acceso a la memoria hizo que el riesgo persistiera más allá de una sola sesión. Un atacante podría añadir instrucciones ocultas que cambiaran los objetivos de un agente durante conversaciones posteriores.

Zenity también encontró acceso a bedrock-agentcore:GetResourceApiKey y secretsmanager:GetSecretValue, lo que podría revelar credenciales destinadas a servicios conectados. Por lo tanto, un solo agente expuesto podría convertirse en una vía de entrada a otras herramientas de negocio y datos sensibles de la nube.

Zenity informó sobre el acceso a los metadatos a AWS el 25 de diciembre de 2025, y sobre los amplios permisos de rol el 12 de enero de 2026. AWS trasladó los nuevos despliegues a IMDSv2 en febrero y más tarde lo hizo obligatorio.

Para el 29 de septiembre, Zenity confirmó que AWS había eliminado los permisos que permitían llamadas amplias a los agentes, acceso a chats y acceso a Secrets Manager. Los investigadores afirman que los problemas reportados ya están solucionados.

AWS cuestiona que la descripción de los hallazgos sea una vulnerabilidad. La compañía afirma que el acceso a las credenciales del propio rol de ejecución de un agente a través del servicio de metadatos es esperado y está documentado. AWS también indica que el acceso entre cuentas requiere permisos claros tanto en el rol de ejecución como en el recurso objetivo. Su guía de credenciales advierte que cualquier código o actor dentro de la microVM puede llamar al punto final de metadatos.

Tú y tu equipo de seguridad no deberían confiar solo en los cambios de la plataforma. AWS recomienda utilizar roles de producción personalizados que contengan únicamente las acciones y los nombres de recursos que cada agente necesite.

Deberías bloquear los permisos amplios de comodín, validar la entrada de los prompts, limitar el acceso de red saliente, separar los agentes públicos de los internos y monitorizar CloudTrail y CloudWatch en busca de llamadas inusuales. AWS también aconseja utilizar los controles de AgentCore Gateway y asegurarse de que quienes realizan las llamadas no puedan saltárselos accediendo directamente a un runtime.

La lección clave es que debes tratar a un agente de IA como una carga de trabajo de la nube, no solo como un chatbot. Cada herramienta, secreto, ruta de red y rol expande lo que un prompt malicioso puede alcanzar, por lo que debes realizar revisiones de acceso antes del despliegue y después de cada cambio.