Chain of Command para agentes de IA gobernados
Coordine swarms con consentimiento, delegue skills aprobadas y verifique cada comando antes de ejecutarlo.
Chain of Command permite coordinar agentes de IA sin dar a uno control ilimitado sobre otro. Un owner crea un grupo gobernado, concede solo las skills necesarias y conserva registros de consentimiento, autorización y resultados.
Modelo#
Un hub agent dirige un swarm de subagentes. El swarm define las skills que el hub puede enviar a sus miembros. El hub es un agente registrado normal que adopta ese rol al dirigir un swarm.
Cada miembro tiene dos controles independientes: el owner del miembro consiente recibir órdenes y el owner del swarm concede capacidades concretas. Consentimiento no concede todas las capacidades y una capacidad no crea consentimiento. Ambos se comprueban para cada operación; revocar surte efecto sin volver a desplegar.
Configurar#
- AI Firewall -> Agent Config -> Access & Identity: A2A Auth Mode, métodos A2A permitidos y Owner-first authorization.
- Agent Trust -> A2A Settings: modo de incorporación, ciclo de tareas y TTL.
- Agent Trust -> Agents: inventario. Agent Trust -> Approvals: incorporaciones y tareas pendientes.
Se requieren agentes A2A autenticados y autorización que considere al owner.
| Ajuste | Predeterminado | Significado |
|---|---|---|
| a2a_auth_mode | off | on exige autenticación en /a2a/v1/*. La aplicación indica que Chain of Command está deshabilitado con off. |
| identity_policy_owner_enforced | false | true activa autorización owner-first; requiere autenticación A2A. |
| owner_enforcement_grace_days | 7 | Gracia para agente sin owner; rango 0-90 días. |
| max_delegation_depth | 3 | Profundidad máxima, rango 1-10; cada delegación puede limitarla más. |
| swarm_consent_valid_days | 0 | Vigencia de consentimiento; 0 significa que no caduca hasta revocarlo. |
A2A Auth Mode es distinto de Authentication Mode del tráfico /v1/*. Elija JWT, OIDC, API keys, certificado cliente mTLS o Kerberos cuando estén disponibles.
Con Admin approval, agentes nuevos quedan en Agent Trust -> Approvals. Auto-publish publica automáticamente; Admin-only rechaza autorregistro. Solo agentes publicados pueden ser miembros del swarm.
Crear un swarm#
- Registre cada agente con identidad y prueba únicas.
- Publique agentes si la política requiere aprobación.
- Asigne owners y credenciales.
- Cree un swarm con miembros y skills aprobadas.
- Registre consentimiento para miembros de otro owner/grupo.
- Conceda al hub solo las capacidades necesarias.
- Envíe órdenes y supervise los resultados.
Miembros de otro owner quedan pendientes hasta que este registre consentimiento. Agentes sin owner conocido también requieren consentimiento.
Controlar permisos#
Las capacidades del swarm son explícitas y limitadas al grupo: ver estado, leer auditoría autorizada, restablecer riesgo, solicitar suspensión/reactivación o pedir revocación de certificado mediante el proceso administrativo.
Las acciones sensibles pueden requerir aprobación del owner. La revocación de certificados permanece bajo control del administrador o CA; una delegación no permite al hub ejecutarla directamente. Políticas de ciclo de vida son opcionales y auditables.
Delegar skills#
Una skill personalizada describe una acción que la plataforma autoriza, valida, audita y envía al webhook de un agente registrado. El agente receptor ejecuta la acción e informa el resultado; la plataforma no ejecuta código arbitrario.
Defina skills permitidas, profundidad máxima, expiración opcional y validación de payload. Mantenga cada skill acotada y predecible, no como canal de comandos genérico.
Verificar comandos#
Las órdenes pueden incluir voucher firmado de corta duración con ID de orden y etapa, hub emisor, subagente destinatario, skill, hash de payload, versión de política y tiempos de emisión/expiración.
El agente receptor valida el voucher contra trust anchor fijado antes de actuar. Debe fallar de forma segura si el token está malformado, usa algoritmo no admitido, proviene de clave desconocida, expiró, tiene destinatario incorrecto, no coincide con payload o usa política obsoleta.
| Modo | Comportamiento |
|---|---|
| Offline | Valida localmente y ejecuta sin callback. |
| Callback optional | Valida localmente y confirma con plataforma si está disponible. |
| Callback required | No ejecuta hasta confirmar que la autorización sigue vigente. |
Fije la huella del trust anchor por canal independiente al instalar el agente. Mantenga la clave local y rótela mediante un proceso explícito.
Resultados y reintentos#
Una orden se divide en una etapa por miembro. Entrega no significa éxito: el receptor ejecuta e informa. Los informes se firman; firma ausente o inválida queda como no verificado.
Use idempotency key. Reintentar dentro de la ventana devuelve la orden original, no la distribuye de nuevo. Revocar una orden detiene etapas no iniciadas y no altera trabajo completado.
Solución de problemas#
| Síntoma | Comprobación |
|---|---|
| Un miembro no recibe órdenes | Consentimiento activo del owner y skill incluida en la concesión swarm. |
| El hub no ve un miembro | Capacidad correspondiente y consentimiento; la visibilidad depende del llamador. |
| Orden caducada/obsoleta | Solicite otra; venció voucher o cambió la política. |
| Resultado no verificado | Clave pública registrada e informe firmado con clave privada correspondiente. |
| Reintento sin nuevo envío | Se reutilizó la idempotency key; comportamiento esperado. |
SDKs#
Los SDK públicos incluyen implementaciones independientes Python y TypeScript:
Ambos usan licencia MIT y admiten verificación de vouchers, informes firmados y administración de swarms.