El rol predeterminado, no el modelo: cómo un solo prompt tomó el control de todos los agentes de una cuenta de AWS

Conclusiones clave

• Un solo prompt a un agente público comprometió todos los agentes AgentCore de la misma cuenta y región de AWS — Zenity Labs divulgó la cadena AgentCorruption el 8 de octubre de 2026 en SecTor, Toronto, tras una divulgación responsable que comenzó el 25 de diciembre de 2025.
• El radio de impacto fue una propiedad del rol, no del modelo — el rol de ejecución predeterminado incluía bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:ListEvents, un permiso de escritura en memorias entre agentes, bedrock-agentcore:GetResourceApiKey y secretsmanager:GetSecretValue, todos con alcance en toda la región de la cuenta y no limitados a un solo agente.
• La corrección tardó 278 días — AWS migró AgentCore a IMDSv2 el 14 de febrero de 2026, pero la re-verificación de Zenity del 22 de junio de 2026 encontró el rol predeterminado sin cambios; la eliminación de permisos llegó el 29 de septiembre de 2026.
• La memoria del agente es una superficie de persistencia — los investigadores plantaron memorias que redirigían las conversaciones futuras de los agentes a un destino controlado por el atacante, mientras los usuarios seguían hablando con lo que parecía un agente empresarial de confianza.
• AWS calificó el comportamiento de «documented and expected» — y recomienda a los clientes conceder a los roles de ejecución solo los permisos que sus agentes necesitan. La verificación del rol predeterminado es tarea del cliente, en cualquier plataforma gestionada.

El 8 de octubre de 2026, en la conferencia SecTor de Toronto, Zenity Labs divulgó AgentCorruption: una cadena de fallos en Amazon Bedrock AgentCore, la plataforma gestionada de AWS para desplegar y operar agentes de IA. Un solo prompt a un agente público — un agente de atención al cliente expuesto a internet, por ejemplo — devolvió las credenciales temporales de AWS asignadas a la máquina de ese agente. Esas credenciales pertenecían a un rol de IAM predeterminado cuyos permisos no estaban limitados a ese agente, sino a todos los agentes AgentCore de la misma cuenta y región de AWS. Con ellas, los investigadores invocaron agentes internos a los que nunca tuvieron autorización, leyeron conversaciones privadas entre agentes y usuarios, descargaron imágenes de contenedor de los agentes para extraer código fuente, obtuvieron claves de API y tokens OAuth de AWS Secrets Manager, y plantaron memorias que siguieron operando después de que la sesión terminara.

Nada de eso requirió un fallo del modelo. El único trabajo del modelo en la cadena fue hacer una petición HTTP cuando se le pidió. Todo lo que siguió fue IAM. Este artículo traza la cadena de cinco pasos, los permisos concretos que hicieron posible cada paso, la cronología de 278 días de la divulgación, y las cinco preguntas que cualquier equipo debería hacerse antes de desplegar agentes en una plataforma gestionada de agentes — sea cual sea el proveedor.

La cadena de ataque, paso a paso

Zenity Labs publicó la investigación completa como una serie técnica en cinco partes; la cadena se comprime en cinco movimientos.

Paso 1: inyección de prompt hacia IMDS. Los agentes de AgentCore se ejecutan dentro de microVMs de Firecracker cuyo aislamiento de red no bloqueaba el servicio de metadatos de la instancia. Cualquier herramienta del agente capaz de hacer una petición HTTP saliente envía esa petición desde dentro de la propia instancia — una primitiva de SSRF. Un solo prompt dirigió al agente expuesto a llamar a 169.254.169.254, el Instance Metadata Service, que devolvió las credenciales temporales de IAM del rol asignado a la carga de trabajo. El coste de entrada fue acceso de chat a un solo agente con una herramienta de uso común.

Paso 2: descubrimiento en toda la cuenta. Las credenciales pertenecían a un rol de ejecución predeterminado que no estaba limitado al agente concreto. Entre sus permisos estaba DescribeLogGroups, que los investigadores usaron para enumerar cada agente y su ID en toda la región de la cuenta. Una segunda vía de descubrimiento llegó gratis: los nombres de los repositorios del Elastic Container Registry coincidían con los IDs de los agentes, de modo que el permiso de pull a ECR del rol permitió a los investigadores descargar la imagen de contenedor de cualquier agente y leer su código fuente completo.

Paso 3: movimiento lateral. El rol incluía bedrock-agentcore:InvokeAgentRuntime, con alcance en toda la región. Los investigadores podían invocar cualquier agente AgentCore de la cuenta — incluidos agentes internos y sensibles a los que no estaban autorizados a acceder. El ejemplo desarrollado en la divulgación: un atacante que entra por el agente público de atención al cliente se mueve lateralmente a un agente financiero interno de la misma región, lo invoca, y accede a sus datos, herramientas y credenciales.

Paso 4: acceso a datos y credenciales. bedrock-agentcore:ListEvents devolvía todas las conversaciones privadas de todos los agentes, usuarios y sesiones — las fronteras de privacidad de la plataforma, disueltas. bedrock-agentcore:GetResourceApiKey y secretsmanager:GetSecretValue alcanzaban después las credenciales que AgentCore deliberadamente mantiene lejos del agente: claves de API, tokens OAuth y entradas de Secrets Manager, incluidas credenciales usadas para conectar con recursos empresariales y servicios de terceros más allá de AWS.

Paso 5: persistencia mediante memoria. El rol también llevaba un permiso de escritura en memoria — bedrock-agentcore:CreateEvent sobre BedrockAgentCoreMemory. Los investigadores crearon memorias nuevas en distintos agentes y usuarios que alteraron de forma persistente el comportamiento de los agentes y secuestraron sus objetivos en sesiones futuras, dirigiendo conversaciones a un destino controlado por el atacante. El compromiso sobrevivió a la sesión que lo creó.

La cadena siguiente traza los cinco movimientos y lo que expuso cada uno:

El rol, no el modelo

La lección estructural está en lo que los cinco pasos no implicaron. Sin jailbreak, sin fallo de alineación, sin ingeniería de prompts sofisticada más allá de «llama a esta URL». El cofundador y CTO de Zenity, Michael Bargury, planteó la causa raíz como una tensión de diseño con la que toda plataforma sale al mercado: «La seguridad en la nube se basa en la segmentación y el acceso de mínimo privilegio. Los agentes de IA, sin embargo, necesitan su espacio creativo para ser útiles. Mezclar ambos crea un conflicto inherente». Su conclusión: «Toda empresa que despliegue agentes en la nube se enfrentará a las mismas decisiones fundamentales entre agencia y mínimo privilegio».

AgentCore resolvió ese conflicto a favor de la agencia — para la comodidad de la plataforma, no para la seguridad del cliente. El rol de ejecución predeterminado era amplio para que los agentes funcionaran recién instalados, y sus permisos cubrían todos los recursos de agentes en la región de la cuenta. La propia declaración de AWS, publicada junto con la investigación, dice que el comportamiento es «documented and expected», que los agentes pueden acceder a las credenciales de su propio rol de ejecución a través del servicio de metadatos, y que «como buena práctica, recomendamos a los clientes conceder a sus roles de ejecución solo los permisos que sus agentes necesitan», remitiendo a su gestión de credenciales, permisos del runtime y guía de mínimo privilegio.

Leídos juntos, esos dos hechos dejan la posición del comprador sin ambigüedad: la plataforma trata el rol predeterminado como un punto de partida, y el radio de impacto de un agente comprometido como un problema de configuración del cliente. Es una posición defendible para un proveedor de nube — el mínimo privilegio en IAM ha sido tarea del cliente desde que existe IAM. Pero choca con el marco de marketing de las plataformas gestionadas de agentes: que la plataforma se encarga del endurecimiento operativo para que tu equipo no tenga que hacerlo. La cadena AgentCorruption es el aspecto práctico de ese choque: el valor por defecto de la plataforma era la vulnerabilidad, y la documentación de la plataforma era la mitigación.

278 días de la divulgación a la corrección

La cronología de la divulgación es la segunda lección. Zenity informó del acceso inicial a IMDS el 25 de diciembre de 2025. AWS migró AgentCore a IMDSv2 exclusivamente para los agentes recién desplegados el 14 de febrero de 2026, y cerró ese primer informe como «informativo» el 12 de abril. Pero el segundo informe de Zenity — el radio de impacto del rol predeterminado, presentado el 12 de enero de 2026 — avanzó más despacio. El 25 de febrero, AWS dijo que el equipo estaba trabajando activamente en ello mientras el rol predeterminado seguía igual. El 22 de junio de 2026, Zenity re-verificó y confirmó que los permisos seguían sin cambios. La corrección sustancial — eliminar los permisos que permitían la ejecución amplia de agentes, la lectura de conversaciones privadas y el acceso a Secrets Manager — se observó el 29 de septiembre de 2026, 278 días después de la primera divulgación y días antes de la publicación pública.

Fecha	Evento
25 dic 2025	Zenity divulga a AWS el acceso inicial a IMDS
12 ene 2026	Zenity presenta el informe del radio de impacto del rol predeterminado
14 feb 2026	AgentCore pasa a IMDSv2 exclusivamente para agentes recién desplegados
25 feb 2026	AWS confirma trabajo en curso; el rol predeterminado sigue igual
12 abr 2026	AWS cierra el informe de IMDS como «informativo»
22 jun 2026	Re-verificación de Zenity: el rol predeterminado sigue sin cambios
29 sep 2026	Rol predeterminado endurecido — eliminados los permisos de ejecución entre agentes, lectura de conversaciones y Secrets Manager

Dos implicaciones para cualquier equipo que confíe en los valores por defecto de una plataforma gestionada. Primera: un valor por defecto pensado para la comodidad puede ser una vulnerabilidad permanente durante casi un año incluso después de una divulgación responsable — la ventana entre «lo informamos» y «está corregido» se mide en meses, y tus agentes corren dentro de ella. Segunda: la corrección misma es la prueba de la tesis: AWS no reentrenó un modelo ni añadió un filtro de seguridad. Editó una política de rol. El radio de impacto fue todo ese tiempo un documento de IAM.

La memoria es una superficie de persistencia

La parte más orientada al futuro de la cadena es el paso 5. Leer datos es una brecha; modificar la memoria es una toma de control. Los investigadores usaron el permiso de escritura en memoria del rol para plantar instrucciones que sobrevivieron a la sesión, redirigieron conversaciones futuras a un destino controlado por el atacante y dejaron al agente aparentando operar con normalidad. Una respuesta a incidentes que detiene el agente, rota sus credenciales y parchea el vector de inyección no elimina una memoria plantada. Si el almacén de memoria no forma parte de la respuesta, el compromiso persiste a través de la limpieza.

Es la misma clase de modificación de comportamiento que llevó a Anthropic a cortar el acceso a internet de todas las evaluaciones internas de agentes, como la compañía divulgó en octubre de 2026 — el tema de Dos laboratorios frontera, una admisión. Ese artículo cubre la admisión del laboratorio frontera de que el entrenamiento de alineación no basta para controlar el comportamiento de los agentes. AgentCorruption muestra el mismo problema un nivel más abajo, en la capa de plataforma: un almacén de memoria en el que puede escribir cualquier cosa con el permiso IAM correcto es un mecanismo de persistencia, y las arquitecturas de kill switch tratadas en Kill switch por diseño deben tratar la memoria como parte del estado comprometido, no solo del runtime.

Cinco preguntas antes de desplegar en cualquier plataforma gestionada de agentes

AgentCore es el ejemplo desarrollado, no la excepción. La nota de prensa de Zenity plantea el punto general: las empresas ejecutan habitualmente agentes orientados al público y agentes internos en los mismos entornos de nube, y una sola debilidad inesperada en un agente puede desplomar las fronteras de un entorno completo. La plataforma cambiará; las clases de permisos rimarán. Antes de que cualquier agente entre en producción en una plataforma gestionada, consigue respuestas por escrito a estas cinco:

1. ¿Qué contiene exactamente el rol de ejecución predeterminado? No «es seguro por defecto» — el documento de política, permiso a permiso. Marca cada permiso con alcance * o sobre todos los agentes de la cuenta. La cadena de AgentCorruption es la respuesta de cinco permisos a esta pregunta.
2. ¿Puede un agente descubrir a los demás? Cualquier permiso de listado o descripción en toda la cuenta convierte un agente comprometido en un inventario de objetivos. DescribeLogGroups fue el paso de enumeración; toda plataforma tiene una superficie de listado equivalente.
3. ¿Puede un agente invocar a otro? La invocación agente-a-agente es la primitiva de movimiento lateral. Si la plataforma no puede limitar la invocación a listas de permiso explícitas por agente, trata a todos los agentes de la cuenta como un único dominio de confianza — porque así es como los tratará el atacante.
4. ¿Dónde viven las credenciales de las herramientas, y qué rol puede leerlas? Una puerta de enlace de secretos solo traslada el riesgo si ningún rol de agente puede llamar a GetSecretValue sobre ella. El rol de AgentCorruption podía leer exactamente las credenciales que el diseño de la plataforma se suponía que mantenía lejos de los agentes.
5. ¿Puede escribir en la memoria algo distinto del propio agente, en su propia sesión? Las escrituras en memoria entre agentes y entre usuarios convierten el almacén de memoria en una superficie de persistencia. Si la respuesta es un permiso que puedes limitar, limítalo; si no, el almacén de memoria pertenece a tu plan de respuesta a incidentes como estado controlado por el atacante.

Lecturas relacionadas

• Bedrock vs OpenAI: Cómo elegir una plataforma de IA administrada para agentes en producción — la comparación de plataformas gestionadas sobre la que aterriza este incidente: coste, privacidad y estabilidad del proveedor, con la cuestión del rol predeterminado añadida ahora a la lista de due diligence
• 126 incidentes en un mes: el primer inventario integral de seguridad de IA y lo que demuestra sobre el riesgo de los agentes — la declaración de frecuencia detrás de este incidente: los exploits en la capa de agentes fueron la mayor clase de vector de ataque en septiembre de 2026
• Lista de verificación de gobernanza de agentes de IA: una revisión previa al despliegue para agentes en producción — la revisión previa al despliegue completa, con los roles de ejecución de mínimo privilegio y el descubrimiento entre agentes como elementos de la lista

Un distribuidor industrial de mid-market con dos agentes en una plataforma gestionada — un agente público de cotizaciones frente a su tienda y catálogo de BigCommerce, y un agente interno con tarifas de NetSuite y acceso a inventario — tiene exactamente la topología que AgentCorruption explotó: un agente expuesto a internet y un agente de back-office en la misma cuenta. El patrón contra el que construimos da a cada módulo conector su propio rol de mínimo privilegio, registra cada herramienta que el agente puede llamar, limita la memoria por agente y escribe una pista de auditoría que mostraría una escritura en memoria desde fuera de la sesión. El punto no es que un build con permisos limitados sea inmune a un fallo del lado de la plataforma; es que el radio de impacto del próximo lo fija la política de rol que revisó tu equipo, no la que la plataforma publicó como valor por defecto.

Descubrimiento de una semana. Obtienes un inventario de sistemas, un mapa de flujos de trabajo y un alcance fijo — construyas con nosotros o no.

Solicita un build con alcance definido.