La investigación de Zenity sobre AgentCore: el prompt fue la entrada, el rol cloud del agente decidió el daño

La inyección de prompt se suele plantear como un problema del modelo: cómo evitar que un agente siga instrucciones ocultas en su entrada. La nueva investigación de Zenity Labs sobre Amazon Bedrock AgentCore recuerda que la pregunta más costosa llega después de que la inyección tiene éxito. ¿A qué puede llegar la propia identidad cloud del agente?

En el entorno de prueba de los investigadores, la respuesta era mucho más de lo que debería alcanzar un solo agente. Zenity informa de que, partiendo de un único agente expuesto públicamente, obtuvo las credenciales del rol de ejecución de ese agente, y que los permisos de ese rol llegaban a todos los agentes de la misma cuenta y región de AWS: se podía invocar a otros agentes, recuperar sus imágenes de contenedor y leer y alterar su memoria, incluidas las conversaciones privadas entre usuarios y agentes.

Dos advertencias enmarcan todo lo que sigue. Primero, este es el relato de los propios investigadores sobre su configuración de prueba, publicado el 8 de octubre como una serie de publicaciones; no encontramos ninguna declaración pública de AWS al respecto, y AWS cerró el primero de los dos informes de Zenity como “informativo”. Segundo, Zenity vende productos de seguridad para agentes de AgentCore. Ninguno de los dos puntos hace que los hallazgos sean falsos, pero ambos deben leerse junto a ellos.

El rol, no el prompt, definió el radio de impacto

El hallazgo central tiene que ver con el alcance. Según Zenity, el rol de ejecución por defecto asociado a los agentes “no estaba acotado al agente específico”: sus permisos cubrían los runtimes de los agentes, la memoria y los logs de toda la región, en lugar de los recursos del agente al que pertenecía. Los investigadores llaman al resultado “movimiento lateral amplio”.

Es un fallo cloud conocido en un lugar nuevo. Un rol de carga de trabajo escrito con comodines es un riesgo en cualquier servicio de cómputo. En una plataforma de agentes, el riesgo es más agudo por dos motivos. La carga de trabajo recibe instrucciones en lenguaje natural de cualquiera que pueda hablar con ella, así que el camino desde una entrada externa hasta el rol es corto. Y los vecinos a los que puede llegar son otros agentes, cuya memoria guarda lo que los usuarios les contaron, que a menudo son justo los datos personales y de negocio que la plataforma debía mantener separados.

El hallazgo sobre la memoria merece una línea aparte. Zenity informa de que el rol no solo podía leer la memoria, sino también escribir en ella, lo que convierte un problema de confidencialidad en uno de integridad: a un agente que confía en su memoria puede dirigirlo cualquiera que pueda añadirle contenido. Ya lo señalamos cuando escribimos que la memoria de los agentes es almacenamiento de datos empresariales; esto es lo que ocurre cuando la vía de escritura está abierta.

A qué debería llegar el rol de ejecución de un agente

Los recursos del propio agente

• Su runtime
• Su memoria
• Sus logs
• Su acceso al modelo

Acotado por recurso, no por comodín

Todo lo demás de la cuenta

• Otros agentes
• Su memoria y sesiones
• Secretos compartidos
• Imágenes de contenedor

Se alcanza solo mediante una llamada auditada bajo otra identidad

Qué cambió AWS y qué deja en sus manos

La cronología de Zenity abarca casi un año. Reportó el problema de acceso inicial el 25 de diciembre de 2025, y el rol por defecto con privilegios excesivos el 12 de enero de 2026. AgentCore pasó a usar solo IMDSv2, un endurecimiento de cómo las cargas de trabajo obtienen credenciales, el 14 de febrero de 2026, según los investigadores. En junio, dicen, el rol por defecto seguía sin cambios. Durante una revisión final el 29 de septiembre, Zenity observó “cambios sustanciales” en el rol de ejecución por defecto: se eliminaron la ejecución de agentes entre regiones, la lectura de conversaciones privadas y el acceso a Secrets Manager, y otros permisos quedaron muy restringidos. Zenity no publica los permisos del rol antes y después.

De ahí se derivan tres consecuencias para los equipos que ejecutan agentes en AgentCore, o en cualquier plataforma que asocie un rol cloud a un agente.

Un valor por defecto más seguro no reescribe los roles que usted ya tiene. Zenity no dice si se actualizaron los roles existentes. Los roles de IAM en una cuenta de cliente normalmente solo cambian cuando alguien los cambia, así que los agentes desplegados con el valor por defecto anterior merecen una revisión directa de sus roles de ejecución, no una suposición.

Acote cada rol a un solo agente. El runtime, la memoria, los logs y los secretos deben nombrarse por recurso. Separar los agentes expuestos públicamente de los internos, por cuenta cuando el riesgo lo justifique, limita a qué puede llegar un solo compromiso; Zenity señala que muchas organizaciones ejecutan ambos tipos en paralelo.

Trate las peticiones salientes de las herramientas del agente como una frontera de seguridad. Cualquier herramienta que obtenga URLs en nombre del agente puede apuntarse a un lugar inesperado. Las reglas de egreso aplicadas fuera del agente, el tipo de frontera que tratamos en nuestro análisis sobre la contención de agentes, y las credenciales que nunca entran en el entorno del agente, como en el propio diseño Strands Box de AWS, reducen ambas lo que puede hacer un agente manipulado.

La lección no es específica de AWS. Todo runtime gestionado de agentes le da al agente una identidad en la nube que hay debajo, y esa identidad normalmente la crea la herramienta de despliegue, no la revisa nadie del programa de IA y es invisible en el propio registro de auditoría del agente. La inyección de prompt no se evitará por completo. Hasta dónde viaja se decide en IAM, antes de que llegue el primer prompt.