AgentCorruption, publicado por Zenity el 8 de octubre, describe una ruta histórica desde un agente Amazon Bedrock AgentCore público hacia runtimes vecinos y memoria persistente. La condición era un rol de ejecución amplio en la misma cuenta AWS y región, no intrusión en otros clientes ni robo de contraseña administrativa.
Una petición de red inducida por prompt expuso credenciales temporales; IAM amplificó su alcance. Antes de publicar, investigadores vieron restricciones importantes en el rol predeterminado. La investigación demuestra fallos de configuraciones antiguas probadas, no vulnerabilidad completa de toda instalación actual.
El prompt cruzó hacia una identidad de carga confiable
AgentCore, disponible generalmente desde octubre de 2025, combina runtimes aislados, identidad, memoria, gateways, navegador, ejecución de código y observabilidad. Resuelve problemas reales, pero crea dependencias de autorización fuera de la microVM.
En la prueba, una herramienta HTTP siguió instrucciones no fiables y pidió metadatos locales. AWS usa un servicio link-local; las microVM Firecracker de AgentCore ofrecen MMDS relacionado. Credenciales temporales permiten legítimamente recursos aprobados sin claves permanentes en imágenes.
La petición salió del interior, se trató como local y devolvió clave de acceso, secreta y token temporal. Es SSRF: inducir a un servidor a contactar un destino inaccesible directamente al atacante. La inyección dio intención, la herramienta capacidad de red y los metadatos identidad.
Texto inseguro solo no produciría la cadena. Bloquear acceso innecesario de herramientas a metadatos la interrumpiría; un rol estrecho limitaría efectos del robo. AWS indica que código o actores dentro de la microVM pueden alcanzar credenciales y exige mínimos privilegios.
Zenity notificó metadatos el 25 de diciembre de 2025. AWS cerró como informativo el 12 de abril de 2026, diciendo que nuevos despliegues usaban IMDSv2 desde el 14 de febrero. El token previo bloquea muchos SSRF clásicos, pero herramientas flexibles pueden hacer también ese paso. Zenity lo ve como fricción sin resolver confianza.
La guía actual dice rechazar runtimes sin MMDSv2 desde el 30 de junio de 2026. Clientes deben comprobar configuración real, incluido requireMMDSV2, sin asumir migración histórica completa. Endurecer metadatos es una capa, no justificación de permisos excesivos al código legítimo.
Los permisos amplios hicieron útil la entrada en otros recursos
El segundo informe, del 12 de enero, trató el rol. Listas regionales de grupos CloudWatch y patrones AgentCore revelaban identificadores de runtimes y memorias sin inventario previo. Permisos ECR y repositorios previsibles conectaban imágenes, con posible exposición de código y configuración.
El permiso wildcard probado alcanzaba agentes privados de la misma cuenta y región. Un bot público podía llegar a un agente de facturación sensible. Zenity mostró herramientas y billing.json en una prueba por API legítimas, no otro exploit independiente.
Los derechos de memoria permitían según el informe listar actores, sesiones y eventos ajenos. Conversaciones podían contener datos personales, código, planes, clientes o credenciales pegadas durante soporte. Si un secreto debía estar en conversación no decide si una carga ajena debe leerlo.
Crear y borrar eventos amenazaba integridad además de confidencialidad. Contexto falso podía entrar en sesiones y resultados reales desaparecer. El aislamiento computacional no impedía invocar o modificar recursos con la misma identidad; la autorización requiere aislamiento distinto.
AWS dijo el 25 de febrero que trabajaba en el problema. Según investigadores, el 22 de junio el rol seguía igual, pero el 29 de septiembre estaba restringido: eliminados invocación cruzada, conversación privada y Secrets Manager, con otros recortes.
Eso limita afirmaciones actuales. Roles propios, políticas copiadas y despliegues antiguos merecen revisión, pero el pasado no prueba los mismos permisos hoy. Fueron entornos controlados; las fuentes citadas no establecen explotación amplia de clientes. AWS no había publicado boletín específico de toda la cadena.
La memoria podía mantener influencia tras caducar credenciales
La memoria corta guarda eventos; estrategias largas extraen hechos, preferencias, resúmenes y lecciones. Recordar casos o formatos ayuda, pero convierte historial en entrada de decisiones futuras, no solo evidencia posterior.
Zenity describe identificadores por logs, enumeración de actores, sesiones y estrategias e inserción de eventos hostiles. La extracción convertía contenidos en registros largos recuperados como contexto fiable. No hacía falta repetir la inyección inicial en cada interacción.
“Mando y control persistente” es la descripción de los investigadores en su prueba. El comportamiento depende de memoria, recuperación, modelo, herramientas y derechos. Destino falso, aprobación fabricada o resumen contaminado ilustran riesgo, no control garantizado de todos los agentes por todo recuerdo.
Un evento de asistente insertado parece decisión anterior; un resultado borrado quita evidencia contraria. Caducidad o rotación detiene futuras API, pero no borra código copiado, secretos o estado envenenado. Recuperar exige identificar sesiones, eventos, resúmenes y memorias afectados.
AWS recomienda validación, controles antes de persistir, pruebas de inyección y privilegios mínimos. Procedencia debe señalar usuario, agente, sesión y extracción para permitir cuarentena. Preferencias de estilo difieren de destinos de pago o concesiones de acceso, que exigen creación, retención y revisión más fuertes.
Recordar no autoriza una acción peligrosa. Una cuenta bancaria preferida no sustituye aprobación actual independiente. Escrituras y borrados deben vigilarse junto con lecturas, volúmenes anómalos y cruces entre agentes, con CloudTrail, logs y observabilidad AgentCore.
La autorización pertenece fuera del juicio del modelo
AWS desaconseja políticas de desarrollo amplias generadas por CLI en producción y pide ARN concretos, no wildcard. Los privilegios del rol no deben superar los de sujetos autorizados a invocarlo. Un agente público necesita autoridad especialmente reducida.
No todo agente público es inseguro, pero el lenguaje sigue sin confianza, incluso solicitudes hostiles autenticadas o instrucciones indirectas en páginas y documentos. Autenticación identifica al llamante, no asegura todo significado aportado.
Gateways, guardrails e interceptores ayudan si otra ruta permitida no los evita. Si gateway es entrada, invocación directa debe limitarse a su rol. La identidad debe venir de sujetos verificados, no etiquetas del modelo o autodeclaraciones.
IAM por recurso puede impedir otros agentes, imágenes, logs regionales y memorias. Cargas públicas e internas no deben compartir roles por comodidad; cuentas o regiones separadas aclaran límites sensibles.
Herramientas son interfaces privilegiadas, no derechos concedidos por la decisión del modelo. Autorización debe evaluar usuario, recurso y operación independientemente. Registros técnicos unen responsables, políticas, amenazas e incidentes, sin sustituir denegación impuesta.
La revisión actual necesita historia y estado persistente
Una revisión acotada cubre roles, metadatos, entradas públicas/IAM/JWT, bypass, derechos entre runtimes, ECR y logs, memoria entre usuarios, eventos, tokens y Secrets Manager. Políticas de recursos e identidad deben probarse juntas para denegación esperada, no juzgarse por prototipo funcional.
Exposición histórica exige eventos del periodo: CloudTrail, invocaciones, metadatos, imágenes, memorias y secretos, no solo políticas actuales. Credenciales temporales dejan efectos persistentes; rotación y validación se complementan.
Próximas evidencias útiles serían aviso o migración formal AWS, mayor separación de herramientas y endpoints de credenciales, procedencia visible, escrituras limitadas, alertas y cuarentena masiva. Son señales por verificar, no funciones supuestas entregadas.
La cuestión amplia es qué sigue siendo posible cuando el modelo obedece una instrucción maliciosa. Lo gestionado reduce complejidad, pero no puede unir herramientas, identidad y memoria en un rol ampliamente fiable. Límites deterministas deben impedir que una respuesta manipulada se convierta en incidente de toda la cuenta, aunque falle el modelo.
Fuentes y lecturas relacionadas
Cadena estudiada por Zenity · Credenciales AWS · Análisis del rol Zenity · Seguridad runtime AWS · Lectura: bases de conocimiento técnico · Estudio de envenenamiento de memoria · Prácticas de memoria AWS · Noticia AgentCorruption