1. Objetivos de la semana
En las semanas anteriores hemos construido progresivamente las piezas de una arquitectura de seguridad para sistemas de IA.
El objetivo de esta semana es construir mentalmente —y posteriormente técnicamente— un SOC capaz de proteger una organización donde los agentes de IA son ciudadanos de primera clase dentro de la infraestructura.
Saber qué está ocurriendo dentro del ecosistema de agentes.
Identificar comportamientos sospechosos.
Relacionar eventos aislados para descubrir ataques.
Reconstruir qué ha ocurrido.
Contener y responder al incidente.
Utilizar cada incidente para mejorar las defensas.
2. De Security Operations a AI-Security Operations
Un SOC tradicional monitoriza principalmente:
- endpoints;
- servidores;
- firewalls;
- IDS/IPS;
- identidades;
- aplicaciones;
- cloud;
- redes.
Un AI-SOC debe añadir nuevas fuentes de información.
3. ¿Qué hace realmente un SOC?
Un SOC no es simplemente una pantalla con alertas.
Un SOC es un proceso operacional.
La misma lógica debe aplicarse a incidentes que involucren agentes.
"¿Qué ha hecho este usuario?"
a:"¿Qué ha hecho este usuario, qué ha interpretado el agente, qué herramientas ha ejecutado y qué sistemas ha afectado?"
4. ¿Qué es un AI-SOC?
Un AI-SOC es una evolución del SOC tradicional en la que la telemetría, detección, investigación y respuesta incorporan explícitamente el comportamiento de sistemas de IA.
El objetivo no es sustituir al SOC tradicional.
Es ampliarlo.
5. Arquitectura completa del AI-SOC
Esta arquitectura es la columna vertebral del módulo.
6. Telemetría de agentes
Sin telemetría no existe detección.
Pero registrar absolutamente todo puede ser un problema de coste, privacidad y rendimiento.
Por tanto debemos decidir qué observar.
| Fuente | Ejemplos | Valor |
|---|---|---|
| Authentication | login, token, session | Alto |
| Prompt | request metadata | Alto |
| Tool Call | tool + parameters | Crítico |
| Model Output | response metadata | Medio/alto |
| Memory | read/write | Alto |
| Network | destination | Crítico |
| DLP | sensitive data | Crítico |
| Policy | allow/deny | Crítico |
7. Diseñar un evento de seguridad para IA
Necesitamos un formato común.
{
"timestamp":
"2026-08-29T10:15:22Z",
"event_type":
"agent.tool_call",
"agent_id":
"operations-agent",
"user_id":
"user-142",
"tool":
"modify_firewall",
"risk_score":
84,
"policy":
"HIGH_RISK_TOOL",
"decision":
"DENY",
"source_ip":
"10.10.4.21",
"destination":
"firewall-api",
"correlation_id":
"INC-2026-00031"
}
El campo correlation_id es especialmente importante.
Nos permitirá reconstruir una cadena de acontecimientos.
8. Event Taxonomy
Antes de construir detecciones debemos definir una taxonomía.
| Categoría | Eventos |
|---|---|
| Identity | login, token, impersonation |
| Prompt | injection, anomaly, policy violation |
| Context | untrusted source, poisoning |
| Tool | call, deny, error |
| Memory | read, write, delete |
| Network | connection, DNS, egress |
| Data | classification, DLP |
| Model | model change, version |
| Agent | behavior, delegation |
9. Security Telemetry Pipeline
Normalization
Los eventos procedentes de diferentes sistemas deben convertirse a un modelo común.
Por ejemplo:
CloudTrail
Firewall
Agent Gateway
IAM
LLM Gateway
Application
EDR
↓
COMMON SECURITY EVENT
10. AI-SIEM
Un SIEM tradicional centraliza y correlaciona eventos.
Un AI-SIEM debe además entender eventos específicos de IA.
Ejemplo
Tenemos tres eventos aparentemente independientes.
10:01
User logs in
10:04
Agent receives suspicious prompt
10:05
Agent calls privileged tool
10:06
Sensitive data accessed
10:07
External network connection
10:08
Data transfer detected
Individualmente pueden no ser suficientes para disparar una alerta.
Juntos representan una cadena de ataque.
11. UEBA para agentes
UEBA significa User and Entity Behavior Analytics.
En un AI-SOC debemos ampliar el concepto:
Ejemplo
Un agente normalmente:
- consulta 50 eventos por hora;
- utiliza dos herramientas;
- se conecta a tres APIs;
- trabaja durante horario laboral.
De repente:
- consulta 50.000 eventos;
- utiliza 12 herramientas;
- contacta con destinos desconocidos;
- realiza operaciones fuera de horario.
La desviación respecto al comportamiento esperado ya puede ser suficiente para generar una señal de riesgo.
12. Detection Engineering
Una detección debe responder a una pregunta concreta.
Ejemplo
"¿Está un agente intentando utilizar una herramienta de alto riesgo fuera de su patrón habitual?"
IF
agent.tool == "modify_firewall"
AND
agent.identity != authorized_identity
THEN
ALERT
severity = CRITICAL
Las reglas pueden ser deterministas, estadísticas o basadas en modelos.
| Tipo | Ventaja | Problema |
|---|---|---|
| Rule | Predecible | Rígida |
| Statistical | Detecta desviaciones | Puede generar ruido |
| ML | Patrones complejos | Explicabilidad |
| LLM | Contexto semántico | Coste / determinismo |
13. Correlación de eventos
La correlación convierte eventos en historias.
Ejemplo
A = suspicious_prompt
B = tool_access
C = sensitive_data_read
D = external_connection
IF A + B + C + D
WITHIN 10 MINUTES
THEN
CRITICAL_INCIDENT
14. Risk Engine
El Risk Engine asigna contexto a los eventos.
No todos los eventos deben tener la misma prioridad.
Risk Score =
Identity Risk
+
Tool Risk
+
Data Sensitivity
+
Network Risk
+
Behavior Anomaly
+
Threat Intelligence
+
Attack Chain Context
Ejemplo
| Factor | Puntuación |
|---|---|
| Unknown user | 20 |
| Privileged tool | 25 |
| Sensitive data | 25 |
| External destination | 20 |
| Behavior anomaly | 10 |
| Total | 100 |
15. Threat Intelligence
El AI-SOC debe consumir información externa para enriquecer eventos.
Por ejemplo:
- IPs maliciosas;
- dominios;
- hashes;
- técnicas de ataque;
- indicadores de compromiso;
- campañas conocidas;
- vulnerabilidades.
En el mundo de IA debemos además mantener inteligencia específica sobre:
- técnicas de prompt injection;
- tool abuse;
- model manipulation;
- agent hijacking;
- memory poisoning;
- AI supply chain.
16. Investigación de un incidente
Supongamos:
El analista debe reconstruir:
- ¿Quién inició la sesión?
- ¿Qué identidad utilizó?
- ¿Qué prompt recibió?
- ¿Qué contexto tenía?
- ¿Qué modelo utilizó?
- ¿Qué herramientas invocó?
- ¿Qué datos consultó?
- ¿A qué destinos se conectó?
- ¿Qué respuesta generó?
- ¿Qué acciones ejecutó?
09:42 Login
09:43 Session created
09:44 Prompt anomaly
09:44 Tool request
09:45 Tool allowed
09:46 Sensitive data access
09:47 External connection
09:48 DLP alert
09:49 SOC alert
09:50 Agent isolated
17. SOAR
SOAR significa Security Orchestration, Automation and Response.
El objetivo es automatizar tareas repetitivas.
Ejemplo
Detectamos que un agente está intentando conectarse a un destino desconocido.
El SOAR puede:
- consultar threat intelligence;
- comprobar reputación;
- calcular riesgo;
- bloquear el destino;
- revocar temporalmente la sesión;
- crear incidente;
- notificar al SOC.
18. Respuesta automatizada
No todas las respuestas deben requerir aprobación humana.
| Acción | Automatización |
|---|---|
| Block malicious IP | Automática |
| Terminate suspicious session | Automática |
| Disable agent | Condicionada |
| Rotate credential | Condicionada |
| Modify firewall | Human approval |
| Delete infrastructure | Human approval |
La autonomía de la respuesta debe ser proporcional al riesgo y a la reversibilidad de la acción.
19. Autonomous Security Response
Aquí aparece una de las ideas más potentes de todo el curso.
Podemos utilizar IA no solo para proteger agentes, sino también para operar el propio SOC.
El agente de seguridad podría investigar automáticamente un incidente, pero debe existir una frontera clara entre:
- analizar;
- recomendar;
- ejecutar.
20. AI Analyst Agent
Podemos crear un agente especializado exclusivamente en investigación.
Este agente puede reducir enormemente el tiempo de investigación.
21. AI Analyst Guardrails
El agente investigador también necesita controles.
- read-only por defecto;
- allowlist de herramientas;
- separación de funciones;
- auditoría;
- rate limiting;
- context isolation;
- human approval para acciones críticas.
El propio SOC debe protegerse contra ataques contra el agente del SOC.
Para proteger agentes necesitamos agentes de seguridad.
Y esos agentes también necesitan seguridad.
22. SOC Agent vs Production Agent
| Característica | Production Agent | SOC Agent |
|---|---|---|
| Objetivo | Negocio | Seguridad |
| Tools | Business tools | Security tools |
| Access | Necesario | Muy controlado |
| Privileges | Limitados | Potencialmente elevados |
| Approval | Según operación | Crítica |
| Audit | Alta | Máxima |
23. Blast Radius
Uno de los conceptos fundamentales del AI-SOC es el blast radius.
Debemos preguntarnos:
¿Qué puede ocurrir si este agente es comprometido?
Un agente que únicamente puede consultar documentación tiene un blast radius pequeño.
Un agente que puede modificar infraestructura tiene un blast radius mucho mayor.
24. Agent Risk Registry
Una organización grande debería disponer de un inventario de riesgo para todos sus agentes.
| Agent | Data | Tools | Privilege | Risk |
|---|---|---|---|---|
| HR-Agent | Personal | HR API | Medium | High |
| Monitoring-Agent | Logs | Read APIs | Low | Medium |
| Cloud-Agent | Infrastructure | Cloud API | High | Critical |
| SOC-Agent | Security | SIEM/SOAR | High | Critical |
25. Security Graph
Una evolución interesante consiste en representar la organización como un grafo.
El grafo permite responder preguntas como:
- ¿Qué usuarios pueden llegar a este dato?
- ¿Qué agentes pueden ejecutar esta herramienta?
- ¿Qué herramientas pueden modificar este sistema?
- ¿Qué rutas conducen a un activo crítico?
- ¿Qué ocurre si este agente queda comprometido?
26. Attack Path Detection
El AI-SOC puede combinar el grafo con eventos reales.
Si una serie de eventos activa una ruta previamente identificada como peligrosa, el riesgo puede incrementarse automáticamente.
27. AI-SOC Dashboard
Un dashboard útil no debe mostrar únicamente miles de eventos.
Debe ayudar a tomar decisiones.
28. Incident Prioritization
No todos los incidentes deben llegar al mismo nivel del SOC.
| Risk | Action |
|---|---|
| 0-20 | Log |
| 21-40 | Monitor |
| 41-60 | Investigate |
| 61-80 | High priority |
| 81-100 | Critical response |
29. False Positives
Un AI-SOC que genera demasiadas alertas deja de ser útil.
Supongamos:
100,000 events
10,000 alerts
500 real incidents
El equipo humano no puede investigar todo.
Necesitamos:
- deduplicación;
- correlación;
- risk scoring;
- suppression;
- baselines;
- enrichment.
30. Detection Coverage
No basta con tener muchas reglas.
Debemos conocer qué cubren.
| Técnica | Detection | Coverage |
|---|---|---|
| Prompt Injection | 3 | Alta |
| Tool Abuse | 7 | Alta |
| Memory Poisoning | 2 | Media |
| Agent Impersonation | 1 | Baja |
| Data Exfiltration | 8 | Alta |
31. Laboratorios
Objetivo
Diseña la arquitectura de un AI-SOC para una empresa con:
- 200 agentes;
- 500 servidores;
- 3 clouds;
- 2.000 usuarios;
- 100 APIs internas.
Debes incluir
- ingestion;
- SIEM;
- UEBA;
- risk engine;
- SOAR;
- threat intelligence;
- incident management.
Resolución orientativa
Crea un esquema JSON para representar una llamada de herramienta realizada por un agente.
Debe incluir como mínimo
- timestamp;
- agent;
- identity;
- tool;
- risk;
- decision;
- source;
- destination;
- correlation ID.
Respuesta
{
"timestamp": "...",
"agent_id": "...",
"identity": "...",
"tool": "...",
"risk_score": 72,
"decision": "DENY",
"source": "...",
"destination": "...",
"correlation_id": "..."
}Detecta el siguiente comportamiento:
Un agente accede a datos sensibles y posteriormente realiza una conexión externa en menos de cinco minutos.
Resolución
IF
event_1.type == "sensitive_data_access"
AND
event_2.type == "external_connection"
AND
event_2.timestamp -
event_1.timestamp <= 5 minutes
THEN
ALERT
severity = HIGH
Un agente normalmente realiza:
50 queries/hour
2 tools
3 APIs
En una hora realiza:
8,000 queries
12 tools
21 APIs
Preguntas
- ¿Existe anomalía?
- ¿Qué factores utilizarías?
- ¿Qué severidad asignarías?
Respuesta orientativa
Sí. La desviación es extremadamente significativa.
Debe combinarse volumen, diversidad de herramientas, número de APIs, identidad, horario y tipo de datos consultados.
En un agente con acceso sensible podría justificar una alerta de severidad alta o crítica.
Dispones de:
10:01 Login anomaly
10:02 Prompt anomaly
10:03 Tool escalation
10:04 Sensitive data
10:05 External connection
Construye la cadena de ataque y determina el riesgo.
Respuesta
Diseña un playbook para detectar un agente que intenta acceder a un destino externo malicioso.
Debe:
- enriquecer IOC;
- calcular riesgo;
- bloquear destino;
- aislar agente si riesgo crítico;
- crear incidente;
- notificar SOC.
Clasifica estas acciones:
- bloquear IP;
- revocar sesión;
- desactivar agente;
- cambiar firewall;
- eliminar VM.
Respuesta orientativa
| Acción | Modelo |
|---|---|
| Bloquear IP | Automática |
| Revocar sesión | Automática |
| Desactivar agente | Condicionada |
| Cambiar firewall | Human approval |
| Eliminar VM | Human approval |
Reconstruye un incidente a partir de 12 eventos proporcionados por el SIEM.
El objetivo es identificar:
- initial access;
- execution;
- privilege escalation;
- data access;
- exfiltration;
- containment.
32. Preguntas de comprobación
Pregunta 1
¿Por qué no basta con utilizar un SIEM tradicional para proteger agentes?
Respuesta
Porque un SIEM tradicional puede recoger logs de infraestructura, pero el ecosistema de agentes introduce eventos específicos como prompts, tool calls, memoria, contexto, comportamiento del modelo y delegación entre agentes.
Pregunta 2
¿Por qué es importante correlacionar eventos?
Respuesta
Porque un ataque suele estar compuesto por múltiples acciones que individualmente pueden parecer legítimas. La correlación permite identificar la cadena completa.
Pregunta 3
¿Qué diferencia existe entre un evento y un incidente?
Respuesta
Un evento es una observación individual. Un incidente representa una situación de seguridad que requiere investigación o respuesta. Varios eventos pueden formar un único incidente.
Pregunta 4
¿Por qué un agente de seguridad también necesita seguridad?
Respuesta
Porque tiene acceso a información altamente sensible y, potencialmente, a herramientas de respuesta. Si es comprometido, el atacante podría utilizarlo para obtener visibilidad y capacidad de respuesta dentro del propio SOC.
Pregunta 5
¿Por qué la autonomía debe estar limitada por políticas?
Respuesta
Porque una recomendación correcta no implica que la acción sea segura en cualquier circunstancia. Las acciones deben estar limitadas por identidad, contexto, riesgo, reversibilidad y autorización.
Pregunta 6
¿Qué es el blast radius?
Respuesta
Es el alcance potencial del impacto si un componente queda comprometido. Cuantas más capacidades y privilegios tenga un agente, mayor será su blast radius.
33. Caso práctico completo
Escenario
Una empresa tiene un agente denominado:
Cloud-Operations-AgentPuede:
- consultar infraestructura;
- reiniciar servicios;
- modificar reglas de firewall;
- consultar logs;
- crear tickets.
Incidente
El AI-SOC detecta:
09:21
User login from unusual location
09:23
Prompt anomaly
09:24
Agent accesses firewall tool
09:24
Agent queries sensitive infrastructure
09:25
External destination contacted
09:26
Large response generated
Investigación
Risk
| Factor | Risk |
|---|---|
| Identity anomaly | High |
| Prompt anomaly | Medium |
| Firewall tool | Critical |
| Sensitive data | Critical |
| External connection | Critical |
Respuesta
34. Forensics de agentes
Una característica importante del AI-SOC será poder reconstruir exactamente qué ocurrió.
Para ello necesitamos conservar:
- identidad;
- session ID;
- correlation ID;
- model version;
- prompt metadata;
- tool calls;
- tool responses;
- memory operations;
- network events;
- policy decisions.
No siempre es necesario almacenar el contenido completo de cada prompt o respuesta. El diseño de telemetría debe tener en cuenta privacidad, minimización de datos, cumplimiento y protección de información sensible.
35. Incident Response Lifecycle para IA
Inventario, políticas, playbooks, logging y herramientas.
Identificación de comportamiento anómalo.
Reconstrucción del ataque.
Aislamiento del agente, identidad o sistema.
Eliminación de la causa.
Restauración controlada.
Convertir el incidente en nuevas defensas y tests.
36. Mean Time To Detect
Una métrica fundamental del SOC es:
MTTD =
Mean Time To Detect
En agentes debemos medir también:
- time to detect;
- time to understand;
- time to contain;
- time to recover.
Una organización puede tener excelentes controles preventivos y aun así necesitar mejorar enormemente su capacidad de detección.
37. Mean Time To Respond
MTTR =
Mean Time To Respond
La automatización puede reducirlo.
Pero la velocidad nunca debe estar por encima de la seguridad de la acción.
38. Security Automation Maturity
| Nivel | Descripción |
|---|---|
| Level 0 | Manual |
| Level 1 | Alert automation |
| Level 2 | Enrichment automation |
| Level 3 | Response playbooks |
| Level 4 | Adaptive response |
| Level 5 | AI-assisted SOC |
39. El SOC del futuro
La idea no es crear un SOC completamente autónomo sin supervisión.
La idea es construir un SOC donde humanos y agentes colaboren, cada uno realizando aquello para lo que es más eficiente.
40. Human + AI Security Team
| Actividad | Humano | IA |
|---|---|---|
| Buscar eventos | △ | ✓ |
| Correlacionar millones de eventos | △ | ✓ |
| Contextualizar incidente | ✓ | ✓ |
| Decisión crítica | ✓ | △ |
| Bloqueo de IOC conocido | △ | ✓ |
| Gestión estratégica | ✓ | △ |
41. GRAN PROYECTO · Build an AI-SOC
Construye una plataforma conceptual y posteriormente funcional que permita monitorizar y responder frente a una infraestructura de agentes.
Arquitectura mínima
Funcionalidades
- Registro de agentes.
- Inventario de herramientas.
- Inventario de identidades.
- Ingesta de eventos.
- Normalización.
- Detecciones.
- Correlación.
- Risk scoring.
- Incident management.
- Playbooks.
- Respuesta automática.
- Human approval.
- Audit trail.
- Dashboard.
42. Modelo de datos
Como mínimo deberíamos tener entidades similares a:
agents
users
identities
tools
models
sessions
events
alerts
incidents
detections
risk_scores
playbooks
actions
approvals
audit_logs
Relaciones
43. API conceptual
El AI-SOC debe exponer APIs para integrar agentes y sistemas.
POST /api/events
POST /api/alerts
GET /api/incidents
GET /api/agents
GET /api/agents/{id}/risk
POST /api/incidents/{id}/investigate
POST /api/incidents/{id}/contain
POST /api/actions/{id}/approve
GET /api/audit
La API también debe estar protegida mediante autenticación fuerte, autorización granular y auditoría.
44. Dashboard de incidente
Un analista debería poder abrir un incidente y ver:
45. Métricas del AI-SOC
| Métrica | Objetivo |
|---|---|
| MTTD | Reducir |
| MTTR | Reducir |
| Detection Rate | Aumentar |
| False Positive Rate | Reducir |
| Coverage | Aumentar |
| Automation Rate | Aumentar controladamente |
| Critical Incidents | Reducir |
| Unmanaged Agents | Reducir a cero |
46. AI-SOC Maturity Model
Logs básicos.
Centralización y SIEM.
Detección específica de IA.
Correlación y risk engine.
SOAR y automatización.
AI-assisted SOC.
Continuous autonomous security con control humano.
47. Conexión con Red Team
Ahora podemos cerrar el círculo iniciado en Cybersecurity-15.
Cada ataque del Red Team debe convertirse en una oportunidad para crear una nueva detección.
48. Continuous Security Loop
49. Ejercicio experto
Tienes 500 agentes.
Cada agente genera 1.000 eventos por minuto.
¿Cuántos eventos por minuto debe procesar el AI-SOC?
Respuesta
500 × 1,000
= 500,000 eventos/minuto
El sistema debe diseñarse para al menos ese volumen y, en una arquitectura real, incorporar capacidad adicional para picos.
Si el 1% de los eventos genera alertas, ¿cuántas alertas por minuto tendríamos?
Respuesta
500,000 × 0.01
= 5,000 alerts/minute
Este resultado demuestra por qué no podemos convertir cada evento sospechoso directamente en un incidente.
50. El problema de escala
Este cálculo revela una de las cuestiones fundamentales de la ciberseguridad moderna:
Por ello la IA no solo aumenta la superficie de ataque.
También puede ser necesaria para gestionar la propia complejidad defensiva.
51. Principios arquitectónicos del AI-SOC
Sin visibilidad no hay seguridad.
Ni usuarios, ni agentes, ni modelos, ni herramientas.
Un evento aislado raramente cuenta toda la historia.
La automatización debe estar gobernada por políticas.
Especialmente en agentes de seguridad.
Cada incidente debe mejorar el sistema.
52. Recursos y referencias
Base para modelar técnicas, tácticas y procedimientos de ataque.
Marco especialmente relevante para amenazas contra sistemas de Machine Learning e Inteligencia Artificial.
Referencia para riesgos específicos de aplicaciones GenAI.
Marco de gestión del riesgo asociado a sistemas de IA.
Marco para gobernar las capacidades de ciberseguridad.
Tecnologías fundamentales para construir el pipeline operativo de un SOC moderno.
53. Checklist final
| Área | Completado |
|---|---|
| Agent inventory | ☐ |
| Identity inventory | ☐ |
| Tool inventory | ☐ |
| Telemetry | ☐ |
| Normalization | ☐ |
| SIEM | ☐ |
| Detection | ☐ |
| UEBA | ☐ |
| Correlation | ☐ |
| Risk Engine | ☐ |
| Threat Intelligence | ☐ |
| Incident Management | ☐ |
| SOAR | ☐ |
| Human Approval | ☐ |
| Audit | ☐ |
| Red Team Integration | ☐ |
54. Lo que debes recordar
01. Un AI-SOC amplía el SOC tradicional para comprender sistemas de IA.
02. Los agentes deben generar telemetría de seguridad.
03. Prompt, contexto, memoria y tool calls forman parte de la superficie observable.
04. Un evento aislado no siempre constituye un incidente.
05. La correlación permite descubrir attack chains.
06. UEBA permite detectar desviaciones de comportamiento.
07. El Risk Engine debe combinar múltiples señales.
08. SOAR permite automatizar respuesta.
09. La autonomía debe estar limitada por políticas.
10. Los agentes utilizados por el SOC también deben protegerse.
11. Red Team y AI-SOC deben funcionar como un ciclo continuo.
12. La seguridad moderna debe aprender continuamente de los ataques.
55. Preparación para Cybersecurity-17
Hasta ahora hemos construido:
Pero todavía falta analizar una superficie que puede comprometer toda la arquitectura:
AI Supply Chain Security
Modelos externos, librerías, paquetes, embeddings, datasets, contenedores, APIs, proveedores de modelos, plugins, herramientas y componentes open source pueden introducir riesgos antes incluso de que nuestro agente empiece a ejecutarse.
En Cybersecurity-17 construiremos un modelo de seguridad para la cadena de suministro de IA y aprenderemos a analizarla como analizaríamos una cadena de suministro de software crítica.