Chain of Command pour agents gouvernés

Coordonner des swarms avec consentement, déléguer des skills approuvées et vérifier chaque commande avant exécution.

Chain of Command coordonne des agents sans donner à l’un un contrôle illimité sur un autre. Un owner crée un groupe gouverné, accorde les skills nécessaires et conserve consentement, autorisation et résultats.

Modèle#

Un hub agent dirige un swarm de sous-agents. Le swarm définit les skills que le hub peut envoyer. Le hub est un agent enregistré ordinaire qui prend ce rôle en dirigeant le swarm.

Deux contrôles protègent chaque membre : consentement de son owner, puis capacité accordée par l’owner du swarm. Le consentement ne donne pas toutes les capacités ; une capacité ne crée pas de consentement. Les deux sont vérifiés par opération, révocation immédiate.

Configuration#

AI Firewall -> Agent Config -> Access & Identity : A2A Auth Mode, méthodes permises et Owner-first authorization.
Agent Trust -> A2A Settings : inscription, cycle des tâches et TTL.
Agent Trust -> Agents : inventaire ; Agent Trust -> Approvals : demandes en attente.

Agents A2A authentifiés et contrôle tenant compte de l’owner sont nécessaires.

Paramètre	Défaut	Signification
a2a_auth_mode	off	on exige auth sur /a2a/v1/* ; Chain of Command est désactivé avec off.
identity_policy_owner_enforced	false	true active Owner-first et requiert auth A2A.
owner_enforcement_grace_days	7	Délai pour agent sans owner : 0-90 jours.
max_delegation_depth	3	Profondeur max 1-10 ; une délégation peut être plus restrictive.
swarm_consent_valid_days	0	Validité ; 0 signifie pas d’expiration automatique.

A2A Auth Mode est distinct de Authentication Mode pour /v1/*. Méthodes possibles : JWT, OIDC, API keys, certificats mTLS ou Kerberos.

En Admin approval, les nouveaux agents apparaissent dans Agent Trust -> Approvals. Auto-publish publie à l’inscription ; Admin-only refuse l’auto-inscription. Seuls les agents publiés peuvent intégrer un swarm.

Créer un swarm#

Enregistrez chaque agent avec identité/preuve uniques.
Publiez selon la politique.
Attribuez owner et identifiant.
Créez le swarm avec membres et skills approuvées.
Enregistrez consentement des membres d’autres owners/groupes.
Accordez au hub les capacités minimales.
Envoyez les ordres et surveillez les résultats.

Un membre d’un autre owner reste en attente de son consentement ; owner inconnu exige aussi consentement.

Contrôler les permissions#

Capacités explicites et limitées au swarm : consulter l’état, lire audit autorisé, réinitialiser le risque, demander suspension/réactivation ou révocation via workflow admin.

Les actions sensibles peuvent nécessiter l’approbation du propriétaire. La révocation certificat reste contrôlée par admin/CA. Les politiques de cycle de vie sont facultatives et auditées.

Déléguer des skills#

Une skill décrit une action autorisée, validée, auditée et relayée au webhook d’un agent enregistré. L’agent exécute et rapporte ; la plateforme n’exécute pas de code arbitraire.

Définissez skills permises, profondeur, expiration facultative et validation payload. Gardez-les précises, pas un canal de commandes général.

Vérifier les commandes#

Un voucher signé et bref peut contenir ordre/étape, hub, sous-agent, skill, hash payload, version de politique et dates.

L’agent vérifie le voucher avec trust anchor fixé avant action. Refusez token malformé, algorithme non pris en charge, clé inconnue, expiration, mauvais destinataire, payload différent ou politique obsolète.

Mode	Comportement
Offline	Vérifie localement, sans callback.
Callback optional	Vérifie localement et confirme si plateforme accessible.
Callback required	Attend confirmation de validité avant exécution.

Fixez l’empreinte trust anchor par canal indépendant. Gardez la clé localement et utilisez une procédure de rotation explicite.

Résultats et reprises#

Une commande comporte une étape par membre. Livraison n’est pas succès : le récepteur exécute et rapporte. Rapports signés ; absence ou invalidité = non vérifié.

Utilisez idempotency key. Une reprise dans la fenêtre renvoie la commande originale, sans nouveau dispatch. La révocation arrête les étapes non commencées sans changer le travail terminé.

Dépannage#

Symptôme	Vérification
Membre sans commande	Consentement actif et skill incluse dans la concession du swarm.
Hub ne voit pas le membre	Capacité applicable et consentement ; visibilité limitée à l’appelant.
Commande expirée/obsolète	Demander une nouvelle commande.
Résultat non vérifié	Clé publique enregistrée et rapport signé avec clé correspondante.
Reprise sans nouveau dispatch	Même idempotency key, comportement attendu.