Cómo gestionar el "Autonomous Continuous Attack" con Agentes IA en Offensive Security

Hoy os voy a contar lo que en FardaySec aprendimos construyendo un Pentester Autónomo basado en Inteligencia Artificial para hacer Continuos Attack a las empresas como parte de la gestión de la seguridad en el mundo de hoy. La confianza en el Pentesting Autónomo no se resuelve con un modelo más grande — se resuelve con evidencia, trazabilidad y gobernanza. Por eso el futuro no es Inteligencia Artificial reemplazando al pentester, o hacker, sino teniendo al hacker + Agente IA trabajando juntos.

Figura 1: Cómo gestionar el "Autonomous Continuous Attack"

con Agentes IA en Offensive Security

Hace aproximadamente un año y medio empezamos en Faraday con una pregunta bastante simple:

¿Hasta dónde podemos automatizar realmente el trabajo de un pentester utilizando Inteligencia Artificial?

No queríamos construir otro scanner. Tampoco un chatbot capaz de explicar vulnerabilidades. Queríamos darle a un agente un objetivo, herramientas ofensivas reales y suficiente autonomía para investigar, tomar decisiones y producir evidencias. Después de 157 engagements autónomos, más de 117.000 vulnerabilidades procesadas y más de 250 horas de testing, aprendimos algo que inicialmente no era tan evidente:

Encontrar vulnerabilidades no terminó siendo el problema más difícil.

El problema difícil fue decidir cuándo podíamos confiar en lo que el agente decía haber encontrado. Esta es probablemente la principal lección que nos dejó construir FaradAI.

Un LLM no es un pentester

Al principio parece tentador pensar que conectar un modelo con herramientas ofensivas alcanza. Pero un LLM normalmente produce algo parecido a:

Prompt → Modelo → Respuesta plausible

Un pentest necesita otra cosa:

Objetivo → Decisión → Ejecución → Evidencia → Hecho verificable

La diferencia está principalmente en esas últimas palabras: hecho verificable. En FaradAI cada ronda comienza con un objetivo. El agente analiza el contexto, decide una acción, utiliza herramientas a través de MCP, ejecuta y captura los resultados. Después ocurre la parte más importante:

la evidencia obtenida modifica el plan de la siguiente ronda.

Podemos simplificarlo así:

Figura 2: LLM genérico vs. loop de FaradAI

Las herramientas tampoco son particularmente novedosas. Nmap. Burp. Metasploit. Scripts propios. Las mismas herramientas que utiliza un pentester. Lo que cambia es quién decide cuál utilizar, cuándo utilizarla y qué hacer después con el resultado. Una herramienta empieza a operar herramientas.

Cuando volver a intentar se vuelve barato

Uno de los cambios que más nos llamó la atención fue el económico. En un engagement completo de web + red ejecutamos:

Figura 3: Datos del engagement en formato terminal

En todo el programa acumulamos más de 250 horas de testing autónomo por unos pocos miles de dólares de infraestructura y modelos. No significa que una hora de IA sea equivalente a una hora de un pentester humano. Claramente no lo es. Pero cambia otra variable mucho más importante: el costo de volver a intentarlo. 

Cuando probar nuevamente cuesta poco, podemos ejecutar continuamente. Y cuando podemos ejecutar continuamente, empezamos a enfrentarnos con otro problema:

¿Quién decide cuándo dejar de intentar?

El Agente IA que no sabía rendirse

En uno de nuestros engagements vimos al agente ejecutar un escaneo. No encontró nada nuevo. Cinco minutos después volvió a ejecutar prácticamente la misma técnica. Mismo resultado. Después otra variación. Y otra. Hasta que finalmente apareció:

Time limit reached

El Agente IA había pasado varios minutos insistiendo sobre un camino que no estaba generando ninguna señal nueva. Un pentester probablemente habría abandonado antes. El Agente IA no decidió detenerse. Lo detuvo la plataforma. Puede parecer un detalle de implementación, pero para nosotros fue una de las primeras señales de algo mucho más importante:

La autonomía no consiste en darle libertad ilimitada a un modelo. 

Consiste en construir límites alrededor de esa autonomía. Tiempo. Presupuesto. Scope. Cantidad de rondas. Herramientas permitidas. Acciones permitidas. El modelo puede razonar. Pero la plataforma tiene que gobernarlo.

El contexto es la mitad del producto

Otro aprendizaje importante apareció cuando empezamos a darle más información al Agente IA. El mismo Agente IA con diferente contexto parece otro Agente IA totalmente distinto. Si sólo conoce un target, explora en abanico. Prueba. Repite. Consume presupuesto. Pero si además conoce inventario, tecnología, findings anteriores, criticidad y contexto del activo, cambia completamente su comportamiento. Eso nos hizo revisar una pregunta bastante común cuando hablamos de Agentes de IA:

¿Qué modelo utilizan?

Después de nuestra experiencia, probablemente haya otra pregunta igual o más importante:

¿Qué contexto tiene disponible ese modelo?

Porque una Agente IA puede identificar correctamente dos vulnerabilidades, pero no necesariamente sabe que una afecta un microsite de marketing y la otra el sistema de facturación de la compañía. La vulnerabilidad está en la tecnología. La criticidad está en el negocio. Y ese contexto todavía necesita venir de algún lado.

Donde la IA nos sorprendió

Durante el desarrollo terminamos trabajando con dos tipos de Agentes IA muy diferentes. Uno intenta comportarse como un pentester: explora, prueba, encadena y eventualmente explota. El otro realiza triage sobre findings generados por scanners. Llegamos a un loop de validación con harnesses, y el resultado fue inesperado.

Figura 4: The Autonomous Attacker

Nuestro Agente IA de pentesting "The autonomous attacker" trabajó sobre unas mil vulnerabilidades durante cientos de horas. El Agente IA de triage procesó más de 116.000 vulnerabilidades en unas diez horas.

Figura 5: El Agente IA de Triage

Y probablemente ahí encontramos uno de los casos de uso más interesantes. No es el más cinematográfico. No hay shells. No hay exploits. No hay una demo espectacular. Pero permite analizar enormes cantidades de información, correlacionar resultados y reducir ruido antes de que llegue a un equipo humano.

Figura 6: Estadísticas finales con costes en FaradAI

Curiosamente, ahí vimos uno de los mejores retornos y uno de los menores riesgos. Quizás antes de darle autonomía completa a un Agente IA para atacar, exista muchísimo valor en dejarla trabajar sobre toda la información que nuestras herramientas de seguridad ya generan.

Las cuatro formas en que el Agente IA nos hizo perder tiempo

Después de cientos de rondas también empezamos a reconocer patrones de error.

1. Loops repetitivos: Repetir prácticamente la misma acción esperando obtener un resultado diferente.

2. Sintaxis inventada: Utilizar parámetros o flags que la herramienta no tiene, acompañados muchas veces por una explicación perfectamente razonable de por qué deberían existir.

 

3. Herramienta equivocada: Seleccionar una técnica que no corresponde con el objetivo que el propio agente había definido.

4. Presupuesto: Consumir buena parte de las rondas investigando una rama que dejó de generar señales útiles mucho antes.

Todos esos problemas hubo que ir resolviéndolos con Grapth Engineering, con MCPs claros que simplificaban la llamada a las herramientas, con Skills guiadas en procesos conocidos, y con routing adecuados de Prompts a modelos. Un trabajo de ingeniería fina. Pero hubo un problema todavía más importante.

Un finding falso puede parecer exactamente igual que uno verdadero

Este probablemente sea el punto más delicado. Un hallazgo inventado por un modelo puede tener: la misma estructura, el mismo tono, una severidad perfectamente razonable, una descripción convincente, y una recomendación correcta. Leyéndolos, pueden parecer exactamente iguales. 

Figura 7: Gestión de múltiples scans y findings en FaradAI

Durante el desarrollo revisamos informes muy buenos. Y falsos. Después de probar distintas aproximaciones llegamos a una regla bastante simple:

Figura 8: Mismo reporte, distinta evidencia

No es sufiente  con que el modelo diga que encontró una vulnerabilidad. Necesitamos saber: qué ejecutó, contra qué, qué respuesta recibió, cuándo ocurrió, y si otro investigador puede reproducirlo. Y ahí aparece, para nosotros, el verdadero desafío del Pentesting Autónomo.

The Autonomous Pentesting Trust Gap

Internamente empezamos a llamar a este problema: The Autonomous Pentesting Trust Gap. Hay dos capacidades que están creciendo a velocidades diferentes. Por un lado: lo que un Agente IA puede encontrar. Por otro: lo que puede demostrar de aquello que encontró. La primera está avanzando muy rápido. La segunda es bastante más difícil.

Y la distancia entre ambas probablemente determine cuánto podemos confiar realmente en los sistemas autónomos de Offensive Security. No creemos que esto se solucione simplemente utilizando un modelo más grande. Es principalmente un problema de plataforma, evidencia y gobernanza. Después de este año y medio terminamos reduciendo la confianza a cinco condiciones, que deben servir como Harness para cada finding.

Figura 9: Las cinco condiciones de confianza

Si falta alguna de estas piezas, corremos el riesgo de confundir un Pentester Autónomo con algo bastante diferente:

Un generador de respuestas plausibles conectado a herramientas ofensivas.

¿Entonces la IA puede reemplazar a un pentester?

Después de todo este trabajo, creo que esta pregunta empieza a perder sentido. Los Agentes IA ya pueden hacer cosas que antes necesitaban muchas horas de trabajo humano. Explorar. Ejecutar herramientas. Analizar resultados. Hacer triage. Repetir pruebas. Trabajar en paralelo. Pero seguimos viendo una diferencia importante cuando el problema deja de ser ejecutar una técnica y pasa a ser entender qué significa lo que encontramos.

• ¿Este activo realmente importa?
• ¿Vale la pena continuar este camino?
• ¿Para qué podría servir este acceso?
• ¿Existe una cadena mejor?
• ¿Cuál sería el impacto real para esta compañía?

Eso requiere contexto. Hipótesis. Creatividad. Y criterio. 

Por eso el modelo que más nos interesa hoy no es: AI → Pentest 

Sino: Hacker + AI Agent → Pentest

Figura 10: Historial de Engagements y Rounds del Agente IA en FaradAI

El Agente IA aporta escala y velocidad. El Hacker o Pentester aporta contexto, creatividad y criterio.

Lo que viene

Todavía estamos aprendiendo. FaradAI hoy es tanto un producto como un experimento permanente sobre cómo debería funcionar la próxima generación de Offensive Security. Aquí tienes una demo de cómo funciona nuestro sistema, y si quieres, contacta con nosotros para probarlo.

  

Figura 11: Demo de funcionamiento de FaradAI

çPero después de más de un año construyéndose hay algo de lo que estamos bastante convencidos: 

La IA ya puede encontrar vulnerabilidades.

Todavía necesitamos hackers para comprenderlas.

Quizás el futuro del pentesting no sea elegir entre humanos y máquinas. Quizás sea construir algo bastante más interesante:

Hackers humanos trabajando junto a Agentes IA de hackers.

Y cuando esa combinación pueda operar continuamente sobre toda una superficie de ataque, probablemente dejemos de preguntarnos cuándo fue nuestro último pentest. La pregunta será otra:

¿Qué está intentando comprometer nuestro Agente IA hacker ahora mismo?

Si quieres probar nuestro FaradAI, no dudes en ponerte en contacto con nosotros, o directamente conmigo, y hacemos una prueba de cómo funciona el Autonomous Continuous Attack con Agentes IA.

Autor: Martín Tartarelli, CEO — Faraday Security

Contactar con Martín Tartarelli