Frameworks de pentesting autónomo con IA: cómo funcionan y qué preguntar

Durante años, «IA en un pentest» significaba un chatbot que te sugería el siguiente comando. Esa época se acaba. Una nueva categoría de herramientas de código abierto le da al LLM el volante: razona sobre un objetivo, ejecuta una herramienta, lee el resultado y decide qué hacer a continuación, por su cuenta y hacia el objetivo que tú fijes. Zen-AI-Pentest es un ejemplo destacado. Así funcionan estos frameworks, y estas son las preguntas que importan mucho más que el comando de instalación.

Contenido educativo y defensivo. PlayCISO no está afiliado a Zen-AI-Pentest ni a sus autores; esto se basa en el README público del proyecto (no en una auditoría del código), y nada de lo que sigue lo respalda ni es una guía para usarlo contra nadie. Usar cualquier herramienta de seguridad contra sistemas que no son tuyos o que no tienes autorización explícita para probar es ilegal.

Qué cambia de verdad lo «autónomo»

Un escáner tradicional hace una cosa e informa. Un framework de pentesting autónomo con IA ejecuta un bucle, que suele describirse como razonar → actuar → observar → reflexionar (el patrón «ReAct»). Al modelo se le da un objetivo («evalúa este host»), elige una herramienta, el framework la ejecuta, el modelo lee la salida y elige el siguiente paso. Encadena eso las veces suficientes y el agente puede pasar del reconocimiento a la explotación sin que una persona dé cada orden.

Esa es toda la gracia, y todo el riesgo. Un escáner que encuentra una inyección SQL la anota en un informe. Un agente autónomo configurado para explotar puede actuar sobre ese hallazgo y después usar lo que obtiene para llegar más lejos. La velocidad y la iniciativa son exactamente lo que lo hace potente en una evaluación autorizada y peligroso si se apunta a lo que no toca. PentAGI, un agente de pentesting con IA de código abierto, es un ejemplo bien documentado de este bucle, con un modo Assistant que mantiene a una persona aprobando cada paso.

Cómo encajan las piezas

Tomando como ejemplo práctico la propia descripción de Zen-AI-Pentest, la arquitectura es representativa de la categoría:

• Un LLM detrás de un proxy. El framework enruta hacia uno o varios modelos alojados (de nivel gratuito y de pago) a través de un proxy interno, así que el «cerebro» es intercambiable.
• «Personas» de agentes. Roles especializados (reconocimiento, explotación, análisis, red team, nube y otros) coordinados por un controlador que pasa por los estados de planificar, ejecutar, observar y reflexionar.
• Un gran cinturón de herramientas. El README enumera decenas de herramientas de seguridad estándar y públicamente conocidas de escaneo de red, pruebas web, explotación, ataques a credenciales, Active Directory, OSINT, análisis de código y secretos e inalámbricas. El agente las ejecuta, no se limita a nombrarlas.
• Niveles de riesgo. Escalones crecientes, desde el reconocimiento de solo lectura hasta la «explotación completa» con pivotaje y movimiento lateral: el selector que decide hasta dónde puede llegar el agente.
• Superficies para el operador. Una API REST, un terminal web e incluso una interfaz de chatbot para dirigir las ejecuciones.

Ninguna de las herramientas individuales es nueva ni secreta; el cambio es que ahora un LLM las orquesta de principio a fin. (Describimos el diseño declarado, sin reproducir ningún comando de ejecución: lo que importa es el mecanismo, no una receta.)

Las preguntas que importan antes de ejecutar uno

Si tu red team está evaluando una herramienta así, la instalación es lo fácil. Esto es lo innegociable:

1. Autorización por escrito y un alcance estrecho. Permiso explícito para los objetivos exactos, por escrito y con reglas de enfrentamiento. Y sobre todo: un filtro de IP no es una autorización. Bloquear los rangos privados evita un tipo de accidente; no dice nada sobre si tienes permiso para tocar lo que queda.
2. Aislamiento total. Ejecuta el agente desde un entorno aislado y desechable con control de la salida de red, para que un error no pueda llegar a producción ni a internet en general.
3. Una aprobación humana para todo lo irreversible. La autonomía es un selector, no un interruptor. Los pasos destructivos o de movimiento lateral deberían detenerse a la espera de una persona: el caso de manual para una aprobación con una persona en el bucle. Puedes razonar dónde poner esa línea en nuestro Autonomy vs Oversight Lab.
4. Un interruptor de parada y un registro completo. Un comando para detenerlo todo y un registro completo, que deje rastro de cualquier manipulación, de cada acción que realizó el agente, por seguridad y para el informe al cliente.

Salvedades honestas sobre este proyecto concreto

Zen-AI-Pentest es real y bastante popular (licencia MIT, cientos de estrellas, miles de commits), y la capacidad es auténtica. Pero una lectura atenta del README saca a la luz cosas que conviene saber antes de fiarse de él:

• La orientación sobre la autorización ocupa una línea, al final del todo: en el README que leímos no aparece ninguna plantilla de reglas de enfrentamiento, ningún flujo de alcance ni ninguna orientación sobre la divulgación responsable.
• Las «salvaguardas» son sobre todo filtros de IP y de dominio, y la propia petición de ejemplo del README parece escanear un rango privado (192.168.0.0/16) que esos filtros deberían bloquear: una contradicción sin resolver.
• Incluye gestión del anonimato y de los límites de peticiones (Tor/Proxychains y rotación automática de VPN cuando se reciben respuestas de límite de peticiones). Es legítimo en una prueba autorizada, pero también es el tipo de función que se desliza hacia el abuso si el alcance es laxo.
• La cobertura de pruebas autodeclarada ronda el 10 % pese a afirmar un gran número de pruebas, así que trata las insignias de madurez con el escepticismo habitual.

Para que quede claro lo que no es: lo buscamos expresamente y no encontramos dependencia de modelos abliterados o «sin censura», ni ninguna generación de malware, ransomware, kits de phishing o evasión de EDR. Es un framework de red team de doble uso con una postura de seguridad endeble, no un kit de armamento.

La conclusión para el defensor

Ejecutes uno o no, la llegada de una orquestación ofensiva autónoma, barata y de código abierto es una premisa de planificación: el esfuerzo de encadenar el reconocimiento con la explotación está bajando, así que invierte en los controles a los que les da igual cómo se dirigió el ataque: segmentación, mínimo privilegio, control de la salida de red y una detección ajustada al ritmo y la secuencia de la actividad, no solo a firmas aisladas. Hay también una imagen especular constructiva: el mismo bucle de agente apuntado a tu propio entorno autorizado, con una aprobación humana, es como una herramienta de validación defensiva como AegisLoop convierte un hallazgo en una detección probada.

Si estás montando pruebas autorizadas de cualquier tipo, empieza por el alcance y el permiso, no por las herramientas: nuestra lista de comprobación de alcance y RFP de pruebas de penetración recorre la autorización, las reglas de enfrentamiento y las salvaguardas, en tu navegador (prueba gratis: una cuenta gratuita incluye 3 usos de herramientas Pro).

Explicación educativa de un proyecto de código abierto de terceros, basada en su README público. Sea autónoma o no, usa cualquier herramienta de seguridad ofensiva solo contra sistemas que sean tuyos o que tengas autorización explícita y por escrito para probar.