Seguridad Agéntica de Confianza Cero

license: Apache-2.0 name: agentic-zero-trust-security description: | Seguridad criptográfica para sistemas agénticos — redes de confianza cero para agentes, sobres de mensajes firmados (JWS/JWE), seguridad basada en capacidades (ocaps), árboles Merkle de auditoría, aislamiento WASM y verificación formal. Cubre seguridad de herramientas CLI, mTLS entre agentes, límites de permisos (mínimo privilegio para agentes de IA) y seguridad en la cadena de suministro de habilidades/plugins. Activar con: "seguridad de agentes", "agentes de confianza cero", "comunicación segura de agentes", "seguridad basada en capacidades", "ocap", "mensajes firmados entre agentes", "registro de auditoría de agentes", "ejecución aislada de agentes", "permisos de agentes", "agentes mTLS", "verificación criptográfica", "cadena de suministro de agentes", "OWASP agéntico", "probar que el agente hizo X", "registros de agentes a prueba de manipulaciones". NO para: escaneo SAST a nivel de aplicación (usar security-auditor), reglas de firewall de red (usar infrastructure), cumplimiento SOC2/HIPAA (organizacional) o defensa contra inyección de prompts (usar prompt-engineer). allowed-tools: Read,Write,Edit,Bash,Glob,Grep,WebSearch,WebFetch metadata: category: Seguridad y Confianza tags: - confianza-cero - criptografía - seguridad-agentes - seguridad-capacidades - mTLS - registro-auditoría - aislamiento - WASM - ocap - verificación-formal pairs-with: - skill: coordinación-multi-agente reason: Asegura los canales de comunicación en los que se basan los sistemas multi-agente - skill: protocolos-de-conversación-de-agentes reason: Firma y verificación de sobres de mensajes para protocolos de agentes - skill: auditor-de-seguridad reason: Complementa el SAST a nivel de código con patrones de seguridad arquitectónica category: Seguridad tags:

• confianza-cero
• seguridad
• agentes
• autenticación
• autorización

---

¿Qué hace Seguridad Agéntica de Confianza Cero?

Arquitectura de seguridad criptográfica para sistemas autónomos de agentes de IA. Esta habilidad cubre la intersección entre la ingeniería de seguridad tradicional y los desafíos únicos de los agentes que planifican, persisten, delegan y ejecutan a través de límites de confianza.

Principio central: Nunca confíes, siempre verifica — aplicado a cada mensaje entre agentes, cada habilidad cargada, cada herramienta invocada y cada resultado devuelto.

Puntos de Decisión

1. Nivel de Amenaza → Estrategia de Verificación

Evaluación del Nivel de Amenaza:
├── PÚBLICO (agentes de internet, habilidades desconocidas)
│   ├── Acciones: mTLS completo + JWS + tokens de capacidad + aislamiento WASM
│   ├── Auditoría: Cada acción registrada con prueba Merkle
│   └── TTL: Vida útil máxima de capacidad de 5 min
├── INTERNO (clúster de agentes confiables)
│   ├── Acciones: mTLS + JWS + capacidades (TTL más largo)
│   ├── Auditoría: Registro agregado con publicación raíz diaria
│   └── TTL: Vida útil máxima de capacidad de 1 hora
└── DESARROLLO/PRUEBAS (localhost, desarrollo)
    ├── Acciones: mTLS opcional + capacidades básicas
    ├── Auditoría: Archivos de registro locales (sin árbol Merkle)
    └── TTL: Vida útil máxima de capacidad de 24 horas

2. Solicitud de Agente → Verificación de Capacidad → Lógica de Concesión/Denegación

Procesamiento de Solicitud de Agente Entrante:
├── 1. Verificar cadena de certificados mTLS
│   ├── ¿Firma CA válida? → Continuar
│   └── ¿Inválida/expirada? → RECHAZAR inmediatamente
├── 2. Analizar sobre de mensaje JWS
│   ├── ¿Firma válida + no expirada? → Continuar
│   ├── ¿Replay detectado (caché jti)? → RECHAZAR
│   └── ¿Firma inválida? → RECHAZAR + registrar evento de seguridad
├── 3. Verificar capacidades requeridas
│   ├── ¿El agente posee la capacidad exacta? → CONCEDER
│   ├── ¿El agente posee una capacidad más amplia? → ATENUAR + CONCEDER
│   ├── ¿Capacidad expirada? → RECHAZAR + forzar actualización
│   └── ¿Sin capacidad coincidente? → RECHAZAR + sugerir concesión mínima
└── 4. Ejecutar con restricciones de espacio aislado
    ├── Habilidades WASM: Límites de CPU/memoria aplicados
    ├── Operaciones de archivo: Validación de ruta contra capacidades
    └── Llamadas de red: Validación de destino contra capacidades

3. Cadena de Delegación → Decisión de Profundidad de Confianza

Solicitud de Delegación de Capacidad:
├── ¿Capacidad padre delegable=true?
│   ├── Sí → Verificar profundidad restante
│   │   ├── ¿Profundidad > 0? → Permitir con profundidad-1
│   │   └── ¿Profundidad = 0? → RECHAZAR (se alcanzó la delegación máxima)
│   └── No → RECHAZAR (no delegable)
├── ¿Acciones solicitadas ⊆ acciones padre?
│   ├── Sí → Permitir subconjunto
│   └── No → RECHAZAR (no se pueden escalar privilegios)
└── ¿Se cruzó el límite de confianza?
    ├── Mismo dominio de orquestador → Permitir
    └── Dominio diferente → Requerir capacidad de dominio cruzado explícita

Modos de Fallo

1. Fuga de Autoridad Ambiental

Detección: grep -r "process.env" agent_code/ muestra acceso a variables de entorno sin verificación de capacidad Síntoma: El agente accede a recursos para los que no debería tener permisos Solución: Reemplazar con tokens de capacidad explícitos limitados a los recursos exactos necesarios

2. Ataque de Replay de Mensajes

Detección: Múltiples entradas de registro de auditoría con jti idéntico (ID de mensaje) o marcas de tiempo dentro de la ventana de replay Síntoma: El agente recibe y procesa el mismo comando múltiples veces Solución: Implementar caché de deduplicación jti con TTL que coincida con la expiración del mensaje

3. Escalada de Capacidad a través de la Delegación

Detección: La capacidad hija tiene más acciones que la padre, o la profundidad de delegación excede el máximo configurado Síntoma: Los sub-agentes obtienen más privilegios de los que su delegador padre pretendía Solución: Aplicar la invariante de atenuación: capacidades hijas ⊆ capacidades padre en el momento de la delegación

4. Escape del Espacio Aislado por Agotamiento de Recursos

Detección: Uso de CPU del agente >95% durante más de 30 segundos, o uso de memoria acercándose a los límites del espacio aislado Síntoma: El agente intenta bucles infinitos o asignación excesiva de memoria para salir de las restricciones Solución: Matar forzosamente el proceso del agente en los límites de recursos, implementar medición de ejecución basada en combustible

5. Aceptación de Certificado TOFU (Trust-on-First-Use)

Detección: El agente acepta un certificado sin verificación CA en la primera conexión Síntoma: Los ataques de intermediario tienen éxito al presentar cualquier certificado Solución: Preaprovisionar todos los certificados de agente, mantener un almacén de confianza explícito, rechazar CAs desconocidas

Ejemplos Prácticos

Ejemplo 1: Pipeline de Firma de Mensajes Multi-Agente

Escenario: El agente de investigación necesita pasar el análisis al agente de generación de código, luego al agente de revisión.

Fase de Configuración:

// El orquestador acuña capacidades
const researchCap = mint.mint('fs:/tmp/research/**', ['read','write'], 'agent-research-001');
const codegenCap = mint.mint('fs:/workspace/src/**', ['read','write'], 'agent-codegen-001'); 
const reviewCap = mint.mint('fs:/workspace/**', ['read'], 'agent-review-001');

Flujo de Mensajes:

1. Investigación → Codegen: El agente de investigación crea un mensaje firmado con JWS:

   Header: {alg: 'EdDSA', kid: 'agent-research-001/v1'}
   Payload: {
     iss: 'agent-research-001',
     sub: 'agent-codegen-001', 
     dag_id: 'proj-alpha-v1',
     action: 'task',
     body: {analysis: "API necesita flujo OAuth2", output_path: "/tmp/research/api_analysis.json"}
   }
   

2. Verificación Codegen: El agente de generación de código recibe el mensaje:

   • Verifica la firma JWS contra la clave pública del agente de investigación
   • Comprueba el TTL del mensaje (no expirado)
   • Valida que jti no esté en la caché de replay
   • Confirma que dag_id coincide con el contexto de ejecución actual
   • Captura experta: Verifica que el agente de investigación tenía capacidad para output_path

3. Codegen → Review: El generador de código crea un resultado firmado:

   {
     "iss": "agent-codegen-001",
     "sub": "agent-review-001",
     "action": "result", 
     "body": {"archivos_generados": ["/workspace/src/auth.ts"], "confianza": 0.87}
   }
   

Error de novato: Omitiría la protección de replay jti, permitiendo el procesamiento duplicado. Perspectiva experta: El registro de auditoría muestra la cadena de mensajes completa con prueba criptográfica de custodia.

Ejemplo 2: Emisión de Token de Capacidad con Atenuación

Escenario: El agente principal necesita delegar el análisis de archivos a un sub-agente especializado, pero restringir el acceso a directorios sensibles.

Concesión Inicial:

// El orquestador concede acceso amplio al sistema de archivos
const mainCap = mint.mint('fs:/project/**', ['read','write','execute'], 'agent-main', {
  delegatable: true,
  maxDepth: 2,
  ttlSeconds: 3600
});

Árbol de Decisión de Atenuación:

Agente principal evaluando solicitud de delegación:
├── Sub-agente solicita: fs:/project/src/** [leer]
│   ├── /project/src/** ⊂ /project/** ? SÍ
│   ├── [leer] ⊂ [leer,escribir,ejecutar] ? SÍ  
│   ├── Profundidad de delegación 2 > 0 ? SÍ
│   └── CONCEDER: Crear capacidad atenuada
├── Sub-agente solicita: fs:/project/secrets/** [leer]  
│   ├── La ruta contiene "secrets" → Violación de política de seguridad
│   └── RECHAZAR: Exclusión de ruta sensible
└── Sub-agente solicita: fs:/etc/passwd [leer]
    ├── /etc/passwd ⊂ /project/** ? NO
    └── RECHAZAR: Fuera del alcance autorizado

Capacidad Atenuada Generada:

const subCap = mint.attenuate(mainCap, 'agent-analyzer-001', ['read']);
// Resulta en: fs:/project/src/** [leer] delegable=true maxDepth=1 ttl=3600s

Error de novato: Concedería la capacidad padre completa sin restricción. Perspectiva experta: La atenuación aplica "nunca escalar privilegios" a nivel criptográfico.

Ejemplo 3: Detección de Violación de Política de Espacio Aislado con Análisis de Compensaciones

Escenario: El agente de generación de código intenta acceder a la red durante la ejecución, violando la política del espacio aislado.

Configuración del Espacio Aislado:

const codegenSandbox = {
  fileRead: ['/workspace/src/**', '/workspace/package.json'],
  fileWrite: ['/workspace/src/**'], 
  netConnect: false,  // SIN acceso a la red
  maxExecutionMs: 300000,
  maxMemoryMb: 512
};

Flujo de Detección de Violación:

1. Acción del Agente: El generador de código intenta fetch('https://api.github.com/repos/...')

2. Interceptación del Aislador: El runtime WASM detecta la syscall para el socket de red

3. Verificación de Política: netConnect: false → VIOLACIÓN DETECTADA

4. Análisis de Compensaciones:

   Compensaciones entre Seguridad y Funcionalidad:
   ├── ESTRICTO (actual): Bloquear red, terminar agente
   │   ├── Pro: Superficie de ataque de red cero
   │   ├── Contra: No puede obtener dependencias/documentación externas
   │   └── Decisión: APLICAR (entorno de seguridad primero)
   ├── MODERADO: Permitir dominios específicos en lista blanca
   │   ├── Pro: Funcional para APIs conocidas y seguras  
   │   ├── Contra: Riesgos de envenenamiento DNS, subdominio takeover
   │   └── Decisión: Considerar solo para entornos de desarrollo
   └── PERMISIVO: Registrar pero permitir
       ├── Pro: Funcionalidad completa preservada
       ├── Contra: El agente puede filtrar datos, descargar malware
       └── Decisión: RECHAZAR (viola el modelo de confianza cero)
   

5. Respuesta: Terminar agente, registrar evento de seguridad:

   {
     "event": "violacion_aislador",
     "agent_id": "agent-codegen-001", 
     "violation_type": "acceso_red_no_autorizado",
     "attempted_url": "api.github.com",
     "policy_matched": "netConnect: false",
     "action_taken": "terminar_agente"
   }
   

Error de novato: Permitiría el acceso a la red "solo esta vez" o no detectaría la violación. Perspectiva experta: Las violaciones del aislador indican un posible compromiso o deriva del modelo; siempre aplicar estrictamente.

Puertas de Calidad

• Cada agente tiene una identidad criptográfica única (par de claves Ed25519 + certificado)
• Todos los canales agente-a-agente usan TLS mutuo con verificación de certificado
• Todos los mensajes llevan firmas JWS con TTL <5 min y protección de replay jti
• Los tokens de capacidad siguen el modelo ocap (sin autoridad ambiental en ninguna parte)
• La delegación de capacidad preserva la invariante de atenuación (hijo ⊆ privilegios padre)
• El registro de auditoría usa un árbol Merkle de solo añadidura con raíces publicadas
• Toda la ejecución de habilidades ocurre en un aislador WASM o contenedor
• Se aplican límites de recursos (CPU, memoria, tiempo de ejecución, red)
• Los paquetes de habilidades se direccionan por contenido y están firmados por el autor
• Ningún agente acepta habilidades/entradas sin firmar o sin verificar
• Rotación de certificados automatizada con vida útil del certificado <24 horas
• Caché de detección de replay operativa con TTL que coincide con la expiración del mensaje
• Todas las violaciones de seguridad registradas con marca de tiempo + identidad del agente + acción tomada

LÍMITES DE NO APLICACIÓN

Esta habilidad NO debe usarse para:

• Escaneo de vulnerabilidades a nivel de aplicación → Usar security-auditor en su lugar
• Configuración de firewall de red/WAF → Usar infrastructure-engineer en su lugar
• Documentación de cumplimiento SOC2/HIPAA → Usar procesos organizacionales de cumplimiento
• Defensa contra inyección de prompts → Usar la habilidad prompt-engineer en su lugar
• Limitación de tasa o protección DDoS → Usar configuración de API Gateway
• Seguridad de orquestación de contenedores → Usar la habilidad devops-automator en su lugar

Límites de delegación:

• Para problemas de seguridad a nivel de código → security-auditor
• Para endurecimiento de infraestructura → infrastructure-engineer
• Para prácticas de codificación segura → software-engineer
• Para respuesta a incidentes → security-incident-response