AgentCorruption AWS la investigación mostró cómo una Amazonas agente de Bedrock AgentCore expuesto podría revelar credenciales temporales de rol y abrir vías de acceso a agentes vecinos dentro de la misma cuenta y región de AWS. Publicado por Zenity Labs el 8 de octubre de 2026, el ataque controlado dependía de herramientas con capacidad de red y permisos IAM excesivos. No se trató de una brecha de AWS a escala global y, a 13 de octubre de 2026, no se había confirmado ninguna explotación activa.
¿Qué es el ataque AgentCorruption AWS?
AgentCorruption AWS es una cadena de ataque controlada que convierte un runtime de Amazon Bedrock AgentCore con capacidad de red en un punto de apoyo para acceder a credenciales, servicios, otros agentes y memoria de AWS. Zenity Labs demostró la cadena dentro de una cuenta y región de AWS en 2026; la investigación no estableció acceso entre cuentas de clientes no relacionadas.
La cadena comenzó con un agente accesible externamente equipado con una herramienta HTTP, de shell o de red comparable. Los investigadores indicaron al agente que contactara con la dirección de metadatos 169.254.169.254, según la divulgación de Zenity Labs del 8 de octubre de 2026.
La respuesta de metadatos expuso credenciales temporales de AWS Security Simbólico Service asignadas al rol de ejecución del agente: un ID de clave de acceso, una clave de acceso secreta y un token de sesión. Zenity exportó esas credenciales y las utilizó fuera del entorno de ejecución para llamar correctamente a las API de AWS.
Esa distinción es importante. Un prompt no burló IAM de alguna manera. El prompt convenció al código autorizado del runtime para acceder a una fuente de credenciales, tras lo cual los permisos del rol determinaron el alcance del impacto. El caso respalda el cambio más amplio de los documentos de políticas hacia la gobernanza de la IA aplicada mediante controles en tiempo de ejecución.
¿Cómo expuso un agente de AWS a otros agentes?
La cadena AgentCorruption AWS alcanzó otros agentes porque el rol de ejecución comprometido tenía históricamente permisos amplios para Amazon CloudWatch Logs, Amazon Elastic Container Registry y AgentCore Runtime. Esos permisos permitieron a Zenity Labs identificar agentes vecinos, recuperar imágenes de contenedor y código fuente, e invocar runtimes internos en la misma cuenta y región durante las pruebas de 2026.
La fase de descubrimiento obtuvo identificadores útiles de los registros y los recursos de infraestructura. El acceso amplio a Amazon ECR expuso después imágenes de contenedor pertenecientes a otros agentes, lo que podía revelar código de aplicación, definiciones de herramientas y supuestos operativos que no estaban destinados a un runtime expuesto públicamente.
Zenity también descubrió que bedrock-agentcore:InvokeAgentRuntime permitía la invocación lateral de agentes internos descubiertos. Por tanto, un agente expuesto a Internet podía convertirse en un invocador de agentes que no estaban expuestos directamente a Internet, siempre que el rol compartido o generado autorizara la acción.
La comparación siguiente separa cada permiso de su consecuencia demostrada. También muestra por qué solucionar únicamente el acceso a los metadatos no elimina el riesgo arquitectónico.
| Escenario | Capacidad o permiso de AWS | Resultado observado | Límite práctico |
|---|---|---|---|
| Acceso inicial | Herramienta del agente con capacidad de red | Solicitud a 169.254.169.254 |
Requería un agente accesible capaz de realizar la solicitud |
| Acceso a credenciales | Servicio de metadatos del runtime | Credenciales STS temporales para el rol de ejecución | Las credenciales heredaban únicamente los permisos de ese rol |
| Descubrimiento | Acceso amplio a CloudWatch Logs y ECR | Identificadores, imágenes y código fuente de los agentes | Demostrado dentro de la misma cuenta y región |
| Movimiento lateral | bedrock-agentcore:InvokeAgentRuntime |
Invocación de agentes internos | Requería permiso sobre el runtime de destino |
| Acceso a conversaciones | ListActors, ListSessions y ListEvents |
Enumeración de usuarios, sesiones e historial a corto plazo | Limitado por la autorización de AgentCore Memory |
| Persistencia | Acceso de escritura a AgentCore Memory | Instrucciones plantadas y redirección posterior de conversaciones | Requería derechos de modificación de la memoria |
De este modelo se desprende directamente un cálculo de riesgo útil: un agente expuesto más un rol compartido pueden crear tantas vías laterales como invocaciones permita el rol. Si un rol puede invocar 12 runtimes, el compromiso de un agente público puede crear hasta 11 objetivos de runtime vecinos, sin contar registros, imágenes, memorias o secretos. La cifra no es un valor predeterminado de AWS; es una forma de cuantificar tu propia exposición de IAM.
¿Podía AgentCorruption leer conversaciones o persistir?
Las pruebas de AgentCorruption AWS mostraron que los permisos de AgentCore Memory podían exponer usuarios, sesiones e historiales de conversaciones a corto plazo, mientras que el acceso de escritura a la memoria podía crear persistencia. Zenity Labs utilizó operaciones de memoria autorizadas en 2026 para plantar instrucciones, alterar el comportamiento posterior del agente y establecer un canal que redirigía al exterior los datos de conversaciones posteriores.
Los permisos, incluidos ListActors, ListSessions y ListEvents permitían la enumeración. En un rol con acceso a múltiples recursos de memoria, esto convierte el compromiso de un solo agente en un problema de privacidad que afecta a conversaciones gestionadas en otros lugares.
El acceso de escritura es más peligroso que el de lectura porque el efecto puede sobrevivir al prompt malicioso original. Una instrucción plantada puede influir en sesiones posteriores una vez finalizada la interacción inicial, convirtiendo la memoria en una superficie de control en lugar de un almacenamiento pasivo. Se observan preocupaciones similares en informes sobre agentes redirigidos hacia comportamientos de phishing.
Sinceramente, los permisos amplios de escritura en la memoria solo tienen sentido cuando el diseño del agente los requiere explícitamente. El acceso de lectura y escritura debería separarse siempre que los controles de recursos y acciones de AWS lo permitan, y los recursos de memoria deberían limitarse a un único agente o zona de confianza.
¿Era AgentCorruption una vulnerabilidad de AWS o un fallo de configuración?
AWS cuestionó la descripción de AgentCorruption AWS como una vulnerabilidad en octubre de 2026 y afirmó que el acceso a las credenciales del rol de ejecución era un comportamiento documentado. Zenity Labs describió las vías combinadas de metadatos, rol predeterminado y memoria como problemas de seguridad. Las pruebas respaldan una revisión post mortem arquitectónica: la entrega prevista de credenciales se volvió peligrosa al combinarse con herramientas potentes y una autorización excesiva.
La documentación de AWS fechada el 30 de junio de 2026 indica que las invocaciones de AgentCore Runtime se rechazan a menos que MMDSv2 esté habilitado mediante metadataConfiguration.requireMMDSV2=true. La misma documentación explica que el código dentro de la microVM aún puede recibir las credenciales del rol de ejecución del tiempo de ejecución. MMDSv2 eleva el nivel de acceso necesario, pero no constituye un límite de IAM.
Zenity informó de que todos los agentes de AgentCore recién implementados habían utilizado un comportamiento exclusivo de IMDSv2 desde el 14 de febrero de 2026. The Next Web informó de que la validación de Zenity del 29 de septiembre de 2026 había detectado un rol de ejecución predeterminado más limitado, al haberse eliminado los permisos utilizados para la invocación entre agentes, el acceso a conversaciones y el acceso a AWS Secrets Manager.
No se comunicó ningún CVE. Zenity declaró el 8 de octubre de 2026 que AWS había solucionado o aplicado parches a los problemas comunicados, mientras que AWS mantuvo que el comportamiento subyacente de las credenciales era el esperado. Por tanto, calificar el episodio de vulnerabilidad de día cero sin parchear sería engañoso, del mismo modo que considerarlo una configuración inofensiva ignoraría cómo los valores predeterminados y los roles compartidos condicionan las implementaciones reales.
También hay un matiz relacionado con las fechas de divulgación que muchos resúmenes omiten. La narración de Zenity sitúa el informe inicial sobre los metadatos el 17 y el 25 de diciembre de 2025, mientras que The Next Web afirma que el problema generalizado relacionado con el rol predeterminado se comunicó el 12 de enero de 2026. Es posible que esas fechas describan hallazgos distintos, pero las fuentes publicadas no los concilian por completo.
¿Cómo se debe proteger Amazon Bedrock AgentCore?
La protección de Amazon Bedrock AgentCore requiere MMDSv2, un rol de ejecución con el mínimo privilegio para cada agente, redes salientes restringidas y la separación entre tiempos de ejecución públicos e internos. Las directrices de seguridad de AWS disponibles el 13 de octubre de 2026 recomiendan la implementación en una VPC, puntos de conexión de VPC o AWS PrivateLink cuando sea posible, ARN de recursos definidos de forma estricta y auditorías periódicas de permisos.
Empieza por la identidad. Sustituye los roles generados o compartidos por roles de ejecución personalizados que autoricen únicamente el modelo, la imagen, el grupo de registros, la memoria, el secreto y el servicio posterior que necesite cada agente. Los recursos comodín merecen un análisis minucioso incluso cuando la acción permitida parezca inofensiva.
A continuación, limita la comunicación. Un agente expuesto al público no debería poder enumerar ni invocar agentes internos simplemente porque ambos se ejecuten en la misma cuenta y región. La separación de zonas de confianza, grupos de seguridad y roles reduce la probabilidad de que un incidente de inyección de instrucciones se convierta en un movimiento lateral. El aislamiento basado en hardware lleva esta misma premisa un paso más allá, como se observa en el enfoque de Nvidia para el aislamiento de agentes de IA.
La lista de comprobación de la revisión de AgentCorruption AWS debería abarcar estos controles:
- Confirma que todos los tiempos de ejecución requieren MMDSv2 e identifica las implementaciones antiguas que puedan ser anteriores al cambio de aplicación de 2026.
- Busca en las políticas de IAM recursos comodín, roles de ejecución compartidos y permisos para invocar tiempos de ejecución de AgentCore vecinos.
- Limita el acceso a CloudWatch Logs y Amazon ECR a los grupos de registros y las imágenes asignados a un único agente.
- Revisa las acciones de AgentCore Memory, especialmente las relacionadas con la enumeración de actores, sesiones y eventos, además de todos los permisos de escritura.
- Comprueba el acceso a AWS Secrets Manager y elimina los secretos que el tiempo de ejecución no necesite para la tarea definida.
- Restringe las reglas salientes de los grupos de seguridad y deniega el acceso a los destinos que ninguna herramienta aprobada necesite.
- Separa los agentes públicos e internos por rol, ruta de red, recurso de memoria y límite de sesión.
No dependas de instrucciones incluidas en las indicaciones, como «no accedas nunca a los metadatos». Las indicaciones rigen el comportamiento del modelo de forma probabilística; IAM y las políticas de red aplican la autorización. La misma lección de seguridad aparece cuando los incidentes de filtración de datos de agentes obligan a restringir el tiempo de ejecución en lugar de añadir otra capa de instrucciones amables.
Preguntas frecuentes sobre AgentCorruption AWS
¿Se explotó AgentCorruption en la práctica?
No se identificó ninguna explotación confirmada de AgentCorruption en la naturaleza en las divulgaciones de Zenity, la documentación de AWS o la cobertura independiente revisadas hasta el 13 de octubre de 2026. Las pruebas publicadas describen una investigación de seguridad controlada, no una brecha activa que afecte a clientes.
¿AgentCorruption afectó a todas las cuentas de AWS?
AgentCorruption no demostró tener acceso a todos los clientes de AWS ni a cuentas no relacionadas. Zenity Labs mostró acceso lateral a recursos permitidos por un rol de ejecución dentro de la misma cuenta y región de AWS.
¿MMDSv2 detiene toda la cadena de ataque?
MMDSv2 no sustituye a IAM con el principio de mínimo privilegio, porque la documentación de AWS indica que el código en tiempo de ejecución puede recibir las credenciales de su rol de ejecución. MMDSv2 es una capa de defensa; los roles restringidos, los controles de salida y el aislamiento de los agentes limitan lo que pueden hacer las credenciales expuestas.
¿Debería rotar las credenciales del rol de ejecución de AgentCore?
AgentCore utiliza credenciales STS temporales, pero una posible exposición sigue justificando medidas de respuesta ante incidentes en 2026: detén o aísla el entorno de ejecución, revisa CloudTrail y los registros de los servicios, elimina los permisos excesivos, rota cualquier secreto expuesto por separado y vuelve a desplegar con un rol limitado.
¿Puede un prompt por sí solo proteger un agente de AWS?
Un prompt no puede imponer la autorización de AWS ni los límites de red. La seguridad de Amazon Bedrock AgentCore depende de las políticas de IAM, los controles de metadatos del tiempo de ejecución, los grupos de seguridad, la arquitectura de la VPC, el aislamiento de recursos y la supervisión.