AgentCorruption es el nombre dado por Zenity Labs a una cadena de investigación que conectó una debilidad conocida de los agentes, la inyección de instrucciones, con acceso al servicio de metadatos de instancia y permisos IAM excesivos. La prueba se realizó en un entorno controlado.
CONFIRMADO EN PRUEBA: un actor que podía interactuar con un agente público de Amazon Bedrock AgentCore logró inducirlo a consultar el endpoint local de IMDS, recuperar credenciales temporales del rol de ejecución y reutilizarlas contra recursos de AgentCore de la misma cuenta y región. La demostración incluyó invocar otros agentes, leer sesiones privadas, acceder a secretos y crear eventos de memoria persistente.
NO DETERMINADO: las fuentes publicadas no aportan evidencia de explotación por atacantes reales. Tampoco existe evidencia pública de una capacidad para cruzar libremente a cualquier cuenta de AWS. AWS indicó que el acceso entre recursos depende de permisos otorgados por el desarrollador.
Lectura rápida
Qué ocurrió y qué no está demostrado
La investigación describe una ruta condicionada por la arquitectura. Un prompt malicioso no obtiene por sí solo control de una cuenta cloud. La cadena requirió un agente accesible, una herramienta capaz de hacer solicitudes HTTP, acceso de la microVM a IMDS y una identidad IAM con permisos amplios.
Zenity caracteriza la cadena como un problema sistémico de diseño y permisos. AWS sostiene que el comportamiento de acceso se ajustaba a la configuración esperada y al modelo de responsabilidad compartida. Ambas posiciones son necesarias para leer correctamente el riesgo: el prompt fue el disparador, pero el alcance provino de las capacidades delegadas al agente.
Cómo avanzó la cadena AgentCorruption
1. Entrada maliciosa: el atacante entrega una instrucción a través del chat de un agente expuesto.
2. Solicitud inducida: una herramienta con capacidad HTTP ejecuta una petición desde la microVM hacia 169.254.169[.]254, el endpoint local legítimo de AWS IMDS.
3. Identidad temporal: IMDS devuelve las credenciales temporales asociadas al rol IAM del workload.
4. Descubrimiento y movimiento lateral: permisos de enumeración, invocación y lectura permiten identificar o alcanzar otros agentes y recursos de la misma cuenta y región.
5. Secretos y memoria: permisos amplios pueden habilitar recuperación de secretos o creación de eventos de memoria que alteren sesiones posteriores.
De un prompt a una identidad cloud
El punto de quiebre fue la combinación de controles
La inyección no fue la única causa. Si la identidad recuperada hubiera tenido un alcance mínimo, y cada agente hubiera estado aislado con un rol propio, la consecuencia habría sido mucho menor. El riesgo aumenta cuando una entrada no confiable recibe, a través del agente, capacidades que pertenecen a la infraestructura.
PROBABLE: los despliegues con roles compartidos, herramientas de red genéricas, memoria persistente y secretos de varias integraciones concentran más radio de impacto. Esa es una condición de exposición que debe validarse localmente, no una prueba de compromiso.
Qué cambió después de la divulgación
Según la cronología publicada por Zenity, AWS comenzó a usar IMDSv2 para agentes nuevos en febrero de 2026 y posteriormente redujo de forma sustancial los permisos del rol predeterminado. Esto reduce parte de la ruta publicada, pero no demuestra que todos los despliegues previos hayan sido recreados, migrados o reevaluados.
La pregunta operativa no es solo si un servicio usa la versión más reciente. Es si cada agente existente conserva una combinación de exposición externa, salida de red, acceso a metadatos, permisos regionales y memoria que permita una ruta equivalente.
Exposición y cómo saber si existe una condición equivalente
Priorice agentes accesibles desde internet, desde canales de clientes o proveedores, o conectados a contenido no confiable. Revise herramientas de navegación, HTTP, ejecución de código y conectores que puedan alcanzar destinos internos.
Inventarie por agente: cuenta, región, propietario, fecha de despliegue, interfaz expuesta, herramientas, memoria, rol IAM, secretos consumidos y reglas de salida. Después valide en CloudTrail, registros del runtime, VPC Flow Logs, proxy y auditoría de memoria si existen solicitudes a metadatos, invocaciones entre agentes o acceso a secretos fuera del patrón esperado.
Qué hacer a primera hora
1. Inventariar los agentes de AgentCore y documentar exposición, herramientas, memoria y rol IAM. El cierre es un listado con propietario, cuenta, región y criticidad.
2. Confirmar IMDSv2 y reevaluar o recrear despliegues anteriores cuando corresponda. La prueba de cierre es evidencia técnica por agente.
3. Asignar un rol independiente por agente y retirar permisos regionales, comodines y acciones no justificadas. Compare cada política con funciones reales.
4. Restringir salida de red y acceso a destinos link local salvo necesidad explícita. Pruebe el control sin afectar operaciones aprobadas.
5. Separar secretos por integración, limitar GetSecretValue y GetResourceApiKey, y revisar memorias para detectar eventos persistentes no aprobados.
Cómo evitar caer
No introduzca secretos, credenciales ni datos regulados en agentes públicos o no aprobados. Desconfíe si un asistente pide tokens, claves, datos de infraestructura o acciones fuera de su función.
No copie instrucciones técnicas de fuentes externas directamente en un agente conectado a cloud. Reporte respuestas anómalas o cambios persistentes de comportamiento y confirme operaciones sensibles fuera del chat.
Indicadores y artefactos de comportamiento
- Solicitudes desde agentes hacia
169.254.169[.]254. - Uso inesperado de
DescribeLogGroupspara enumerar recursos de agentes. InvokeAgentRuntimeoListEventsentre agentes no relacionados.GetResourceApiKeyoGetSecretValuedesde roles sin necesidad funcional.CreateEventsobre memorias de otros agentes, usuarios o sesiones.
Lectura ATRc®
La exposición relevante aparece cuando una interfaz conversacional obtiene capacidad de actuar sobre cloud. La oportunidad crece con herramientas de red, identidades reutilizadas, secretos y memoria. La ruta publicada por Zenity permite evaluar cada uno de esos enlaces antes de que una instrucción no confiable herede permisos operativos.
La métrica defendible es el tiempo necesario para descubrir el agente expuesto, identificar su rol, reducir permisos y confirmar su aislamiento. La inyección de instrucciones puede ser difícil de eliminar por completo, pero el radio de impacto es controlable mediante arquitectura y trazabilidad.
Conclusión estratégica
AgentCorruption no prueba una toma de control masiva de AWS ni una explotación real observada. Sí demuestra, en una prueba controlada, que un agente con capacidad de red y una identidad cloud sobredimensionada puede convertir una instrucción maliciosa en una cadena operacional.
La respuesta debe enfocarse en condiciones verificables: roles aislados, mínimo privilegio, IMDSv2, egreso restringido, secretos segmentados, memoria revisable y telemetría suficiente para detectar acciones anómalas. Tratarlo como una lección de diseño evita tanto la minimización como el alarmismo.
© 2026 CronUp Ciberseguridad. Todos los derechos reservados. Este contenido está protegido por la Ley Nº 17.336. Se permite su uso informativo citando la fuente y enlazando el artículo original. Su reproducción o uso sin atribución constituye infracción.
