Desplegar la arquitectura agéntica D2D en un equipo de operaciones de seguridad
La arquitectura teórica es una cosa. Ejecutar D2D en un SOC en producción, con alertas reales, analistas reales y una guardia real, es otra. Esto es lo que aprendimos al desplegarlo.
El stack inicial
El despliegue empezó con cinco dominios de workers:
- Consulta al SIEM: consultas a Splunk para enriquecer las alertas
- Enriquecimiento de IP y dominios: VirusTotal, Shodan, DNS pasivo
- Búsqueda de CVE: NVD + puntuación EPSS
- Resolución de identidades: asociar IP a usuarios internos mediante Active Directory
- Notificación: Slack (baja/media), PagerDuty (alta/crítica)
El coordinador se ejecutaba en un modelo de nivel Claude Opus. Los workers, en uno de nivel Haiku. El nodo killer se ejecutaba como un proceso aparte con un bucle de sondeo de 10 segundos.
Lo que funcionó desde el primer momento
Enriquecimiento en paralelo. Antes de D2D, un analista ejecutaba a mano 4 o 5 consultas de enriquecimiento seguidas por cada alerta. El coordinador de D2D las ejecutaba todas en paralelo: SIEM + IP + CVE + identidad a la vez. El tiempo de triaje de la primera alerta bajó de unos 12 minutos a unos 2 minutos en las alertas estándar.
Formato de salida coherente. Cada alerta que pasaba por D2D salía con el mismo resumen estructurado: activos afectados, indicadores de amenaza, puntuación de confianza, acción recomendada y cadena de pruebas. Los analistas podían leerlos siguiendo un patrón predecible sin tener que interpretar prosa.
El nodo killer se ganó el sueldo. En la primera semana, el nodo killer terminó tres workers desbocados: dos workers de consulta al SIEM que dieron con una consulta mal formada y entraron en bucle, y un worker de enriquecimiento que se quedó atascado reintentando una API con límite de tasa. Sin el killer, cada uno habría agotado presupuesto y acabado expirando en el API gateway.
Lo que se rompió
El DAG del coordinador era demasiado optimista. El prompt de planificación inicial daba por hecho que todos los resultados de los workers estarían disponibles antes de la síntesis. En la práctica, los workers de enriquecimiento a veces devolvían datos parciales con errores. La primera versión del coordinador hacía fallar el paso de síntesis en lugar de seguir adelante con huecos. Lo arreglamos haciendo que los workers siempre devolvieran un resultado (con un campo status: partial) en lugar de terminar con error.
Los mensajes de escalado eran demasiado escuetos. Cuando el coordinador escalaba a PagerDuty, el mensaje inicial era legible por máquina pero hostil para el analista. A los ingenieros de guardia les llegaban avisos con bloques de JSON a las 3 de la madrugada. Añadimos una capa de resumen en lenguaje natural que el coordinador genera junto a la salida estructurada.
Los presupuestos de tokens estaban mal. Los presupuestos iniciales se fijaron a ojo. Tras dos semanas de logs, los recalibramos: los workers de consulta al SIEM necesitaban el triple del presupuesto estimado (los resultados de Splunk pueden ser muy extensos), mientras que los de resolución de identidades necesitaban la mitad. Calibrar el presupuesto es empírico: ejecútalo en producción y mide.
La cola de revisión humana
Las misiones escaladas (las que el coordinador no podía completar de forma autónoma) iban a una cola de revisión humana con un SLA de 15 minutos en horario laboral y un aviso de PagerDuty fuera de horario. La interfaz de la cola mostraba:
- Qué había logrado el coordinador antes de escalar
- Qué no pudo completar y por qué
- Qué decisión se necesitaba de la persona
- La recomendación del coordinador si tuviera que adivinar
Los analistas encontraron valioso el campo de recomendación: incluso cuando lo descartaban, tener un punto de partida era más rápido que empezar de cero. Al cabo de tres meses, los coordinadores acertaban la recomendación aproximadamente el 78 % de las veces. Esa cifra mejoró a medida que se afinaba la tabla de enrutamiento.
Gobierno y aprobación del CISO
Antes de entrar en producción documentamos:
- Cada tipo de acción que podían realizar los workers, con la designación explícita de «autónoma» o «requiere una persona»
- El presupuesto máximo de tokens por misión (control de costes)
- Las restricciones de residencia de datos (ningún dato personal sale de la región de la UE)
- La política de retención de los logs de auditoría (90 días, con evidencia de manipulación)
La revisión de este documento por parte del CISO llevó dos horas. Las preguntas clave giraron en torno a las acciones irreversibles (fijamos en el código que todos los cambios de firewall requieren una persona) y al tratamiento de los datos (los workers de enriquecimiento recibieron restricciones explícitas sobre lo que podían enviar a APIs externas).
Qué viene ahora para D2D
El patrón está madurando deprisa. La frontera interesante no es el coordinador ni el worker, sino el modelo de confianza entre dominios. Cuando un worker de un dominio pasa resultados a un worker de otro dominio, ¿cómo evitas la inyección de prompts en los datos intermedios? ¿Cómo verificas que la salida del worker de enriquecimiento de IP no fue envenenada por un actor de amenazas que controla esa IP?
Estos son los problemas que definirán la seguridad agéntica de nivel empresarial, y son los problemas hacia los que estamos construyendo futuros escenarios de la Cyber War Room de PlayCISO.