28 subagentes de Claude Code para pentesting: pentest-ai-agents

Un repositorio bautizado pentest-ai-agents acaba de publicar 28 subagentes listos para usarse con Claude Code orientados íntegramente a pruebas de penetración. La noticia la recogió CyberSecurityNews el 28 de abril de 2026, y el número en sí ya dice bastante: no se trata de un par de herramientas de demo, sino de una colección estructurada que cubre fases completas de un engagement de seguridad.

Que alguien haya decidido modelar el flujo de un pentest como un grafo de subagentes orquestados por Claude Code no es un accidente. Es la consecuencia directa de que la arquitectura de subagentes de Claude Code haya madurado lo suficiente para delegar tareas con contexto específico sin perder el hilo de la sesión principal.

Qué es pentest-ai-agents y qué incluye

El proyecto organiza sus 28 subagentes por fases típicas de una prueba de penetración: reconocimiento, enumeración, análisis de vulnerabilidades, explotación, post-explotación y generación de informes. Cada subagente está diseñado para recibir un alcance concreto —un dominio, un rango de IPs, un servicio— y devolver resultados estructurados que el agente orquestador puede encadenar.

Algunos de los subagentes más destacados que recoge la fuente:

• Recon Agent: combina OSINT pasivo con enumeración de subdominios.
• Port Scanner Agent: orquesta llamadas a herramientas como nmap vía MCP server y parsea la salida para el agente principal.
• Web Vuln Agent: automatiza comprobaciones OWASP Top 10 sobre endpoints definidos.
• Privilege Escalation Agent: sugiere vectores de escalada según el contexto de sistema recibido.
• Report Writer Agent: toma los hallazgos acumulados en la sesión y genera un borrador de informe en markdown.

La integración con Claude Code se apoya en la capacidad de invocar subagentes bajo demanda: el orquestador delega, espera la respuesta y continúa. Esto permite que cada subagente lleve sus propias instrucciones de sistema, su propio contexto de herramientas y, potencialmente, su propio MCP server configurado para las utilidades que necesita.

Por qué importa la arquitectura elegida

El enfoque de subagentes separados —en lugar de un único agente monolítico con cientos de instrucciones— tiene implicaciones prácticas. Primero, la ventana de contexto se gestiona mejor: cada subagente trabaja con el fragmento de información que le corresponde, sin arrastrar el ruido acumulado de las fases anteriores. Segundo, la especialización hace que las instrucciones de sistema sean más precisas y, por tanto, los resultados más predecibles.

También hay una ventaja de mantenimiento: si la lógica de reconocimiento cambia —porque una herramienta externa cambia su API o su formato de salida—, solo hay que tocar ese subagente, no reescribir un prompt monolítico.

Esto, llevado al contexto de ciberseguridad, tiene sentido adicional: un pentester puede querer activar solo ciertas fases según el tipo de engagement (caja blanca, caja negra, red team) sin modificar la configuración global.

Para quién es útil

El perfil más evidente es el de pentesters que ya trabajan con Claude Code y quieren automatizar las partes más mecánicas de un engagement: el reconocimiento inicial, la generación de comandos repetitivos, la correlación de hallazgos, la redacción de informes. No sustituye el criterio técnico del profesional, pero sí reduce el tiempo que se pasa ejecutando tareas de bajo valor cognitivo.

También es relevante para equipos de seguridad internos (blue team o DevSecOps) que hacen revisiones periódicas de superficie de ataque y necesitan una forma de estandarizar el proceso sin depender de un único experto que recuerde todos los pasos.

Y hay un tercer perfil menos obvio: formadores y estudiantes de ciberseguridad que pueden usar el repositorio como referencia de cómo se estructura un flujo de pentesting, independientemente de si usan o no Claude Code.

Lo que conviene tener claro antes de usarlo

Un proyecto así plantea preguntas que el repositorio deberá responder con claridad en su documentación: ¿qué controles hay para que los subagentes no ejecuten acciones fuera del alcance autorizado? ¿Cómo se gestiona el logging de las acciones para cumplir con los requisitos de un engagement real? ¿Los MCP servers que necesitan algunos agentes son de terceros o están incluidos?

Sin respuestas claras a esas preguntas, el proyecto queda más cerca de una prueba de concepto avanzada que de una herramienta lista para producción en un entorno regulado.

Dicho esto, que el ecosistema de Claude Code esté produciendo colecciones especializadas de esta envergadura es una señal de que la arquitectura de subagentes empieza a tener tracción real fuera de los casos de uso genéricos. Para el nicho de ciberseguridad ofensiva, donde la automatización asistida tiene un valor muy concreto, un repositorio estructurado como este era cuestión de tiempo.