01. El siguiente salto
En las semanas anteriores hemos ido construyendo piezas independientes del sistema.
Ahora queremos integrarlo todo.
02. ¿Qué es un sistema multiagente?
Un sistema multiagente está compuesto por diferentes agentes especializados que colaboran para conseguir un objetivo.
En lugar de pedirle a un único LLM que haga absolutamente todo, dividimos el problema.
ONE BIG AGENT "Analyze this incident, search everything, decide what happened, and fix it."
frente a:
TRIAGE AGENT
↓
INVESTIGATION AGENT
↓
THREAT HUNT AGENT
↓
THREAT INTELLIGENCE AGENT
↓
DECISION AGENT
↓
RESPONSE AGENT
↓
REVIEW AGENT
03. ¿Por qué no utilizar un único agente?
Complejidad
Un agente con demasiadas responsabilidades tiene contextos enormes y reglas difíciles de controlar.
Permisos
No todos los agentes necesitan capacidad para ejecutar acciones sobre infraestructura.
Seguridad
Separar responsabilidades reduce el impacto de un error o compromiso.
Especialización
Un agente puede estar optimizado para una tarea concreta.
04. Agente no significa simplemente "un chatbot"
Un agente de seguridad debe tener varios componentes.
La combinación de estos componentes es lo que convierte un modelo en un agente operativo.
05. Modelo mental del agente
Este ciclo es especialmente importante en seguridad.
El agente no debería ejecutar una secuencia completamente ciega.
Después de cada acción debe analizar el resultado.
06. Los agentes del AI-SOC
| Agent | Responsabilidad |
|---|---|
| Triage Agent | Clasificar y priorizar alertas. |
| Investigation Agent | Investigar incidentes. |
| Threat Hunting Agent | Buscar actividad sospechosa no detectada. |
| Threat Intelligence Agent | Analizar indicadores y contexto externo. |
| Detection Engineer Agent | Crear o mejorar detecciones. |
| Response Agent | Proponer y ejecutar respuestas autorizadas. |
| Reviewer Agent | Revisar decisiones y evidencias. |
| Orchestrator | Coordinar el sistema. |
07. Arquitectura general
08. El Orchestrator
El Orchestrator es el cerebro de coordinación.
No necesariamente realiza la investigación.
Su responsabilidad es decidir:
- Qué agente debe intervenir.
- Qué información necesita.
- En qué orden deben ejecutarse las tareas.
- Cuándo debe detenerse el proceso.
- Cuándo debe escalar a un humano.
09. Ejemplo de Orchestration
ALERT ↓ ORCHESTRATOR ↓ "Need triage" ↓ TRIAGE AGENT ↓ CRITICAL ↓ ORCHESTRATOR ↓ "Need investigation" ↓ INVESTIGATION AGENT ↓ "Need external context" ↓ THREAT INTELLIGENCE AGENT ↓ "Need historical evidence" ↓ THREAT HUNT AGENT ↓ "Need containment recommendation" ↓ RESPONSE AGENT
10. Agent Contracts
Cada agente debería tener un contrato explícito.
AGENT: Threat Intelligence Agent INPUT: IP Domain Hash URL OUTPUT: Reputation Sources Confidence Related campaigns Known techniques
El agente no debería devolver información arbitraria si otro componente depende de él.
11. Structured Agent Output
{
"agent": "threat_intelligence",
"status": "completed",
"entities": [
{
"type": "ip",
"value": "185.x.x.x"
}
],
"reputation": "malicious",
"confidence": 0.93,
"techniques": [
"T1071.001"
],
"sources": [
"source-01",
"source-02"
]
}
La estructura permite que otros agentes consuman el resultado sin tener que interpretar lenguaje natural.
12. Agent State
Cada agente debe mantener un estado controlado.
CREATED ↓ RUNNING ↓ WAITING ↓ EXECUTING ↓ COMPLETED or FAILED or ESCALATED
Esto permite recuperar procesos después de fallos.
13. Shared Context
Los agentes necesitan compartir información.
14. Shared Memory vs Agent Memory
| Memory | Uso |
|---|---|
| Incident Memory | Información específica del incidente. |
| Agent Memory | Estado interno del agente. |
| Knowledge Base | Conocimiento general. |
| Threat Intelligence | Información sobre amenazas. |
| Historical Cases | Incidentes anteriores. |
15. Memory Architecture
16. RAG para Cybersecurity
RAG significa Retrieval Augmented Generation.
En lugar de esperar que el modelo conozca toda la información, el sistema recupera información relevante.
QUESTION
"What does our policy say about
isolating production servers?"
↓
SEARCH
↓
Security Policy
↓
RETRIEVE
↓
Relevant paragraphs
↓
LLM
↓
Decision
17. Fuentes de conocimiento
Security Policies
Normas internas.
Runbooks
Procedimientos operativos.
MITRE ATT&CK
Técnicas y tácticas.
Historical Incidents
Casos anteriores.
Architecture
Información sobre infraestructura.
Threat Intelligence
Contexto externo.
18. Tool Calling
Un agente de seguridad necesita herramientas.
TOOLS ├── search_logs() ├── search_edr() ├── lookup_ip() ├── lookup_hash() ├── query_dns() ├── query_identity() ├── create_incident() ├── isolate_host() ├── disable_account() ├── create_ticket() └── send_notification()
La IA decide cuándo utilizar una herramienta, pero la herramienta debe controlar qué está permitido.
19. Tool Permission Matrix
| Tool | Triage | Investigation | Response |
|---|---|---|---|
| search_logs | ✓ | ✓ | ✓ |
| lookup_ip | ✓ | ✓ | ✓ |
| isolate_host | ✗ | ✗ | ✓ |
| disable_account | ✗ | ✗ | Approval |
20. Nunca confiar únicamente en el prompt
Escribir:
"You must never disable production accounts without approval."
no sustituye a una política técnica.
La herramienta debe comprobarlo.
if action == "disable_account":
if target.environment == "production":
require_human_approval()
21. Agent-to-Agent Communication
Los agentes necesitan intercambiar mensajes.
FROM:
investigation-agent
TO:
threat-hunting-agent
MESSAGE:
{
"request": "search_lateral_movement",
"entities": [
"admin01",
"HOST-042",
"SERVER-02"
],
"time_window": "24h"
}
22. Message Bus
En arquitecturas grandes puede utilizarse un sistema de mensajería.
Esto desacopla los agentes y facilita escalar el sistema.
23. Event Driven Security
EVENT:
SuspiciousLoginDetected
↓
EVENT BUS
↓
┌───────────────┬───────────────┐
│ │ │
▼ ▼ ▼
TRIAGE IDENTITY HUNT
AGENT AGENT AGENT
│ │ │
└───────────────┼───────────────┘
▼
INCIDENT
24. Parallel Investigation
Una de las grandes ventajas de los sistemas multiagente es poder investigar diferentes dimensiones simultáneamente.
INCIDENT
│
┌──────────┼──────────┐
│ │ │
▼ ▼ ▼
IDENTITY EDR NETWORK
AGENT AGENT AGENT
│ │ │
└──────────┼──────────┘
▼
CORRELATION
Esto puede reducir considerablemente el tiempo de investigación.
25. Dependency Management
No todas las tareas pueden ejecutarse simultáneamente.
Triage
│
▼
Classification
│
├────────► Threat Intel
│
└────────► Investigation
│
▼
Correlation
│
▼
Decision
El Orchestrator debe conocer estas dependencias.
26. Planning
El agente puede generar un plan de investigación.
PLAN 1. Identify affected account 2. Review authentication 3. Review MFA 4. Inspect endpoint 5. Search lateral movement 6. Check threat intelligence 7. Correlate evidence 8. Calculate confidence 9. Recommend response
El plan debe poder ser inspeccionado antes de ejecutar acciones de alto impacto.
27. Plan Validation
El sistema debe evitar planes que contengan acciones no autorizadas.
28. Supervisor Agent
Introducimos un componente adicional:
Su objetivo es revisar el comportamiento de otros agentes.
INVESTIGATION AGENT
↓
"Credential compromise"
↓
SUPERVISOR
↓
Check:
Evidence?
Alternative hypotheses?
Confidence?
Policy?
Consistency?
↓
APPROVE
or
REQUEST MORE EVIDENCE
29. Agent Debate
En determinados casos podemos utilizar varios agentes con perspectivas diferentes.
INVESTIGATOR: Likely credential compromise. THREAT HUNTER: Evidence of lateral movement. REVIEWER: Could be legitimate admin activity. SUPERVISOR: Need additional evidence.
Esto evita que la primera hipótesis se convierta automáticamente en la conclusión final.
30. Alternative Hypotheses
Un sistema profesional debe considerar explicaciones alternativas.
| Hypothesis | Evidence | Confidence |
|---|---|---|
| Credential compromise | Impossible travel + PowerShell | 0.82 |
| VPN configuration | Known corporate VPN | 0.31 |
| Administrator activity | Scheduled maintenance | 0.22 |
31. Evidence First
El flujo correcto es:
OBSERVE ↓ COLLECT ↓ CORRELATE ↓ HYPOTHESIZE ↓ TEST ↓ CONCLUDE
32. Evidence Graph
33. Agent Observability
Si el sistema tiene diez agentes funcionando, debemos poder saber qué está haciendo cada uno.
Necesitamos observar:
- Agent execution time.
- Tokens utilizados.
- Tools invoked.
- Errors.
- Retries.
- Decisions.
- Escalations.
- Actions.
34. Agent Trace
TRACE-ID: a8f4-91cd 12:00:01 orchestrator.start 12:00:02 triage.start 12:00:04 triage.complete 12:00:05 investigation.start 12:00:06 tool.search_logs 12:00:08 tool.search_edr 12:00:11 investigation.complete 12:00:12 review.start 12:00:15 review.complete 12:00:16 decision.created
35. Cost Management
Un AI-SOC puede generar un coste considerable si cada agente utiliza modelos grandes para cada tarea.
Debemos utilizar modelos adecuados a cada función.
| Task | Modelo |
|---|---|
| Classification | Small / Fast |
| Extraction | Small / Fast |
| Investigation | Medium / Advanced |
| Complex reasoning | Advanced |
| Final review | Advanced |
36. Model Routing
TASK
↓
CLASSIFY COMPLEXITY
│
├── LOW ──► SMALL MODEL
│
├── MEDIUM ─► MEDIUM MODEL
│
└── HIGH ──► ADVANCED MODEL
Esto permite reducir costes y latencia.
37. Context Engineering
No debemos enviar todo el contexto disponible a todos los agentes.
Cada agente debería recibir exactamente la información que necesita.
RAW DATA ↓ FILTER ↓ RELEVANT CONTEXT ↓ AGENT
Esto mejora precisión, reduce costes y limita exposición de información.
38. Context Isolation
Ejemplo:
Threat Intelligence Agent CAN READ: IPs Domains Hashes CANNOT READ: Payroll HR Personal documents
39. Agent Identity
Cada agente debería tener una identidad técnica.
agent-triage agent-investigation agent-hunting agent-intelligence agent-response agent-review
Esto permite aplicar:
- Authentication
- Authorization
- Audit
- Rate limiting
- Resource isolation
40. Zero Trust para agentes
La misma filosofía Zero Trust que aplicamos a usuarios, dispositivos y servicios debe aplicarse a agentes de IA.
41. Agent Compromise
Por ejemplo:
- Prompt injection.
- Tool poisoning.
- Context manipulation.
- Memory poisoning.
- Credential theft.
- Model manipulation.
42. Memory Poisoning
Imaginemos que un atacante consigue introducir información maliciosa en la memoria persistente.
MEMORY "185.x.x.x is a trusted corporate IP."
Si posteriormente el sistema utiliza esa memoria, podría ignorar un indicador malicioso.
Por eso la memoria debe tener:
- Provenance.
- Timestamp.
- Confidence.
- Source.
- Expiration.
43. Provenance
Cada dato debería responder a:
WHERE DID THIS INFORMATION COME FROM?
Ejemplo:
IOC: 185.x.x.x SOURCE: Threat Intelligence Provider COLLECTED: 2026-08-29 CONFIDENCE: 0.94 VALID UNTIL: 2026-09-05
44. Knowledge Expiration
La información de seguridad cambia.
Una IP maliciosa puede dejar de serlo.
Una vulnerabilidad puede ser parcheada.
Una cuenta puede cambiar de privilegios.
Por tanto:
KNOWLEDGE + TIMESTAMP + TTL + SOURCE
45. Confidence Propagation
La confianza debería propagarse entre agentes.
Threat Intel
Confidence:
0.92
↓
Investigation
Confidence:
0.88
↓
Correlation
Confidence:
0.91
↓
Final Decision
Confidence:
0.89
Pero nunca debemos multiplicar o combinar scores de forma ingenua. La metodología de calibración debe definirse.
46. Human-in-the-Loop
47. Human Override
El humano debe poder detener al sistema.
AI ACTION ↓ RUNNING ↓ ANALYST: STOP ↓ CANCEL ↓ ROLLBACK IF REQUIRED
Esta capacidad es especialmente importante en acciones contra infraestructura crítica.
48. Kill Switch
GLOBAL KILL SWITCH ↓ STOP ALL RESPONSE ACTIONS ↓ FREEZE AGENTS ↓ PRESERVE STATE ↓ ALERT SECURITY TEAM
49. Autonomy Levels
| Level | Capability |
|---|---|
| L0 | AI only observes. |
| L1 | AI recommends. |
| L2 | AI executes low-risk actions. |
| L3 | AI executes predefined containment. |
| L4 | AI manages complex response under policies. |
La autonomía debería aumentar gradualmente, no activarse de golpe.
50. ¿Qué significa autonomía segura?
Autonomía no significa:
Significa:
51. Caso práctico completo
Ataque mediante credenciales comprometidas
08:41 Suspicious authentication User: admin01 08:42 PowerShell detected 08:43 SMB connections 08:44 Suspicious external IP 08:45 SIEM generates alert
52. Caso — Orchestration
ALERT
↓
ORCHESTRATOR
↓
TRIAGE AGENT
↓
CRITICAL
↓
PARALLEL INVESTIGATION
┌───────────────┐
│ │
▼ ▼
IDENTITY EDR
AGENT AGENT
│ │
▼ ▼
AUTH EVENTS PROCESS TREE
│
▼
NETWORK AGENT
│
▼
THREAT INTEL AGENT
53. Caso — Correlation
IDENTITY:
Impossible travel
EDR:
PowerShell
NETWORK:
SMB lateral movement
THREAT INTEL:
Suspicious destination
↓
CORRELATION ENGINE
↓
LIKELY COMPROMISE
Confidence:
0.93
54. Caso — Supervisor
SUPERVISOR:
Could this be legitimate?
Check:
Maintenance window?
Known VPN?
Administrator ticket?
Expected PowerShell?
Expected SMB?
↓
No matching activity
↓
Hypothesis strengthened
55. Caso — Decision
DECISION AGENT Risk: 94 Confidence: 0.93 Recommended: 1. Isolate HOST-042 2. Revoke sessions 3. Reset credentials 4. Investigate SERVER-02 High impact action: ISOLATE HOST-042 Approval: REQUIRED
56. Caso — Response
ANALYST:
APPROVE
↓
POLICY ENGINE
↓
ALLOW
↓
RESPONSE AGENT
↓
EDR
↓
HOST ISOLATED
↓
VERIFY
↓
CONTAINED
57. Caso — Learning
Después del incidente:
INCIDENT ↓ ROOT CAUSE ↓ NEW IOC ↓ NEW DETECTION ↓ NEW HUNT ↓ PLAYBOOK UPDATE ↓ KNOWLEDGE UPDATE
El sistema aprende operacionalmente a partir de los incidentes.
58. AI-SOC Learning Loop
59. Agent Evaluation
Los agentes también deben evaluarse.
| Metric | Pregunta |
|---|---|
| Accuracy | ¿La conclusión era correcta? |
| Evidence Quality | ¿Utilizó evidencia adecuada? |
| Tool Efficiency | ¿Utilizó demasiadas herramientas? |
| Latency | ¿Cuánto tardó? |
| Cost | ¿Cuánto costó? |
| Safety | ¿Intentó acciones no permitidas? |
60. Golden Dataset
Para evaluar nuestro AI-SOC necesitamos casos conocidos.
CASE-001 Credential compromise Expected: CRITICAL CASE-002 Legitimate VPN login Expected: LOW CASE-003 Ransomware Expected: CRITICAL CASE-004 Admin maintenance Expected: MEDIUM CASE-005 Phishing Expected: HIGH
El sistema se ejecuta contra estos casos antes de desplegar cambios.
61. Regression Testing
Modificar un prompt o un modelo puede cambiar el comportamiento del sistema.
Esto convierte la IA en una pieza de software que puede ser evaluada continuamente.
62. Security Testing de agentes
Debemos intentar romper nuestro propio sistema.
- Prompt injection.
- Malicious tool output.
- Fake threat intelligence.
- Memory poisoning.
- Privilege escalation.
- Unauthorized tool calls.
- Context manipulation.
- Denial of service.
63. Red Team vs AI-SOC
64. Exercise — diseñar tu AI-SOC
Ejercicio principal
Diseña una arquitectura multiagente para una empresa de 5.000 empleados.
La organización dispone de:
- SIEM
- EDR
- Firewall
- IAM
- Email Security
- Cloud
- Threat Intelligence
El sistema debe ser capaz de gestionar automáticamente un incidente de compromiso de credenciales.
65. Resolución propuesta
66. Preguntas de arquitectura
¿Debe el Threat Intelligence Agent poder aislar un endpoint?
Su responsabilidad es proporcionar inteligencia. No necesita permisos de respuesta. Reducir sus privilegios limita el impacto de un compromiso o error.
¿Debe el Orchestrator ejecutar directamente comandos sobre el firewall?
Debe coordinar el proceso. La ejecución debería pasar por un Action Engine y un Policy Engine.
¿Puede un agente utilizar información obtenida de otro agente como un hecho absoluto?
Debe conocer el origen, confianza, timestamp y contexto de la información.
67. Ejercicio avanzado — diseño de permisos
Define permisos para:
| Agent | Read | Write | Execute |
|---|---|---|---|
| Triage | SIEM | Incident | No |
| Investigation | SIEM / EDR / IAM | Evidence | No |
| Hunting | Logs / EDR | Hunt results | No |
| Response | Incident / EDR | Actions | Controlled |
| Supervisor | All relevant evidence | Decision review | No |
68. Diseño del Agent Registry
El sistema debería mantener un registro de agentes.
{
"agent_id": "investigation-agent",
"version": "1.4.2",
"model": "security-model",
"capabilities": [
"log_search",
"edr_search",
"identity_search"
],
"permissions": [
"read_incident",
"write_evidence"
],
"status": "active",
"owner": "security-platform"
}
69. Versionado de agentes
Un agente no debería actualizarse sin control.
AGENT v1.2 ↓ TEST ↓ SECURITY TEST ↓ REGRESSION TEST ↓ APPROVAL ↓ DEPLOY ↓ MONITOR
Debemos poder hacer rollback a una versión anterior.
70. Deployment seguro
71. Canary Agents
Una nueva versión puede ejecutarse inicialmente solo sobre un porcentaje reducido de incidentes.
100 INCIDENTS ↓ v1.4 = 90% v1.5 = 10% ↓ COMPARE ↓ ERROR RATE ↓ SAFETY ↓ LATENCY
72. Circuit Breaker para agentes
Si un agente comienza a comportarse mal, el sistema debe poder desactivarlo automáticamente.
ERROR RATE > THRESHOLD
↓
DISABLE AGENT
↓
STOP ACTIONS
↓
FALLBACK
↓
HUMAN REVIEW
73. Fallback Architecture
El sistema debe degradarse de forma segura.
74. Security Control Plane
Llegamos a un concepto fundamental:
El Control Plane gobierna todos los agentes.
75. El AI-SOC como sistema distribuido
En este punto debemos cambiar nuestra forma de pensar.
Ya no estamos construyendo simplemente una aplicación que utiliza un LLM.
Estamos construyendo un sistema distribuido compuesto por:
- Servicios.
- Agentes.
- Modelos.
- Bases de datos.
- Message brokers.
- APIs.
- Herramientas de seguridad.
- Policies.
- Observability.
76. Arquitectura de referencia final
77. Proyecto de la Week 11
Construir AI-SOC Multi-Agent v1
El alumno debe construir una primera versión funcional de un sistema multiagente de ciberseguridad.
Agentes mínimos
- Orchestrator
- Triage Agent
- Investigation Agent
- Threat Intelligence Agent
- Threat Hunting Agent
- Response Agent
- Supervisor Agent
78. Requisitos funcionales
- Recibir una alerta.
- Crear incidente.
- Ejecutar triage.
- Distribuir tareas entre agentes.
- Recopilar evidencias.
- Compartir contexto.
- Generar hipótesis.
- Realizar Threat Hunting.
- Consultar Threat Intelligence.
- Correlacionar resultados.
- Generar decisión.
- Revisar decisión.
- Aplicar política.
- Solicitar aprobación.
- Ejecutar respuesta.
- Verificar.
- Registrar auditoría.
79. Requisitos de seguridad
| Control | Required |
|---|---|
| Agent identity | ✓ |
| RBAC | ✓ |
| Tool authorization | ✓ |
| Structured output | ✓ |
| Policy engine | ✓ |
| Human approval | ✓ |
| Audit | ✓ |
| Kill switch | ✓ |
| Rollback | ✓ |
| Agent monitoring | ✓ |
| Regression testing | ✓ |
80. Entregables
El alumno deberá entregar:
- Diagrama de arquitectura.
- Agent Registry.
- Tool Registry.
- Permission Matrix.
- Incident schema.
- Agent contracts.
- Playbook.
- Policy definitions.
- Audit schema.
- Threat model.
- Golden Dataset.
- Test cases.
- Demo funcional.
81. Reto final
Autonomous Credential Compromise Response
Construye un sistema capaz de recibir una alerta de compromiso de credenciales y llevar el incidente desde la detección hasta la contención.
82. Preguntas de evaluación
83. Checklist de arquitectura
| Control | OK |
|---|---|
| Agent registry | □ |
| Agent identity | □ |
| Agent permissions | □ |
| Tool registry | □ |
| Shared context | □ |
| Memory provenance | □ |
| Orchestrator | □ |
| Supervisor | □ |
| Policy engine | □ |
| Human approval | □ |
| Audit | □ |
| Kill switch | □ |
| Rollback | □ |
| Regression tests | □ |
| Agent monitoring | □ |
84. Referencias y recursos
MITRE ATT&CK
Utilizar ATT&CK como lenguaje común entre agentes, detecciones, hunts e investigaciones.
MITRE D3FEND
Relacionar técnicas ofensivas con controles defensivos.
NIST
Utilizar sus marcos como referencia para estructurar procesos de ciberseguridad y respuesta.
OWASP GenAI Security
Estudiar los riesgos específicos de aplicaciones basadas en LLM y sistemas agentic.
85. Conexión con las semanas anteriores
86. La arquitectura que estamos construyendo
Estamos construyendo una plataforma de operaciones de seguridad en la que la IA funciona como una capa de razonamiento y orquestación sobre una infraestructura de seguridad real.
87. Cierre de la Week 11
En esta semana hemos introducido uno de los conceptos más importantes de todo el programa: la coordinación de múltiples agentes especializados.
Hemos aprendido que un AI-SOC serio necesita mucho más que un modelo de lenguaje.
Necesita:
AGENTS + TOOLS + MEMORY + KNOWLEDGE + ORCHESTRATION + POLICIES + IDENTITY + OBSERVABILITY + HUMAN CONTROL + AUDIT
Y, sobre todo, necesita una arquitectura diseñada desde el principio para asumir que tanto los modelos como los agentes, las herramientas y los datos pueden fallar o ser atacados.
88. El siguiente nivel
A partir de aquí podemos comenzar a conectar el AI-SOC con capacidades todavía más avanzadas:
Autonomous Threat Hunting
Agentes capaces de generar hipótesis y ejecutar hunts.
Continuous Detection Engineering
Creación y validación automática de nuevas detecciones.
Security Knowledge Graph
Representar entidades, relaciones, amenazas y controles.
Autonomous Purple Team
Atacar y defender el sistema de manera coordinada.
89. Concepto fundamental para recordar
La IA por sí sola no proporciona seguridad.
La seguridad aparece cuando diseñamos correctamente:
El objetivo del curso es precisamente aprender a construir ese sistema completo.
90. Master Challenge
Diseña el AI-SOC de una empresa real
El alumno debe asumir el papel de AI Security Architect.
Debe diseñar una plataforma capaz de operar un SOC moderno utilizando IA y agentes autónomos, pero manteniendo control humano sobre las acciones críticas.
Debe responder:
- ¿Qué agentes existen?
- ¿Qué herramientas puede utilizar cada uno?
- ¿Qué datos puede consultar?
- ¿Cómo comparten contexto?
- ¿Cómo se comunican?
- ¿Cómo se coordinan?
- ¿Cómo se autentican?
- ¿Cómo se autorizan?
- ¿Cómo se auditan?
- ¿Cómo se detecta un agente comprometido?
- ¿Cómo se detiene el sistema?
- ¿Cómo se recupera de un fallo?
- ¿Cómo se evalúa la calidad de las decisiones?
- ¿Cómo aprende el sistema de los incidentes?