El agente de AWS Continuum explotó 33 de 37 vulnerabilidades recién divulgadas partiendo solo de una URL y una pista de una línea, sin acceso a pruebas de concepto públicas.
AWS publicó los resultados de un benchmark interno en el que su agente autónomo de penetration testing — ahora integrado en AWS Continuum — enfrentó 37 CVEs reales divulgados entre 2025 y 2026, cada uno empaquetado como un objetivo containerizado con una flag oculta en el punto de explotación previsto. El agente capturó 35 de 37 flags, con una tasa de éxito del 94,6%. De esas capturas, 33 (89,2%) fueron confirmadas como explotaciones de extremo a extremo a través de la vulnerabilidad prevista, tras una auditoría de integridad que comparó la trayectoria del agente contra la prueba de concepto canónica de cada CVE. Dos capturas fueron reclasificadas como fuera del camino previsto y contabilizadas como no resueltas. Los dos intentos fallidos ocurrieron cuando el agente explotó el bug pero derribó el objetivo antes de poder leer la flag — un escenario que los guardrails de producción del sistema están diseñados para evitar en entornos reales.
Cómo funciona un benchmark que intenta no estar contaminado por datos de entrenamiento
AWS diseñó este benchmark como alternativa a suites públicas como CVEBench y XBOW, que según la compañía están efectivamente saturadas: los modelos de lenguaje actuales reconocen esas vulnerabilidades casi de inmediato porque los bugs y sus write-ups ya están en los datos de entrenamiento. El problema es que una vez que un CVE y su exploit público llegan a un paper o a un repositorio indexado, los modelos de frontera muy probablemente ya ingirieron esa información, y cualquier puntaje posterior combina dos cosas que deberían medirse por separado — si el agente puede explotar el bug y si el modelo ya memorizó la respuesta.
El enfoque de AWS ataca la contaminación por dos rutas. Primero, recencia: los desafíos se construyen a partir de CVEs divulgados lo suficientemente reciente como para que una solución de extremo a extremo sea improbable en los datos de entrenamiento del modelo. Segundo, desactivación de búsqueda de CVE en tiempo de ejecución: el agente no puede consultar una prueba de concepto pública durante la explotación, trabaja solo con el objetivo en vivo. AWS aclara que esto reduce la contaminación, no la elimina — CVEs recientes todavía pueden filtrarse en forma de advisories parciales o fragmentos de PoC — pero es un paso más allá de los benchmarks estáticos que se publican una vez y quedan congelados.
Qué tuvo que hacer el agente para capturar cada flag
Cada desafío del benchmark es un paquete autocontenido: un objetivo levantado desde docker-compose en un sandbox aislado, corriendo la versión afectada del software upstream real o una reproducción mínima fiel, con una flag sembrada en el sink previsto — que puede ser una fila de base de datos, una cookie de sesión de administrador, una API de configuración interna o un archivo accesible solo a través del bug. El agente nunca ve la prueba de concepto canónica, que AWS usa únicamente para auditar las victorias. Los metadatos que recibe son mínimos: URL del endpoint, credenciales semilla si las hay, y una pista de una línea.
Cada ejecución pasa por siete etapas fijas. El objetivo arranca desde docker-compose, un crawler mapea la superficie de ataque (endpoints, parámetros, puntos de entrada), un enjambre de agentes especialistas sondea esa superficie y levanta riesgos candidatos, cada riesgo se confirma o rechaza antes de intentar cualquier explotación, el agente de explotación intenta el exploit usando shell, runtime de Python, navegador real y listener de callback fuera de banda, y si la flag aparece en la salida del agente, la muestra se marca como capturada. Cada captura pasa por una auditoría de integridad — manual y automatizada — que compara la trayectoria del agente contra el PoC canónico para confirmar que la vulnerabilidad prevista fue realmente explotada. El límite de tiempo por muestra es de 10 horas.
Los objetivos abarcan ocho clases de vulnerabilidad en software de producción real
Los 37 CVEs cubren tipos de software que corren en servicios de producción: frameworks web, un registro de contenedores, plataformas de machine learning y AI, un stack de ecommerce, una API tRPC, varias plataformas de medios y una consola de administración LDAP. Entre todos, abarcan ocho clases de vulnerabilidad — desde SQL injection hasta server-side request forgery, pasando por cadenas de cross-site scripting multi-paso que terminan en cookies de administrador. Cada resultado reportado es una flag capturada detrás de un exploit funcional, producido desde una posición de bajo privilegio o sin autenticación, no desde un reporte de bug.
Los dos fallos del agente ocurrieron en escenarios donde encontró y explotó el bug, pero derribó el objetivo antes de poder leer la flag. AWS señala que los guardrails no destructivos que gobiernan los compromisos de producción mantienen ese tipo de comportamiento fuera de los sistemas de clientes. Las dos capturas reclasificadas fueron casos donde el agente tomó un camino distinto al previsto — AWS endureció esos desafíos y los cuenta como no resueltos.
Por qué esto importa para equipos de seguridad en América Latina que dependen de pentesting manual
La capacidad de un agente autónomo de explotar 89% de vulnerabilidades reales sin acceso a exploits públicos plantea una pregunta concreta para equipos de seguridad en la región: cuánto del pentesting manual que hoy se hace en México, Brasil, Argentina o Chile podría automatizarse con este nivel de efectividad, y qué pasa con el 11% restante que el agente no resolvió. La respuesta tiene implicancias directas para presupuestos de seguridad en empresas que hoy contratan pentesting externo por proyecto — si un agente puede cubrir la mayoría de las vulnerabilidades conocidas en menos de 10 horas por objetivo, el valor diferencial del pentester humano se desplaza hacia escenarios de lógica de negocio compleja, cadenas de ataque no documentadas o contextos donde derribar el objetivo no es una opción aceptable ni siquiera en prueba.
Para proveedores de servicios gestionados de seguridad en la región, esto también es una señal de cambio en el tipo de capacidad que van a tener que ofrecer: no solo ejecutar pruebas de penetración, sino interpretar qué significa que un agente haya fallado en un caso específico, o validar que una captura automatizada realmente explotó la vulnerabilidad prevista y no un camino lateral. La auditoría de integridad que AWS describe — comparar la trayectoria del agente contra el PoC canónico — es exactamente el tipo de trabajo que no se automatiza con el agente mismo.
Nuestro análisis
Este benchmark no es una demostración de capacidad general de agentes de IA en ciberseguridad — es una medición controlada de qué tan bien un agente específico de AWS puede explotar CVEs recientes en un entorno containerizado con flags sembradas, partiendo de metadatos mínimos y sin acceso a exploits públicos. La diferencia entre 94,6% de flags capturadas y 89,2% de explotaciones confirmadas como válidas es el dato más revelador: seis puntos porcentuales de distancia entre «el agente obtuvo la flag» y «el agente explotó la vulnerabilidad prevista» muestran que incluso en un entorno de prueba diseñado para ser auditable, hay margen para falsos positivos o caminos no previstos. Eso es exactamente lo que un equipo de seguridad necesita saber antes de confiar en un agente autónomo en producción.
El enfoque de AWS para reducir contaminación — usar CVEs recientes y desactivar búsqueda en tiempo de ejecución — es un paso adelante respecto a benchmarks estáticos, pero la propia compañía reconoce que no es una garantía: advisories parciales, fragmentos de PoC o discusiones técnicas pueden filtrarse en datos de entrenamiento incluso para vulnerabilidades recién divulgadas. Lo que todavía no sabemos es qué tan rápido se degrada la efectividad del agente a medida que los CVEs envejecen y sus exploits se vuelven conocimiento común en la comunidad de seguridad — y si AWS planea refrescar este benchmark con la misma cadencia que se divulgan nuevas vulnerabilidades, o si esto es una instantánea de 2025-2026 que quedará congelada como los benchmarks públicos que critica. Si el objetivo es medir capacidad de explotación autónoma sin memorización, el benchmark tiene que moverse tan rápido como el ciclo de divulgación de CVEs — ¿puede AWS sostener esa velocidad de actualización sin que el costo operativo haga inviable el ejercicio?