AgentCorruption: riesgos de metadatos e IAM en AgentCore

La investigación de Zenity de octubre de 2026 informa que herramientas influidas por el modelo podían acceder a los metadatos del runtime AgentCore y que los permisos históricos del rol predeterminado ampliaban el acceso. AWS considera esperado el acceso a las credenciales del propio rol del runtime y recomienda el mínimo privilegio. La investigación de Zenity no cita un identificador CVE ni demuestra una brecha de clientes.^{[1], [4]}

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina un agente en un taller con una credencial para las tareas que le asignaron. Zenity afirma que una herramienta guiada por el modelo podía pedir esa credencial al mostrador interno; los permisos antiguos de la credencial abrían más salas de las necesarias. AWS dice que es normal que el agente reciba dentro del taller las credenciales de su propio rol. La defensa práctica consiste en limitar las puertas que abre cada credencial y controlar qué herramientas pueden hacer solicitudes internas.^{[1], [4]}

Conceptos Clave y Términos

AgentCorruption: Nombre de Zenity Labs para su cadena de investigación controlada contra Amazon Bedrock AgentCore. Zenity no cita un identificador CVE y su investigación no demuestra una brecha de clientes.^{[1], [7]}
MMDS y credenciales del rol de ejecución: AWS documenta que el código dentro de una microVM de AgentCore puede obtener mediante MMDS credenciales temporales del rol de ejecución de ese runtime. El servicio considera esperado este comportamiento; los permisos del rol determinan qué autorizan esas credenciales.^{[4], [5]}
Alcance de permisos: El rol de ejecución define qué acciones y recursos de AWS puede usar el código del agente. Zenity informa de permisos históricos amplios en la misma cuenta y región. AWS recomienda el mínimo privilegio; la autorización depende de las políticas de identidad y de recursos aplicables a cada operación. AWS especifica que el acceso entre cuentas requiere permisos explícitos tanto en el rol como en el recurso de destino.^{[3], [1], [6]}
CWE-918 — clasificación editorial: Esta página usa CWE-918 como clasificación editorial para una solicitud iniciada por una herramienta del agente hacia un servicio interno de metadatos. AWS no asignó esta CWE; el acceso a metadatos es un comportamiento documentado.^{[8], [4], [1]}

Mapeos de marcos

Mapeo conceptual de FlawOpen a MITRE CWE; ningún proveedor ni registro CVE asignó este identificador de debilidad a esta demostración de investigación. CWE-918

Flujo de Ataque Paso a Paso

Paso 1

Un agente público tiene una herramienta de salida

Zenity probó un agente AgentCore accesible públicamente con una herramienta capaz de enviar solicitudes salientes. El escenario requiere un agente alcanzable y una ruta de herramienta influenciable por el modelo; no describe todas las implementaciones.^{[2], [1]}

Paso 2

La influencia del modelo llega a los metadatos

Zenity informa de que su agente de prueba podía ser inducido a consultar el servicio local de metadatos. AWS documenta que el código de la microVM puede acceder a las credenciales de MMDS; la cuestión de seguridad discutida es la ruta de confianza entre modelo y herramienta y la autoridad de esas credenciales, no la existencia de las credenciales propias del runtime.^{[2], [1], [4]}

Paso 3

La respuesta representa el rol del agente

AWS documenta que MMDS proporciona credenciales temporales para el rol de ejecución configurado. Esas credenciales no autorizan automáticamente todos los recursos; las políticas IAM y de recursos aplicables determinan las operaciones permitidas. AWS especifica que el acceso entre cuentas requiere permisos explícitos tanto en el rol como en el recurso de destino.^{[4], [6], [1]}

Paso 4

Los permisos históricos ampliaron el impacto

Zenity informa de que el rol predeterminado de entonces permitía operaciones sobre otros recursos AgentCore de la misma cuenta y región, incluidas invocaciones, acceso a sesiones/eventos, operaciones de memoria y acceso a secretos. Zenity dice que AWS restringió sustancialmente ese rol antes del 29 de septiembre de 2026. Esto no demuestra que los roles administrados por clientes cambiaran automáticamente.^{[3], [1], [6]}

Paso 5

Los controles actuales protegen límites distintos

Zenity dice que los agentes nuevos empezaron a usar MMDSv2 el 14 de febrero de 2026. La documentación actual de AWS exige MMDSv2 para invocar el runtime desde el 30 de junio de 2026. AWS aún documenta que el código de la microVM puede acceder a las credenciales del rol; por eso MMDSv2 no sustituye al IAM de mínimo privilegio ni al control de herramientas influidas por el modelo. Esta separación es una inferencia defensiva basada en las fuentes.^{[5], [4], [1]}

Evidencias y alcance actual

Límite	Evidencia	Acción defensiva
Acceso a metadatos	Zenity informa de acceso en su prueba; AWS documenta credenciales MMDS para código dentro de la microVM.	Trata el código del agente y las herramientas influidas por el modelo como titulares del rol de ejecución.
Permisos del rol	Zenity informa de valores predeterminados históricos amplios. AWS dice que el acceso entre cuentas requiere permisos explícitos en el rol y en el recurso de destino; las demás operaciones siguen sus políticas IAM y de recursos aplicables.	Inspecciona los roles desplegados y las políticas de recursos; verifica las políticas aplicables a cada operación y no deduzcas el alcance de autorización de un prompt o de un valor predeterminado del servicio.
Cambio del rol predeterminado	Zenity dice que observó cómo AWS restringió el rol predeterminado el 29 de septiembre de 2026. No afirma que cambiaran automáticamente los roles de clientes; su investigación no cita CVE ni demuestra una brecha de clientes.	Verifica los roles efectivos en cada cuenta y región; no supongas que se modificaron los roles de clientes.
MMDSv2	Zenity sitúa el uso de MMDSv2 en agentes nuevos el 14 de febrero de 2026; la documentación actual de AWS exige habilitarlo para invocar el runtime desde el 30 de junio de 2026. AWS aún documenta el acceso a credenciales dentro de la VM.	Habilita MMDSv2 y, por separado, limita las acciones, recursos y llamadores del rol.

Análisis de Causa Raíz

Evalúa dos límites por separado: las herramientas influidas por el modelo pueden hacer solicitudes desde dentro del runtime, y el rol de ejecución define la autoridad de esas solicitudes. AWS considera esperado el acceso a las credenciales propias del runtime; el impacto entre agentes que informó Zenity dependía del alcance histórico del rol. Habilitar MMDSv2 no limita IAM, y limitar el rol no impide las solicitudes internas dirigidas por el modelo. Revisa por separado la salida de red de las herramientas y la autorización IAM; restringir la salida de red por sí solo no demuestra que el código dentro de la microVM no pueda acceder a MMDS.^{[1], [3], [4], [5]}

Código Fuente: Vulnerable vs. Seguro

Declaraciones de política IAM únicamente ilustrativas; no son la política histórica de AWS ni el cambio posterior del rol predeterminado. AWS recomienda limitar los permisos del runtime a ARN de recursos específicos y evitar comodines. La primera declaración muestra un patrón amplio de recurso; la segunda limita la invocación a un runtime aprobado si se necesita ese permiso. Omítelo si no hace falta. Valida la compatibilidad de acción/recurso y las políticas de recursos complementarias para la implementación real; esto no es una política completa lista para desplegar.^{[3], [6], [5]}

IMPLEMENTACIÓN VULNERABLE

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}

PARCHE SEGURO Y ROBUSTO

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

Lista de Verificación de Seguridad para Ingeniería

✓Inventaría cada rol de ejecución de runtime en todas las cuentas y regiones; compara los permisos efectivos con las políticas actuales de AWS y las administradas por clientes.^{[6], [5]}
✓Elimina la invocación entre runtimes, el acceso a conversaciones, la obtención de secretos, la escritura de memorias y el acceso a imágenes salvo que cada acción tenga una necesidad documentada.^{[3], [6]}
✓Si un runtime debe invocar a otro, limita las políticas de identidad y recursos al runtime y endpoint aprobados; prueba que se deniegue el acceso a runtimes no relacionados.^[6]
✓Habilita MMDSv2 como exige AWS, pero trata el acceso del código de la microVM a las credenciales del rol como un límite de autorización independiente.^{[5], [4], [1]}
✓Reduce los destinos que pueden contactar las herramientas influidas por el modelo a los necesarios para la carga; considéralo una reducción del riesgo de salida, no una prueba de que el código dentro de la VM no pueda acceder a MMDS.^[5]
✓Asigna a los agentes públicos roles con privilegios iguales o inferiores a los de los principales que pueden invocarlos; valida los permisos efectivos con IAM Access Analyzer y pruebas negativas de autorización.^{[5], [6]}

Fuentes

← AI Security Directory →