Los puntos ciegos del pentesting agéntico y cómo cerrarlos

Durante años, los equipos de seguridad dispusieron de varias semanas entre la publicación de un CVE y su explotación por parte de los atacantes. Esa ventana se ha ido reduciendo año tras año. Con la llegada de los modelos de clase Mythos, los atacantes pueden weaponizar un nuevo CVE en cuestión de horas, dejando a los equipos de seguridad muy poco tiempo para determinar si están expuestos.

Aquí entra en juego el testing ofensivo, que tradicionalmente se ha ejecutado según un calendario. Con el tiempo, ese calendario se ha ido ajustando: las pruebas anuales se convirtieron en trimestrales, y las herramientas automatizadas permitieron pruebas semanales. Cada avance redujo el tiempo que un cambio podía permanecer sin probar. El pentesting automatizado tradicional funcionaba bien cuando la explotación tardaba semanas. Ahora que los atacantes han dado un gran salto, el testing ofensivo también lo está dando.

Ese salto es el pentesting agéntico. Es la vanguardia del testing ofensivo actual, pero tiene puntos ciegos. Este artículo analiza dónde están y cómo cerrarlos.

Cómo debería funcionar el pentesting agéntico

Un pentest manual suele pasar por varias fases: reconocimiento, evaluación de vulnerabilidades, acceso inicial, post-explotación y generación de informes. Las herramientas de pentesting automatizado tradicional siguen las mismas fases. Incluso antes del auge de los LLM, algunas herramientas avanzadas usaban aprendizaje automático para elegir el siguiente paso. Por ejemplo, hace cinco años construimos nuestro producto Attack Path Validation (APV) con un motor de decisión de este tipo. Pero los agentes de IA van más allá.

En el pentesting agéntico, uno o varios agentes de IA llevan a cabo un pentest paso a paso. En nuestro producto de pentesting agéntico, Picus Swarm utiliza cinco agentes especializados orquestados por Numi AI. Los agentes de pentesting evalúan los hallazgos y el contexto de la organización para elegir dinámicamente el siguiente paso. Esa creatividad les permite encontrar cadenas de explotación mucho más rápido que un pentester humano, incluidas algunas que un humano podría pasar por alto. Sin embargo, la creatividad tiene un costo.

Ejecutar todo de forma agéntica consume muchos tokens y los resultados varían de una ejecución a otra. Incluso cuando nada ha cambiado en el entorno, un agente puede fallar al explotar una vulnerabilidad cinco veces y tener éxito en la sexta. Realizar docenas de pruebas para estar seguro resulta costoso, y en una organización grande con miles de endpoints, una sola ejecución agéntica puede llevar semanas.

Por eso sigue siendo necesario el pentesting automatizado determinista. Es menos creativo, pero ofrece pruebas consistentes, cuesta menos y termina más rápido, por lo que puede ejecutarse con mucha más frecuencia. Sigue pasos repetibles, lo que permite a los equipos comparar ejecuciones a lo largo del tiempo y volver a probar correcciones de forma fiable.

El enfoque correcto ofrece ambos. Ejecute pruebas deterministas con frecuencia para una cobertura predecible y pruebas agénticas a intervalos establecidos. La frecuencia depende de las necesidades y la tolerancia al riesgo de su organización. Picus Autonomous Pentesting puede ejecutarse en cualquiera de los dos modos, totalmente agéntico o determinista, y se adapta a su contexto, riesgos y cambios en el panorama de amenazas y en su entorno. El pentesting agéntico es valioso y la necesidad es real. Pero tiene límites que conviene entender.

Vea qué cubre su pentesting y qué no

En la mayoría de las implementaciones, el pentesting automatizado cubre solo una de las seis superficies que necesita validar. Este whitepaper muestra qué queda sin probar, desde reglas de detección hasta la nube, la identidad y las barreras de seguridad de IA, por qué añadir IA no eleva ese techo, y tres preguntas que exponen la brecha.

El talón de Aquiles del pentesting agéntico: activos y exposiciones no testables

La mayor fortaleza del pentesting agéntico es también su límite. Prueba ejecutando ataques reales, por lo que solo puede probar aquello a lo que puede llegar de forma segura. Una investigación de Omdia encontró que las organizaciones solo prueban el 32% de su superficie de ataque en promedio.

Las restricciones de seguridad lo mantienen alejado de sistemas críticos. Un exploit real puede tumbar un servicio, corromper datos o provocar una conmutación por error. Por eso las guías PCI y NIST aconsejan a los probadores evitar exploits potencialmente disruptivos en sistemas de producción frágiles. La alcanzabilidad limita el resto. El agente solo puede probar aquello para lo que tiene una ruta de red, por lo que las zonas segmentadas y aisladas quedan fuera de su alcance.

Vimos esto en el entorno de un cliente. Sus escáneres marcaron una omisión de autenticación en nginx-ui (CVE-2026-33032) en 480 instancias. Dentro del alcance permitido, el pentesting agéntico solo pudo probar 120 de ellas. Confirmó que 80 eran explotables, mientras que 40 estaban bloqueadas. Las otras 360, tres de cada cuatro instancias afectadas, quedaron fuera de alcance y sin veredicto.

El caso de nginx-ui cubría un solo CVE. Si ampliamos la vista a todos los CVE de su entorno, aparece una segunda brecha. Incluso en activos a los que una herramienta de pentesting agéntico puede llegar, muchas vulnerabilidades no se pueden probar porque no hay un exploit que ejecutar. VulnCheck encontró que solo alrededor de una cuarta parte de los CVE de 2025 tenían código de prueba de concepto (PoC) o detalles de exploit. También descubrió que el 29% de las vulnerabilidades que confirmó como explotadas en 2025 lo fueron en o antes de sus fechas de publicación. Sin un exploit público que ejecutar, algunos equipos piden a un LLM que escriba uno. Sin embargo, un exploit no probado podría tumbar un servicio o corromper datos.

Así, el pentesting agéntico deja dos brechas: los activos a los que nunca llega, como esas 360 instancias, y las vulnerabilidades que no puede probar en los activos a los que sí llega, a menudo porque no hay un exploit que ejecutar. ¿Quiere el análisis técnico completo? Descargue el whitepaper.

Cómo la validación de explotabilidad cubre todos sus activos y exposiciones

En el caso de la omisión de nginx-ui comentado anteriormente, el pentesting agéntico dejó 360 de las 480 instancias afectadas sin respuesta. La validación de explotabilidad, ofrecida por Picus Exposure Validation, no intenta llegar a ellas con un exploit. Descompone el CVE en los comportamientos del atacante necesarios para explotarlo y prueba cada comportamiento contra sus controles de seguridad en vivo en cuestión de horas.

Debido a que el veredicto se basa en la evidencia de los controles en lugar de en una explotación exitosa, la falta de un PoC no se considera prueba de que un activo esté a salvo. Esto aborda ambas brechas. Combinado con el contexto de los activos, esa evidencia da un veredicto a las 360 instancias no probadas: 260 bloqueadas por controles y 100 probablemente explotables. Los 480 hallazgos brutos se convierten en 180 prioridades respaldadas por evidencia: 80 confirmadas como explotables mediante pentesting agéntico y 100 evaluadas como probablemente explotables mediante Exposure Validation. Así sabe qué hosts ya cubren sus controles y cuáles necesitan un control compensatorio hoy.

Tres métodos trabajando juntos para validar cada CVE y cada activo en horas

Ejecutar estos métodos como herramientas separadas puede producir hallazgos aislados o duplicados y prioridades contradictorias. Necesitan alimentar un modelo de hallazgos compartido, respaldado por evidencia y consciente del contexto, con una sola lista de pendientes y un solo resultado por exposición.

La plataforma Picus está construida sobre ese principio, con Autonomous Pentesting, Exposure Validation y Breach and Attack Simulation trabajando a partir de evidencia compartida. Cuando aparece un CVE crítico, Numi AI lo capta como una señal y los agentes de Picus Swarm se encargan del resto.

Descubrimiento. El CVE se enriquece con inteligencia de amenazas y se mapea a técnicas de atacante. Se identifican los activos afectados, su criticidad empresarial y los controles desplegados.
Validación. Autonomous Pentesting prueba los activos dentro del alcance, Breach and Attack Simulation prueba los controles y Exposure Validation evalúa cada activo afectado.
Movilización. Las mitigaciones de bajo riesgo se despliegan automáticamente. El resto se asigna a los responsables y cada corrección se revalida.

Todo el ciclo se ejecuta en horas, no en semanas.

La conclusión

Los atacantes con modelos de clase Mythos ahora pueden weaponizar un nuevo CVE en cuestión de horas. El pentesting agéntico es la forma más potente de probar como un atacante real, y cuando la misma plataforma también admite pruebas deterministas, las pruebas siguen siendo creativas y repetibles. Pero incluso juntos, estos métodos solo pueden probar aquello a lo que pueden llegar de forma segura.

Exposure Validation cubre el resto. Junto con Breach and Attack Simulation, las tres capacidades funcionan como una sola plataforma para validar cada CVE en cada activo en horas. ¿Quiere verlo en vivo? Se lo mostraremos. Solicite su demostración gratuita ahora.

Patrocinado y escrito por Picus Security.