AegisLoop (ARTEX-KO Plus): de una vulnerabilidad a una detección
La mayoría de los equipos de seguridad son buenos encontrando problemas y corrigiéndolos. Muchos menos pueden responder a la pregunta que de verdad decide un incidente: «si alguien lo hubiera explotado, ¿lo habríamos visto?». AegisLoop, con el título ARTEX-KO Plus, es un proyecto de código abierto creado para cerrar justo esa brecha, desde un hallazgo en un activo autorizado hasta una detección probada. Así funciona, en lenguaje claro.
Esta es una explicación educativa de un proyecto de terceros y de código abierto (AGPL-3.0), basada en su README público. PlayCISO no está afiliado a AegisLoop, ni a ARTEX, ni a sus autores. Nada de esto es un respaldo de seguridad ni asesoramiento legal.
Qué es y de dónde viene el nombre
El nombre lleva su linaje. ARTEX es el proyecto de seguridad con agentes de IA original; -KO es la edición en coreano sobre la que se construye; y Plus (con la marca AegisLoop) es lo que añade este fork: funciones de respuesta a incidentes basadas en IA. El README la describe como una plataforma de validación de seguridad con dos mitades que se alimentan mutuamente: una parte ofensiva que ejecuta diagnósticos contra objetivos autorizados y una parte defensiva que convierte las pruebas resultantes en detecciones, las valida con logs reales, investiga la actividad relacionada y puede hacer hunting de forma autónoma. Los temas que lista cuentan la historia: blue-team, detection-engineering, siem, splunk, threat-detection, threat-hunting, autonomous-agents.
La única regla que la hace legítima
Antes que nada: el README dice claramente que hay que «ejecutar los diagnósticos y la revalidación solo contra objetivos que te pertenecen o que tienes permiso explícito para probar». No es un texto de relleno: es la línea que separa una herramienta de purple team de un delito. Un agente autónomo que sondea sistemas solo debe apuntarse a tu propio laboratorio, a tu propia producción (con autorización) o a un objetivo para el que tengas permiso por escrito. Todo lo que sigue da por supuesto ese alcance.
Cómo funciona realmente el ciclo
Piénsalo como cinco etapas, cada una de las cuales alimenta a la siguiente:
- Descubrimiento autorizado. Una parte de agentes que el proyecto llama ARTEX ejecuta diagnósticos dentro de tu alcance autorizado y registra pruebas, no conclusiones. Y, lo que es crucial, el README indica que terminar un trabajo no demuestra que exista una vulnerabilidad; el resultado es material para que lo juzgue una persona.
- Generación de escenarios. A partir de las pruebas de un hallazgo concreto, la IA redacta un flujo de ataque de varios pasos, los puntos de detección a lo largo de él y consultas candidatas en Splunk SPL (Search Processing Language). Son borradores: el README deja claro que no se ejecutan ni se despliegan automáticamente.
- Validación de las defensas. Vuelve a ejecutar la comprobación, vincula tus logs reales de auditoría y de alertas (desde un archivo o desde Splunk) y juzga tres cosas por separado: ¿se reprodujo el comportamiento, se detectó y se bloqueó? Mantener separadas esas tres cosas es toda la partida: «tenemos una regla» no es lo mismo que «la regla saltó», y esto no es lo mismo que «el control lo detuvo».
- Investigación de incidentes. Indícale un activo, un intervalo de tiempo y una ruta, y prepara los logs y ejecuta una investigación con IA. El resultado se divide en elementos observados, inferidos y sin verificar, cada uno citando los eventos en bruto que lo respaldan, para que distingas de un vistazo un hecho de una hipótesis.
- Hunting autónomo. Un ciclo de cuatro etapas (Research → Scenario → Hunting → Verification) que ejecuta consultas de Splunk de solo lectura y guarda como registros separados las fuentes públicas, las hipótesis de la IA, los eventos en bruto de Splunk y el veredicto final.
El modelo de agentes por dentro
La parte ofensiva no es un único bot monolítico. Según el README, un Planner pone en cola «intenciones» de exploración mientras varios Workers ejecutan herramientas dentro del alcance autorizado y registran pruebas, todos ellos compartiendo un grafo de activos común y un grafo de exploración por trabajo. Un «MainAgent» humano puede introducir pistas para dirigir la exploración. Esa separación entre Planner y Workers es un patrón habitual para mantener acotados a los agentes autónomos: el planificador razona sobre qué probar a continuación, los workers realizan acciones de alcance limitado y el grafo es la memoria compartida que les impide perderse o repetirse.
Por qué lo interesante son los guardarraíles
Un agente autónomo que toca herramientas de seguridad es justo el tipo de sistema que necesita supervisión desde el diseño, y merece la pena copiar las decisiones prudentes de AegisLoop aunque nunca lo uses:
- Pruebas antes que veredictos. Un trabajo terminado es materia prima, no una vulnerabilidad confirmada. Esto resiste el fallo de «lo ha dicho la IA».
- Borradores, no despliegues. Las detecciones generadas son propuestas que una persona revisa y publica: el agente nunca cambia tu SIEM en silencio.
- Hunting de solo lectura. La etapa autónoma puede mirar, pero no tocar.
- Observado / inferido / sin verificar, con citas. El hábito más importante para una investigación con IA fiable: no dejar nunca que la conjetura de un modelo se muestre igual que un hecho registrado.
Esto encaja directamente con la cuestión de autonomía frente a supervisión con la que lidia todo equipo que adopta agentes de IA. Un agente con efectos reales en el mundo es el caso de manual para una puerta con intervención humana; escribimos todo un registro de dónde deben ir esas puertas, y puedes poner a prueba el radio de impacto de un agente en el Autonomy vs Oversight Lab.
Antes de ejecutarlo: dos precauciones prácticas
Tratamiento de los datos. Las funciones de IA llaman a un LLM que configuras tú, y el README indica que la investigación con IA puede enviar a ese proveedor pruebas de vulnerabilidades y extractos de logs seleccionados. Los logs de seguridad son sensibles; elige un proveedor y una configuración de retención de datos a los que estés dispuesto a enviarlos, y deja fuera del alcance el material más sensible si tienes dudas.
Licencia y ejecución. Es AGPL-3.0: si lo modificas y lo ofreces como servicio de red, se aplican las obligaciones de compartir el código fuente de la licencia, así que avisa a quien se encargue del cumplimiento de código abierto en tu organización. La pila, según el README, es una interfaz web en Next.js, un servidor en Go y PostgreSQL, que se arranca en local con Docker Compose. Trata las primeras ejecuciones como un ejercicio de laboratorio contra sistemas que te pertenecen.
La conclusión
La idea que merece la pena tomar de AegisLoop, uses las herramientas que uses, es el ciclo de encontrar a detectar: no te quedes en encontrar y parchear una debilidad; conviértela en una ruta de ataque concreta, una detección candidata y una prueba que demuestre si tu monitorización la detectaría de verdad, juzgada con tus propios logs. Eso es ingeniería de detección basada en la realidad y no en reglas genéricas. Puedes practicar ahora mismo la mitad de blue team de ese ciclo en nuestro Detection Lab y en la guía de reglas de detección: sin agente, sin configuración, gratis y en el navegador.
Explicación educativa de un proyecto de código abierto de terceros, basada en su README público. Usa cualquier herramienta de seguridad solo contra sistemas que te pertenecen o que tienes autorización explícita para probar.
Preguntas frecuentes
¿Qué es AegisLoop / ARTEX-KO Plus?
Es una plataforma de código abierto (AGPL-3.0) de validación de seguridad con agentes de IA. El nombre refleja su linaje: ARTEX es el proyecto original, «-KO» es la edición en coreano sobre la que se construye y «Plus» (con la marca AegisLoop) añade funciones de respuesta a incidentes basadas en IA. Según su README, combina una parte de diagnóstico ofensivo (agentes que sondean objetivos autorizados) con una parte defensiva (generación de escenarios de ataque y detección, validación de las defensas con logs reales, investigación de incidentes y threat hunting autónomo en Splunk). PlayCISO no está afiliado a ella; todo lo aquí expuesto se basa en el README público del proyecto.
¿Es una herramienta de hacking ofensivo?
Tiene un componente ofensivo, pero está planteada y limitada como herramienta de blue team y purple team. El README deja claro que hay que «ejecutar los diagnósticos y la revalidación solo contra objetivos que te pertenecen o que tienes permiso explícito para probar». El propósito de la parte ofensiva no es entrar en nada, sino producir pruebas reales que la parte defensiva convierte después en detecciones y valida con tus logs. Usar cualquier herramienta de seguridad contra sistemas que no tienes autorización para probar es ilegal y poco ético, sea cual sea la herramienta.
¿Cómo evita causar daños o actuar por su cuenta?
Con varios guardarraíles deliberados, según el README: un trabajo de agente terminado no se trata como prueba de una vulnerabilidad (sigue necesitando el juicio de una persona); las reglas de detección en Splunk SPL que genera son borradores que no se ejecutan ni se despliegan automáticamente; la etapa de hunting autónomo usa consultas de Splunk de solo lectura; y la salida de la IA se separa en elementos observados, inferidos y sin verificar, cada uno citando los eventos en bruto que lo respaldan. Esa separación es justo lo que mantiene auditable una investigación con IA en lugar de convertirla en una conjetura que suena segura.
¿Qué usa realmente la parte de IA?
Un LLM que configuras tú. El README dice que las funciones de IA llaman al «LLM configurado por el usuario», que se define en System → LLM, y advierte de que la generación de escenarios, los diagnósticos, la investigación con IA y el hunting autónomo llaman todos a ese modelo, así que se aplican costes y límites de tasa. Ten en cuenta la implicación sobre el tratamiento de los datos que también señala: la investigación con IA puede enviar pruebas de vulnerabilidades y extractos de logs seleccionados al proveedor que elijas, así que escoge un proveedor y una postura de retención de datos con los que te sientas cómodo al enviar material sensible de seguridad.
¿Por qué importa «cerrar el ciclo» para los defensores?
La mayoría de los equipos encuentra una vulnerabilidad y la corrige, pero nunca confirma que su monitorización habría detectado el ataque que la explota. Un ciclo de encontrar a detectar responde a la pregunta que de verdad importa en un incidente: «¿lo habríamos visto?». Al convertir un hallazgo concreto en una ruta de ataque concreta, una detección candidata y después una prueba con logs reales que juzga por separado la reproducción, la detección y el bloqueo, produce un trabajo de ingeniería de detección basado en tu propio entorno y no en reglas genéricas. Puedes construir y probar ese tipo de detección a mano en nuestro Detection Lab.