En los últimos meses, la conversación sobre agentic AI ha salido del laboratorio y ha empezado a tocar el día a día de la ciberseguridad. En ese contexto, un proyecto llamado PentAGI está ganando visibilidad por una promesa muy concreta: automatizar pruebas de penetración con varios agentes de IA que se coordinan entre sí, integrando herramientas clásicas de pentesting y una capa de “memoria” para reutilizar aprendizajes en futuras evaluaciones.
La propuesta, tal y como se describe en su documentación pública, busca que el profesional de seguridad pueda definir un objetivo y supervisar el proceso, mientras el sistema decide los siguientes pasos, ejecuta herramientas y va recopilando evidencias. En otras palabras: un flujo de pentesting más cercano a un “equipo” automatizado que a un script aislado.
Un pentester con UI, agentes y “memoria” (y mucho software alrededor)
PentAGI se presenta como un sistema modular y autoalojable, con interfaz web, servicios backend y un enfoque de ejecución encapsulada mediante contenedores. Entre sus puntos diferenciales, el repositorio destaca:
- Ejecución en entorno aislado mediante Docker, con la idea de separar la operativa del sistema anfitrión.
- Autonomía y delegación: un esquema de agentes con roles especializados (investigación, infraestructura, ejecución, etc.) para repartir tareas y mantener contexto.
- Suite integrada de herramientas de seguridad (mencionan “20+” utilidades habituales en el sector), con capacidad para orquestar su uso dentro del flujo.
- Persistencia y búsqueda semántica: almacenamiento de comandos/resultados y uso de componentes de “memoria” para recordar hallazgos o patrones.
- Grafo de conocimiento con Neo4j mediante Graphiti para relacionar entidades, acciones y resultados a lo largo del tiempo, algo especialmente útil cuando se repiten auditorías sobre superficies parecidas.
- Observabilidad: integración con herramientas de monitorización para seguir qué hace la IA, qué ejecuta y cómo evoluciona el proceso.
En paralelo, el proyecto presume de compatibilidad con múltiples proveedores de modelos (y opciones autoalojadas), lo que apunta a un objetivo claro: poner el “cerebro” donde el equipo decida, no donde obligue una plataforma.
La parte incómoda: automatizar también automatiza los riesgos
La automatización en seguridad no es nueva. Lo que cambia con sistemas de agentes es la velocidad con la que pueden encadenar pasos, probar hipótesis y volver a intentar. Eso, en manos responsables, puede ser una ventaja: más cobertura, mejor repetibilidad, menos tareas mecánicas.
Pero hay un matiz que no se puede ignorar: el mismo tipo de automatización que acelera auditorías internas también puede bajar la fricción de usos indebidos. Por eso, cualquier “red team autónomo” acaba chocando con lo de siempre: legalidad, ética, control y trazabilidad.
La propia documentación, sin dramatismos, deja pistas de ese riesgo operativo. Por ejemplo, explica que el despliegue necesita permisos para gestionar contenedores (y menciona explícitamente el acceso a la API de Docker), recordando que ciertas configuraciones equivalen, en la práctica, a privilegios muy elevados. Y también recomienda enfoques de despliegue más aislados en escenarios sensibles, separando la ejecución “peligrosa” en nodos dedicados.
Traducido a lenguaje de sistemas: si lo instalas “como si fuera una app más”, te estás perdiendo el punto. Este tipo de herramienta debe tratarse como si fuese un runner de código potencialmente hostil, aunque el objetivo sea legítimo.
Qué significa esto para equipos defensivos: más presión, menos excusas
Si herramientas así cuajan, el impacto no será que “todo el mundo hackea mejor”, sino que habrá más pruebas automáticas, más ruido inteligente y más intentos de explotación oportunista. Para un administrador de sistemas o un responsable de plataforma, eso suele aterrizar en tres frentes:
- Gestión de superficie y exposición real
Inventario, versiones, servicios publicados, y eliminación de “restos” (subdominios olvidados, paneles de staging, endpoints sin autenticación, buckets, etc.). La automatización hace que lo olvidado deje de estarlo. - Velocidad de parcheo y configuración segura por defecto
No hace falta que un atacante sea brillante si tu stack tiene un CVE conocido sin mitigar. La diferencia la marca la higiene: actualizaciones, hardening y reducción de dependencias de terceros. - Detección y respuesta con telemetría útil
Con IA o sin IA, la realidad es la misma: sin logs bien armados, sin alertas mínimas y sin visibilidad en egress/DNS/HTTP, todo llega tarde. La automatización no “rompe” la defensa; expone su falta de disciplina.
Licencia y adopción: “open source”, sí… con letra pequeña para derivados
En lo legal, PentAGI indica que su núcleo está bajo licencia MIT, pero también incluye condiciones específicas sobre componentes vinculados a un SDK y advierte de implicaciones para forks o usos de terceros. Este detalle importa especialmente a empresas que quieran integrar el sistema dentro de productos cerrados o redistribuirlo como parte de un servicio.
En resumen: hay interés técnico real, pero antes de tocar producción conviene que el área legal y el equipo de plataforma lean esa sección con calma.
Preguntas frecuentes
¿Qué es un “red team autónomo” y en qué se diferencia de un escáner tradicional?
Un escáner suele seguir firmas y checks predefinidos. Un sistema de agentes intenta encadenar acciones, interpretar resultados y decidir el siguiente paso como lo haría un analista (con más o menos acierto según configuración y modelo).
¿Se puede usar PentAGI legalmente en una empresa?
Sí, siempre con autorización explícita y alcance definido (sistemas propios o del cliente con contrato). En muchos países, probar sin permiso es ilegal aunque el objetivo sea “aprender”.
¿Qué requisitos mínimos se mencionan para desplegarlo en laboratorio?
La guía de inicio rápido menciona Docker/Docker Compose y un entorno modesto (por ejemplo, 2 vCPU, 4 GB de RAM y 20 GB libres), suficiente para pruebas iniciales.
¿Cuál es la forma más segura de evaluar este tipo de herramientas en 2026?
En un entorno aislado, con objetivos de laboratorio, control de red (egress), credenciales desechables, y trazabilidad completa (logs/alertas). La prioridad no es “que funcione”, sino que no se convierta en un riesgo interno.
