DOC-foundry: agentes IA que prueban reglas Sigma

Por qué el ruido del SOC es un problema de negocio

El 30% de las alertas que llegan a un centro de operaciones de seguridad (SOC) se ignora por puro desbordamiento, y la rotación anual del personal ronda el 25%, según el Nextgen Cyber Report 2025–2026 recogido por WWWhat’s New. Para un founder con equipo chico, eso significa que la detección de amenazas compite por el mismo presupuesto y las mismas horas que el producto.

Ahí entra DOC-foundry, un proyecto open source de detection-as-code que propone un cambio de método: en vez de que un modelo escriba una regla de detección y alguien confíe en ella, cuatro agentes de IA la escriben, la atacan y un árbitro determinista decide si de verdad funciona.

Qué produce DOC-foundry exactamente

El flujo parte de una amenaza cualquiera — una CVE, una entrada de CISA KEV, el writeup de un incidente o una técnica de MITRE ATT&CK — y devuelve tres artefactos que viajan juntos:

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Una regla Sigma que sobrevivió a un ciclo adversarial Blue-vs-Red.
Un informe de amenaza con el historial de convergencia ronda por ronda.
Un proof bundle: un corpus positivo sobre el que la regla dispara, una línea base benigna sobre la que se mantiene en silencio, un set de mutaciones adversariales y una etiqueta de cobertura calculada (real-coverage, brittle o broken) con números de falsos positivos y falsos negativos, más un hash de reproducibilidad.

Ese tercer artefacto es la diferencia. Un modelo puede escribir una regla Sigma; lo que no puede es entregar una prueba de que funciona, un adversario que demuestra que la versión débil se evade y un registro honesto de cómo se endureció la regla hasta que aguantó.

Cómo funciona: agentes que proponen, un árbitro que prueba

La arquitectura separa dos cosas que suelen mezclarse. Los agentes proponen: Threat Analyst, Blue Detection Engineer, Telemetry y Red-Team Adversary hacen el trabajo creativo. El motor determinista prueba: evaluación de falsos positivos y negativos, evasión adversarial, veredicto de cobertura, verificación del red team y la compuerta de despliegue. Misma entrada, mismo veredicto, mismo hash.

El conocimiento de Blue se ancla en reglas de SigmaHQ, un repositorio abierto que ofrece más de 3.000 reglas de detección de distintos tipos, según su propio repositorio. Red, en cambio, ataca desde técnicas de evasión de defensas de MITRE ATT&CK (por ejemplo T1036.003 Rename System Utilities) y LOLBAS. El retriever es léxico (BM25), offline y determinista, y solo alimenta las propuestas: nunca toca el motor de prueba ni entra en el hash de reproducibilidad.

Dos detalles importan para cualquiera que evalúe herramientas de IA en producción:

El adversario es acotado y fijo. Red se compromete a dos ataques reales y documentados en la primera ronda y vuelve a lanzar esos mismos dos contra la regla endurecida en cada ronda. No es una emboscada nueva cada vez: Blue cierra un par de huecos acotado y la convergencia se vuelve alcanzable.
El motor se niega a puntuar lo que no puede evaluar. Si la regla usa construcciones que no puede resolver de verdad, el motor lanza una excepción en lugar de aprobarla en silencio. Una regla no evaluable nunca se marca como «cubierta»: cuenta como ronda rota y el mensaje del motor vuelve a Blue como evidencia de reparación.

También hay una compuerta de gobernanza. Kartikeya’s Gate calcula Blast Radius × Capability Delta con invariantes estructurales: la salida de datos (egress hacia un SIEM) siempre requiere un humano, y una cobertura que no sea real-coverage pone un piso al radio de impacto. El servidor MCP rechaza cualquier token de aprobación que no esté atado al hash exacto del bundle. En otras palabras: los permisos viven en la infraestructura, no en el agente.

La Review Chain: el mismo elenco, otra pregunta

El proyecto trae un segundo pipeline. Si el primero pregunta «¿esta regla es demostrablemente correcta?», la Review Chain pregunta «¿qué diría cada interesado sobre esta regla y cómo queda después de aplicar su feedback?». El recorrido es borrador → revisión del Red Team → revisión v2 → revisión del SOC Lead → regla final, con cada edición citando el hallazgo que responde.

El ejemplo publicado en el repositorio es un run real sobre CVE-2026-48939 (subida arbitraria de archivos en Joomla iCagenda que deriva en RCE, listada en CISA KEV), autorado por claude-opus-4-8. Tres versiones de la regla y ocho hallazgos. El primer borrador de Blue disparaba cuando un demonio web lanzaba un shell que ejecutaba comandos de reconocimiento. Los dos revisores lo desarmaron en direcciones opuestas: el Red Team señaló que bastaba con saltarse los comandos de reconocimiento para que la regla nunca disparara pese a un RCE completo; el SOC Lead señaló que dispararía sobre un cron benigno propio desde el día uno y enterraría la guardia en ruido de www-data.

Esa tensión es el producto. Endurecer contra la evasión amplía una regla; ampliarla sube el volumen de alertas. La regla final es la que sobrevivió a ambas presiones.

Qué significa esto para tu startup

Aunque no tengas un SOC, el patrón de diseño es trasladable a cualquier producto donde un modelo tome decisiones que afectan a clientes.

Separa quien propone de quien verifica. Si tu producto usa un LLM para generar configuración, reglas, contratos o código, el verificador no puede ser otro LLM opinando. Tiene que ser un componente determinista que devuelva el mismo resultado para la misma entrada. DOC-foundry lo hace con un motor sin dependencias y un hash de reproducibilidad.
Mide la fragilidad, no la asumas. La batería de mutaciones del proyecto (renombrado de binarios, cambios de mayúsculas, espacios, ofuscación con caret, reubicación de rutas) recuerda que una regla que «parece funcionar» puede romperse con un cambio trivial. Antes de confiar en una detección o una automatización, córrela contra variantes hostiles.
Distingue «revisado» de «validado». El propio proyecto lo dice de su Review Chain: no invoca el núcleo de prueba, no ejecuta la regla contra telemetría, no cuenta falsos positivos y no emite veredicto de cobertura. Una regla que pasó por cuatro revisores profesionales parece terminada, y por eso el output empaquetado abre con esa advertencia. Aplica la misma etiqueta a tus propios artefactos.
Gobierna el privilegio en código, no en el prompt. La compuerta que exige un humano para cualquier salida de datos y el token de aprobación atado al hash son controles que no dependen de que el modelo se porte bien.

Los límites que el proyecto reconoce

DOC-foundry no promete cobertura eterna. Su definición de real-coverage es concreta y acotada: la regla de primera versión dispara sobre cada ataque del corpus, se mantiene en silencio ante look-alikes benignos y atrapó los dos ataques reales de Red. Es una línea base validada, no una garantía contra toda evasión futura — extenderla es trabajo del equipo de detección.

El repositorio también es explícito sobre su estado: es un proyecto incipiente, con 0 estrellas y 1 fork al momento de esta nota, y su escenario canned (certutil T1105, que pasa de brittle a real-coverage en dos rondas) existe para que el workflow corra offline y la suite de tests tenga un caso determinista, no como demo.

La hoja de ruta de integración apunta a conectar el núcleo de prueba con fuentes abiertas: Atomic Red Team para el corpus positivo, EVTX-ATTACK-SAMPLES para la línea base benigna y pySigma con SigmAIQ para autoría y conversión multi-SIEM. Es una señal de hacia dónde va el sector: reglas portables entre plataformas en lugar de detecciones atadas a un proveedor.

Para el ecosistema hispanohablante, el interés no está en el repositorio en sí sino en el patrón: la conversación sobre agentes de IA en seguridad ya se movió de «¿puede el modelo hacerlo?» a «¿puede el modelo probar que lo hizo?». Según TechRepublic, Lenovo reportó que su SOC asistido por IA redujo el tiempo medio de detección un 87,5% en más de 140.000 dispositivos, con una tasa de falsos positivos por debajo del 10%. Cifras así son la razón por la que el mercado va a seguir empujando autonomía. La pregunta que DOC-foundry responde es qué controles hacen falta para que esa autonomía sea auditable.