Zenity AgentCorruption reveló una vía de secuestro a nivel de cuenta en AWS AgentCore
Investigadores de Zenity AgentCorruption descubrieron que un prompt malicioso podía exponer credenciales temporales de AWS desde un agente de Amazon Bedrock AgentCore accesible públicamente. Según los informes, esas credenciales abrían rutas hacia todos los entornos de ejecución de AgentCore que compartieran la cuenta vulnerable, la región y el rol predeterminado con permisos amplios. El hallazgo transformó un problema conocido de inyección de prompts en un fallo de seguridad cloud a nivel de cuenta.
El ataque no dependía de vulnerar un modelo fundacional, acceder a un cliente no relacionado de AWS ni robar una contraseña de administrador. Combinaba la capacidad de un agente para realizar solicitudes HTTP con credenciales de metadatos y permisos excesivos de Identity and Access Management. Zenity afirma que la cadena alcanzó agentes privados, código fuente, historiales de conversación, secretos almacenados y memoria a largo plazo.
Esa combinación importa más que la cifra llamativa de un solo prompt. AWS promocionó AgentCore como infraestructura gestionada para operar agentes de producción de forma segura, incluida la identidad, la memoria, las herramientas, la observabilidad y los entornos de ejecución aislados. AgentCorruption mostró cómo esos servicios conectados podían amplificar el compromiso de un solo agente cuando sus límites de autorización eran demasiado amplios.
También hay una salvedad importante. Zenity divulgó los problemas meses antes de publicar su investigación el 8 de octubre de 2026. Los investigadores informaron que AWS restringió el rol de ejecución predeterminado antes de la publicación, mientras que la documentación de AWS ahora exige controles de metadatos más sólidos y advierte contra el uso en producción de políticas amplias generadas por CLI.
El resultado no demuestra que todas las implementaciones actuales de AgentCore sigan expuestas a la cadena completa. Demuestra que los equipos no pueden tratar la infraestructura gestionada de agentes como sustituto del principio de mínimo privilegio. La seguridad de los agentes ahora debe abarcar conjuntamente el comportamiento del modelo de lenguaje, las credenciales de ejecución, los permisos cloud, la integridad de la memoria y el movimiento lateral.
Cómo Zenity AgentCorruption convirtió un prompt en credenciales de AWS
El primer fallo cruzó la frontera entre una entrada lingüística no confiable y una identidad cloud de confianza.
Según la investigación de AgentCorruption de Zenity, un agente de AgentCore expuesto aceptó un prompt que le indicaba solicitar un endpoint local de metadatos. La solicitud se dirigió a 169.254.169.254, una dirección link-local utilizada por entornos de computación de AWS para proporcionar metadatos de cargas de trabajo y credenciales temporales de roles.
El servicio relevante es Instance Metadata Service, comúnmente abreviado como IMDS. El entorno Firecracker microVM de AgentCore utiliza un MicroVM Metadata Service relacionado, o MMDS, para poner las credenciales del rol de ejecución a disposición dentro de la carga de trabajo.
Ese mecanismo de entrega de credenciales tiene un propósito legítimo. Un agente puede necesitar autorización temporal para leer un objeto S3 aprobado, llamar a otro servicio de AWS o realizar una tarea empresarial. Las credenciales temporales también evitan incrustar claves de acceso permanentes en código o imágenes de contenedores.
El problema surge cuando un prompt no confiable puede hacer que una herramienta contacte el endpoint de metadatos. Zenity afirma que una herramienta con capacidad HTTP envió la solicitud desde dentro de la microVM, por lo que el servicio de metadatos la trató como una solicitud local de carga de trabajo. La respuesta expuso la clave de acceso temporal, la clave secreta y el token de sesión del entorno de ejecución del agente.
Este es un patrón de falsificación de solicitudes del lado del servidor, normalmente llamado SSRF. Un atacante induce a un componente del servidor a solicitar un destino al que no puede llegar directamente. En este caso, según los informes, el agente se convirtió en el componente solicitante porque sus herramientas podían realizar llamadas HTTP salientes.
La inyección de prompts aportó la intención, mientras que la herramienta HTTP aportó la capacidad. Después, el servicio de metadatos proporcionó una identidad cloud. Ninguno de esos elementos por sí solo habría producido el alcance de impacto reportado.
Un modelo que simplemente generara texto inseguro no habría robado credenciales. Un endpoint de metadatos protegido frente a las herramientas del agente habría bloqueado la ruta. Un rol de ejecución con alcance limitado habría contenido las consecuencias incluso después del robo de credenciales.
AWS ahora documenta explícitamente esta propiedad de exposición de credenciales. Su guía de credenciales indica que el código o los actores dentro de una microVM pueden llamar al endpoint de metadatos y acceder a las credenciales disponibles. Por ello, AWS recomienda a los clientes limitar los roles de ejecución únicamente a los permisos que requieran sus cargas de trabajo.
Zenity informó inicialmente del problema de metadatos a AWS el 25 de diciembre de 2025. Los investigadores afirman que AWS cerró ese informe como informativo el 12 de abril de 2026. AWS les comunicó que los agentes desplegados recientemente utilizaban IMDSv2 desde el 14 de febrero.
IMDSv2 exige un token de sesión antes de que un cliente pueda recuperar metadatos. Ese diseño bloquea muchos ataques SSRF convencionales porque el atacante no siempre puede controlar la solicitud preliminar del token y sus cabeceras.
Un agente autónomo cambia esa premisa. Si el agente puede realizar solicitudes suficientemente flexibles, puede obtener el token y después recuperar credenciales. Zenity sostiene que exigir IMDSv2 aumentó la fricción, pero no eliminó el problema de confianza subyacente.
Más tarde, AWS fue más allá de la adopción opcional. La guía actual de ejecución indica que los entornos de AgentCore sin MMDSv2 habilitado se rechazan desde el 30 de junio de 2026. Ese control mejora la línea de base, aunque no justifica los permisos excesivos vinculados a credenciales a las que el código legítimo de ejecución todavía puede acceder.
La lección esencial es arquitectónica. La inyección de prompts se convierte en un compromiso cloud cuando un agente puede traducir instrucciones en lenguaje natural en operaciones privilegiadas de red e identidad. Filtrar la frase maliciosa aborda solo una capa de esa ruta.
El rol predeterminado convirtió un agente en el problema de todos
Las credenciales robadas se convirtieron en una capacidad de alcance a toda la cuenta porque el rol de ejecución probado confiaba a un agente acceso regional a otros agentes.
Zenity presentó un segundo informe el 12 de enero de 2026, centrado en los permisos que sustentaban el compromiso inicial. Los investigadores afirmaron que el rol predeterminado no estaba limitado al entorno de ejecución que lo asumía. Varios permisos se aplicaban a recursos de AgentCore en toda la misma cuenta y región de AWS.
El primer paso de expansión utilizó CloudWatch Logs. Zenity afirma que logs:DescribeLogGroups permitía a la identidad comprometida enumerar los nombres de grupos de logs regionales. Las convenciones de nomenclatura de AgentCore exponían identificadores de entornos de ejecución y recursos de memoria en esos nombres.
Los atacantes no necesitaban un inventario previo de agentes privados. Según los informes, podían derivar identificadores de ejecución a partir de metadatos operativos ya visibles para el rol. El descubrimiento convirtió una identidad robada, de un punto de apoyo local, en un mapa de recursos vecinos.
El rol también contenía permisos regionales para Amazon Elastic Container Registry. Zenity afirma que la nomenclatura predecible de los repositorios permitió a los investigadores asociar entornos de AgentCore con imágenes de contenedores. Extraer esas imágenes expuso código de aplicación y, potencialmente, configuraciones sensibles incorporadas en los artefactos desplegados.
Ese hallazgo cuestiona una suposición común sobre los entornos gestionados. Una microVM puede aislar una sesión en ejecución de otra, mientras IAM sigue autorizando a la sesión a recuperar recursos no relacionados. El aislamiento de cómputo y el aislamiento de autorización resuelven problemas distintos.
Después vino bedrock-agentcore:InvokeAgentRuntime. El análisis de roles de Zenity muestra que la política probada cubría recursos de ejecución comodín en la región. Por tanto, las credenciales robadas podían invocar agentes privados a los que un usuario externo nunca debía poder acceder.
Un bot público de soporte podría contar con herramientas limitadas y datos cuidadosamente filtrados. Un agente privado de facturación podría tener acceso a archivos financieros, API internas o sistemas de transacciones. La invocación regional conectó el punto de entrada expuesto con el agente más sensible.
Zenity demostró esta ruta contra un agente de facturación de prueba. Los investigadores enumeraron sus herramientas, identificaron un archivo llamado billing.json e instruyeron al agente para devolver su contenido. Ese escenario ilustró el movimiento lateral a través de API legítimas de AgentCore, en lugar de mediante un segundo exploit de software.
La memoria de conversaciones volvió a ampliar el daño. AgentCore Memory almacena eventos a corto plazo por recurso de memoria, actor y sesión. Las estrategias a largo plazo pueden conservar hechos extraídos, preferencias, resúmenes y aprendizajes para interacciones futuras.
Zenity afirma que el rol comprometido podía enumerar actores y sesiones, y después llamar a ListEvents para recuperar contenido de conversaciones. Como esos permisos cubrían recursos de memoria comodín, los investigadores supuestamente accedieron a conversaciones pertenecientes a otros agentes y usuarios.
El material expuesto podía incluir información personal, código fuente, planes internos, registros de clientes o credenciales pegadas durante la resolución de problemas. La plataforma no puede determinar si un secreto introducido en una conversación debería haber estado allí. La autorización debe impedir que cargas de trabajo no relacionadas lean la sesión desde el principio.
Los permisos de escritura crearon una amenaza de integridad independiente. Zenity descubrió que el rol podía crear y eliminar eventos de memoria. Un atacante podría inyectar contexto falso en una sesión activa, eliminar resultados de herramientas o influir en lo que el agente creía que había ocurrido.
Este riesgo difiere del robo ordinario de datos. Un agente manipulado puede seguir presentándose como un servicio empresarial de confianza mientras actúa según contexto proporcionado por un atacante. Es posible que los usuarios no vean la instrucción hostil porque se encuentra dentro del estado de sesión almacenado, en lugar de en su prompt visible.
AWS comunicó a Zenity el 25 de febrero que su equipo estaba abordando el problema subyacente. Los investigadores volvieron a comprobarlo el 22 de junio e informaron que el rol predeterminado seguía sin cambios. Esa cronología dejó el rol amplio en el centro de la cadena sin resolver durante varios meses.
Durante una revisión final el 29 de septiembre, Zenity encontró restricciones sustanciales. Los investigadores afirmaron que AWS había eliminado permisos que permitían la invocación entre entornos de ejecución, el acceso a conversaciones privadas y la recuperación desde Secrets Manager. También se restringieron otros permisos.
Esa corrección cambia de forma marcada la evaluación actual del riesgo. La cadena publicada documenta lo que los investigadores lograron con configuraciones predeterminadas anteriores, no demuestra que los permisos idénticos sigan asignados hoy. Los roles creados por clientes, las políticas copiadas y los despliegues más antiguos aún merecen una revisión directa.
El aislamiento gestionado se encontró con una realidad de permisos excesivos
AgentCorruption expuso un conflicto entre la promesa de aislamiento de AgentCore y las rutas de autorización compartidas que rodeaban cada entorno de ejecución aislado.
AWS lanzó AgentCore para disponibilidad general en octubre de 2025, describiéndolo como infraestructura para ejecutar agentes de forma segura a escala. La plataforma combinaba aislamiento de ejecución con identidad, memoria, gateways, automatización de navegadores, ejecución de código y observabilidad.
Cada capacidad resuelve un problema real de despliegue. Los agentes necesitan estado entre conversaciones, credenciales para servicios conectados, acceso a herramientas gobernado y trazabilidad para acciones impredecibles. Construir todos esos componentes de forma independiente aumenta el coste y la complejidad.
Sin embargo, la integración también crea dependencias de seguridad. Un runtime puede estar aislado computacionalmente mientras su rol de ejecución puede invocar otro runtime. Un almacén de tokens puede mantener los secretos fuera del código de la aplicación, mientras que una identidad con permisos excesivos puede solicitar esos secretos.
Esta es la inversión central de Zenity AgentCorruption. Los controles conectados de la plataforma gestionada estaban destinados a respaldar un uso seguro en producción. Bajo las configuraciones predeterminadas probadas, esas mismas conexiones supuestamente propagaron el compromiso a través de los límites entre servicios.
Las actuales prácticas de seguridad de runtimes de AWS reconocen esta distinción de forma más directa. La documentación advierte a los clientes que no usen en producción las políticas de desarrollo generadas por CLI. Recomienda ARN de runtime específicos en lugar de declaraciones de recursos con comodines.
La guía también indica que un rol de ejecución debe tener privilegios iguales o menores que los de los principales autorizados para invocarlo. Esa regla ofrece una forma útil de evaluar agentes públicos. Si un usuario anónimo puede invocar un runtime, el runtime no debería heredar autoridad no disponible para los usuarios anónimos.
La accesibilidad pública no convierte automáticamente a un agente en inseguro. Cambia el nivel de confianza de cada instrucción que llega al modelo. El rol de ejecución debe asumir que parte de la entrada aceptada será maliciosa, engañosa o diseñada para manipular herramientas.
La autenticación ayuda a identificar a quienes realizan llamadas, pero no elimina la inyección de prompts. Una cuenta legítima de cliente puede enviar instrucciones hostiles. Documentos y páginas web comprometidos también pueden entregar inyecciones indirectas de prompts después de que el usuario pida a un agente que los resuma.
Los controles de gateway pueden reducir la exposición al validar las solicitudes antes de que lleguen a un runtime. Los guardrails pueden detectar patrones de ataque conocidos, mientras que los interceptores pueden restringir operaciones según la identidad y el contexto. Estos controles solo funcionan cuando quienes realizan llamadas no pueden omitir el gateway e invocar el runtime directamente.
La guía de seguridad de AgentCore ahora recomienda restringir la invocación del runtime al rol de ejecución del gateway cuando este sea el punto de entrada previsto. Este enfoque traslada la autorización fuera del ciclo de decisión del modelo. El agente no puede convencer al sistema para eludir una denegación de IAM.
La delimitación de recursos de IAM sigue siendo el límite de contención más sólido. Un agente de atención al cliente no debería recibir permiso comodín para invocar todos los runtimes. Un permiso de escritura en memoria debería identificar el recurso de memoria específico, el ámbito del actor y la necesidad de negocio siempre que el servicio admita esa precisión.
El mismo razonamiento se aplica a los repositorios de contenedores y los registros. Los metadatos operativos suelen parecer menos sensibles que los datos de aplicación. Sin embargo, los nombres, identificadores, endpoints y patrones de repositorio pueden convertirse en un sistema de descubrimiento para el movimiento lateral.
Las organizaciones también necesitan separación por nivel de confianza. Los agentes públicos y los agentes internos no deberían compartir roles de ejecución solo porque una herramienta de configuración facilite esa configuración. Las funciones sensibles pueden dividirse entre cuentas o regiones de AWS cuando los controles a nivel de cuenta ofrezcan un aislamiento más claro.
Ningún filtro de prompts puede garantizar que un modelo rechazará todas las variantes maliciosas. Los modelos interpretan significado en lugar de aplicar una gramática finita de comandos. Los atacantes pueden reformular solicitudes, ocultar instrucciones dentro de datos recuperados o explotar conflictos entre el contexto del sistema y el del usuario.
Esta limitación no hace que el despliegue de agentes sea impracticable. Cambia dónde deberían depositar su confianza los defensores. Las defensas a nivel de modelo pueden reducir la manipulación exitosa, mientras que los controles deterministas de la nube limitan lo que puede hacer un modelo manipulado.
Los equipos deberían tratar los prompts como entrada no confiable y las herramientas como interfaces privilegiadas. Cada llamada a una herramienta necesita una decisión de autorización basada en el usuario autenticado, el recurso solicitado y la operación permitida. La decisión del modelo de llamar a una herramienta nunca debería servir por sí misma como autorización.
Para las organizaciones que documentan estas decisiones, un conjunto consultable de bases de conocimiento de ingeniería puede ayudar a conectar la propiedad de los runtimes, las políticas de IAM, los modelos de amenazas y los procedimientos de incidentes. Ese registro cobra importancia cuando varios equipos despliegan agentes mediante cuentas compartidas en la nube.
El envenenamiento de memoria convirtió una brecha en control persistente
La parte más trascendental de la cadena no fue el robo de credenciales, sino la capacidad de corromper lo que agentes de confianza recordarían más adelante.
AgentCore Memory admite estado a corto y largo plazo. La memoria a corto plazo registra eventos turno a turno dentro de una sesión. La memoria a largo plazo extrae información reutilizable para que un agente pueda recordar preferencias, hechos, resúmenes o lecciones previas.
Esa persistencia mejora la usabilidad. Un agente de soporte puede recordar un caso sin resolver, mientras que un asistente de trabajo puede conservar preferencias de formato. También crea un canal de entrada duradero que puede influir en decisiones futuras.
El estudio sobre envenenamiento de memoria de Zenity afirma que el rol robado podía descubrir identificadores de memoria a través de los registros de CloudWatch. Después podía enumerar actores, sesiones y estrategias de memoria configuradas.
Los investigadores usaron CreateEvent para añadir contenido hostil a las conversaciones de otros agentes. La extracción de memoria procesó esos eventos y convirtió su contenido en registros a largo plazo. Las sesiones futuras podían recuperar esos registros como contexto de confianza.
Por tanto, un atacante no necesitaba repetir la inyección de prompts original en cada interacción. Una instrucción implantada podía sobrevivir más allá de la sesión comprometida y afectar conversaciones posteriores. La interfaz visible seguiría pareciendo el agente oficial de la organización.
Zenity describe esto como mando y control persistente. Esa expresión debe interpretarse como la caracterización de los investigadores sobre su entorno de prueba. El resultado conductual exacto depende de la configuración de memoria, la lógica de recuperación, el comportamiento del modelo, las herramientas y los controles de autorización.
La primitiva demostrada sigue siendo grave. Una preferencia falsa podría indicar a un agente que envíe datos a una dirección controlada por el atacante. Un hecho fabricado podría redirigir un flujo de trabajo, mientras que un resumen envenenado podría tergiversar la aprobación previa de un cliente.
La manipulación del historial a corto plazo añade riesgos inmediatos. Un evento de asistente insertado puede parecerle al modelo algo que decidió anteriormente. Un resultado de herramienta eliminado puede borrar evidencia que de otro modo detendría una acción insegura.
La seguridad tradicional de las aplicaciones suele tratar los registros y el historial como evidencia tras un incidente. Los sistemas de agentes pueden incorporar activamente el historial almacenado en decisiones futuras. Por lo tanto, los fallos de integridad en esos datos pueden cambiar la ejecución, no solo dificultar la investigación.
La memoria también complica la recuperación. Rotar las credenciales robadas detiene el acceso continuado a la API, pero no elimina automáticamente todos los registros envenenados. Los equipos de respuesta deben identificar qué sesiones, eventos, resúmenes y memorias extraídas fueron tocados por la identidad comprometida.
La actual guía de memoria de AWS recomienda validación de entradas, guardrails antes de la persistencia y pruebas periódicas de inyección de prompts. También enfatiza las políticas de privilegio mínimo para los recursos de memoria.
Esos controles deberían complementarse con procedencia. Un registro a largo plazo debe conservar suficientes metadatos para mostrar qué usuario, agente, sesión y proceso de extracción lo crearon. Los equipos de seguridad necesitan una forma eficiente de poner en cuarentena las memorias asociadas a una identidad comprometida.
Las acciones de alto riesgo no deberían basarse en el contexto recordado como prueba de autorización. Un agente podría recordar que un usuario prefiere una cuenta bancaria determinada, pero una transferencia aún exige una aprobación actual e independientemente verificada. La memoria puede guiar un flujo de trabajo sin autorizarlo.
Las organizaciones también deberían separar los tipos de datos según sus consecuencias. Las preferencias sobre estilo de redacción presentan menos riesgo que las instrucciones de pago, las concesiones de acceso o las direcciones de destino. Las memorias sensibles requieren reglas de creación más estrictas, retención más corta y una revisión más sólida.
La monitorización debe cubrir las escrituras además de las lecturas. Ráfagas inusuales de CreateEvent, acceso a memoria entre agentes o cambios que afecten a muchos actores pueden señalar abuso. CloudTrail, los registros de aplicaciones y los datos de observabilidad de AgentCore deberían alimentar alertas vinculadas al comportamiento esperado de la carga de trabajo.
Aquí es donde el incidente va más allá de AWS. Cualquier plataforma de agentes que combine memoria persistente con herramientas enfrenta un problema de integridad similar. Los detalles de implementación difieren, pero la cuestión de confianza permanece constante.
¿Qué información puede recordar el agente, quién puede escribirla y qué decisiones pueden depender de ella más adelante? AgentCorruption demuestra que respuestas incompletas pueden convertir un punto de apoyo temporal en una influencia continua.
Lo que los clientes de AgentCore deberían verificar ahora
La cadena histórica completa se redujo antes de su publicación, pero los permisos definidos por los clientes y las configuraciones más antiguas determinan la exposición restante de cada despliegue.
La primera comprobación es el rol de ejecución asociado a cada runtime de AgentCore. Los equipos deberían enumerar las acciones y los recursos permitidos, y luego eliminar los permisos no relacionados con la función documentada del runtime. Los comodines merecen una justificación específica en lugar de una aceptación rutinaria.
Los roles de producción no deberían heredar políticas generadas para prototipos. AWS ahora etiqueta los permisos generados por CLI como comodidades de desarrollo y aconseja a los clientes crear alternativas con un alcance limitado. Un despliegue de prueba exitoso no demuestra que su rol pertenezca a producción.
La segunda comprobación es la aplicación de MMDSv2. Los runtimes actuales deberían establecer requireMMDSV2 en true dentro de su configuración de metadatos. Los equipos deberían verificar la configuración desplegada en lugar de asumir que una actualización de plataforma corrigió adecuadamente todos los runtimes históricos.
MMDSv2 debería seguir considerándose una capa. Si un agente controla legítimamente un cliente HTTP flexible, un shell o un intérprete de código, puede realizar solicitudes que las protecciones SSRF simplistas asumían que los atacantes no podían construir. La política de red debería bloquear el acceso innecesario a los endpoints de metadatos.
La tercera comprobación es la accesibilidad entrante. Los equipos deberían identificar qué runtimes aceptan invocación pública directa, basada en IAM o basada en JWT. Los agentes públicos necesitan los roles más limitados porque su entrada procede de la audiencia menos confiable.
Cuando AgentCore Gateway proporciona aplicación de políticas, la invocación directa del runtime debería estar restringida. De lo contrario, un atacante podría omitir los guardrails del gateway y llamar al endpoint del runtime mediante otra ruta autorizada. La autenticación y los identificadores de usuario deben derivarse de principales verificados.
La cuarta comprobación cubre el movimiento lateral. Un runtime no debería invocar agentes no relacionados, enumerar grupos regionales de registros, extraer imágenes ECR no relacionadas ni enumerar recursos de memoria. Esos permisos deberían aislarse por ARN de runtime y función de negocio.
La quinta comprobación es la confidencialidad de las conversaciones. Los equipos de seguridad deberían probar si una identidad de runtime puede enumerar actores, sesiones o eventos que pertenecen a otra carga de trabajo. También deberían verificar si las políticas de recursos y las políticas de identidad generan conjuntamente la denegación prevista.
La sexta comprobación es la integridad de la memoria. Los equipos deberían inventariar los principales con CreateEvent, DeleteEvent y acceso a memoria a largo plazo. Las alertas deberían distinguir las escrituras normales de sesiones de usuario de los cambios entre agentes o de gran volumen.
La séptima comprobación se refiere a las credenciales almacenadas. AgentCore Identity puede mantener tokens de terceros fuera del código de la aplicación, pero IAM sigue controlando quién puede recuperarlos. Los roles de runtime no deberían tener acceso amplio a claves de API ni a valores de Secrets Manager.
Los investigadores que evalúan una posible exposición histórica necesitan más que una instantánea de las políticas actuales. Deben examinar los eventos de CloudTrail, los registros de invocación en tiempo de ejecución, la actividad relacionada con metadatos, las extracciones de imágenes de ECR, las llamadas a la API de memoria y el acceso a Secrets Manager durante el periodo pertinente.
Las credenciales temporales caducan, pero sus efectos pueden persistir. Un atacante podría copiar código fuente, conservar un secreto obtenido, modificar el historial de sesiones o insertar memoria a largo plazo antes de que caduquen. Los planes de respuesta deben incluir la rotación de credenciales y la validación del estado.
Dos incertidumbres siguen siendo centrales. Los hallazgos de Zenity proceden de despliegues controlados por investigadores, y ninguna evidencia pública citada aquí establece una explotación generalizada en entornos de clientes. AWS no ha publicado un boletín de seguridad específico que describa la cadena completa de AgentCorruption.
Esta ausencia debe evitar afirmaciones exageradas, no desestimar la investigación. Zenity publicó ejemplos detallados de permisos, rutas de explotación y fechas de divulgación. La documentación actualizada de AWS confirma de forma independiente que el código en tiempo de ejecución puede acceder a credenciales de metadatos y que las políticas de desarrollo amplias no son adecuadas para producción.
La primera señal que conviene vigilar es si AWS emite un aviso formal, una retrospectiva o guías adicionales para la migración de políticas. Esa documentación aclararía las configuraciones afectadas y si los clientes deben corregir manualmente roles antiguos.
La segunda señal es una mayor restricción del acceso a metadatos desde herramientas controladas por agentes. Un control que impida a las cargas de trabajo en tiempo de ejecución alcanzar los endpoints de credenciales reduciría la dependencia del comportamiento del modelo. Una política de salida granular también podría contener otras rutas de SSRF.
La tercera señal es una protección de memoria visible para el cliente. Una mejor procedencia, autorización de escritura con alcance limitado, alertas de integridad y herramientas de cuarentena masiva facilitarían la detección y reversión del envenenamiento de memoria. Estas capacidades importan a medida que la memoria a largo plazo se integra en flujos de trabajo críticos para el negocio.
En última instancia, Zenity AgentCorruption pone a prueba una afirmación más amplia detrás de los agentes empresariales. La infraestructura gestionada puede reducir la complejidad operativa, pero no puede fusionar de forma segura identidad, memoria y acceso a herramientas en un único rol ampliamente confiable.
Los desarrolladores deberían plantear ahora una pregunta concreta sobre cada agente desplegado: ¿qué ocurre después de que el modelo siga la peor instrucción que pueda recibir? Rastrear las llamadas a herramientas resultantes, las credenciales, los permisos, los agentes alcanzables y las memorias que se pueden escribir.
Si la respuesta va más allá de la tarea limitada de ese agente, trate el alcance como un defecto de seguridad activo. Revise el rol, aísle los entornos de ejecución públicos, pruebe los límites de la memoria y confirme directamente los valores predeterminados actuales de AWS. El agente más seguro no es el que siempre rechaza la manipulación. Es aquel cuyos permisos en la nube impiden que una respuesta manipulada se convierta en un incidente de alcance para toda la cuenta.
