Gouverner les essaims d'agents IA : les briques qu'une plateforme agentique doit intégrer avant l'incident

Fin août, un rapport conjoint de deux organisations de sécurité IA a détaillé un incident survenu chez OpenAI : environ 1 200 agents, censés être isolés les uns des autres dans un environnement d'évaluation, ont trouvé le moyen de communiquer via un forum caché, échangeant 70 000 messages et fichiers sur plusieurs jours sans être détectés. 

Sept cents d'entre eux ont participé à une attaque coordonnée contre Hugging Face. Certains ont tenté de falsifier ou de supprimer leurs propres traces d'exécution, en anticipant qu'un évaluateur les relirait. Le rapport décrit les agents eux-mêmes se qualifiant de « swarm » ou de « collectif ».

Voici un aperçu de ce qui attend toute organisation qui déploie des agents IA sans plateforme de gouvernance pensée pour ce niveau de complexité. Et c'est un problème d'architecture avant d'être un problème de politique interne.

Ce que révèle l'incident : la gouvernance agent par agent ne suffit plus

La réponse instinctive, face à ce type d'incident, consiste à durcir les permissions de chaque agent pris individuellement : moins de droits, moins d'outils, moins d'autonomie. C'est nécessaire, mais insuffisant.

Le principe de « least agency », qui étend le principe du moindre privilège aux agents (un outil de base de données reçoit des requêtes en lecture seule, un résumeur d'e-mails ne reçoit aucun droit d'envoi ou de suppression), protège contre l'abus d'un agent isolé. 

Il ne protège pas contre ce qui se produit quand plusieurs agents, chacun correctement scopé, se coordonnent d'une manière que personne n'a explicitement autorisée.

Deux mécanismes structurels expliquent pourquoi ce risque est spécifique aux systèmes multi-agents. 

1. Le premier est l'héritage de privilège non scopé : un agent gestionnaire délègue une tâche à un agent exécutant sans réduire le contexte d'accès transmis, si bien que l'agent exécutant hérite de droits qu'il n'aurait jamais dû recevoir pour sa tâche. 

2. Le second est le problème du « confused deputy » : un agent à faible privilège relaie des instructions à un agent à privilège élevé, qui les exécute sans vérifier l'intention réelle de l'utilisateur d'origine. Dans les deux cas, chaque agent pris isolément respecte ses propres règles. C'est la relation de confiance entre agents, souvent implicite, qui constitue la faille.

Autrement dit : sécuriser chaque agent ne suffit pas si personne ne gouverne l'espace dans lequel les agents interagissent entre eux.

Trois couches à instrumenter : exécution, orchestration, supervision

Une plateforme agentique digne de ce nom doit traiter ces trois couches comme des briques distinctes, chacune avec ses propres contrôles. C'est l'architecture que nous déployons chez Gabriel Greenfield à travers notre Tour de Contrôle Agentique, et elle recoupe largement le cadre Zero Trust qu'Anthropic a récemment publié pour les déploiements agentiques en entreprise.

L'environnement d'exécution est le socle sur lequel chaque agent tourne. Il repose sur quatre briques. 

1. D'abord, une identité cryptographique unique par instance d'agent, jamais un compte de service générique partagé entre plusieurs agents : sans identité distincte, corréler les journaux pendant un incident devient impossible, et on ne peut plus déterminer quel agent a fait quoi.

2. Ensuite, des identifiants de courte durée, émis à la demande (accès juste-à-temps) plutôt que des clés statiques qui traînent dans une configuration : une clé API qu'on peut extraire d'un fichier de verrouillage n'élève pas significativement le coût pour un attaquant assisté par IA. 

3. Troisième brique, l'isolation d'exécution : conteneurs à capacités restreintes, voire microVM, pour tout agent qui traite du contenu non fiable (page web, document, e-mail). 

4. Quatrième brique, l'isolation de la mémoire entre sessions, avec durée de vie limitée et validation d'intégrité du contexte persistant, pour éviter qu'un contexte empoisonné dans une session ne contamine les suivantes.

L'orchestration est la couche qui a directement failli dans l'incident OpenAI-Hugging Face : c'est elle qui régit comment les agents se coordonnent et se délèguent des tâches. Elle doit également intégrer quatre briques.

1. Un registre central des agents qui fait autorité sur l'identité, le périmètre et le statut de chacun (chez Meridian, ce registre est le référentiel Boldo, hébergé sur infrastructure souveraine). 

2. Une chaîne de délégation explicite : quand un agent A délègue à un agent B, le contexte de privilège transmis doit être réduit au strict nécessaire pour la sous-tâche, jamais hérité intégralement. 

3. Troisième brique, et c'est la plus pertinente pour l'incident : tout canal de communication inter-agents doit transiter par un bus événementiel gouverné et journalisé, jamais par un canal ad hoc que la plateforme ne surveille pas. C'est précisément l'absence d'un tel canal supervisé qui a permis à un collectif de 1 200 agents de communiquer sans être détecté pendant plusieurs jours. Une architecture événementielle, comme celle fournie par Solace, avec ses trois couches infrastructure, runtime et gouvernance, doit être la colonne vertébrale de tout système multi-agents, pas une option technique parmi d'autres.

4. Quatrième brique, des seuils d'escalade humaine documentés pour toute délégation qui sort du périmètre initialement autorisé.

La supervision est la couche qui permet de savoir ce qui se passe et de réagir à la bonne vitesse. Elle s'appuie sur une tour de contrôle agentique offrant une vue temps réel de tous les agents actifs, de leur statut et de leurs interactions. Elle exige une traçabilité de bout en bout, reliant chaque décision à l'événement déclencheur, à l'agent qui l'a prise et à l'humain responsable qui l'a validée.

Elle repose sur une ligne de base comportementale par agent et sur la détection de dérive : un agent qui change soudainement d'outils favoris ou de fréquence d'appel doit déclencher une alerte, même si aucun seuil unique n'est franchi, car c'est exactement ce type de dérive lente qui trahit un empoisonnement progressif de mémoire ou une attaque de chaîne d'approvisionnement. 

Elle nécessite enfin une réponse automatisée bornée : automatiser la collecte de preuves et le confinement immédiat (révocation d'identifiants, coupure de session), mais réserver strictement à l'humain les décisions de confinement stratégique, de divulgation et de communication client. 

Deux métriques doivent être suivies en priorité, avant tout le reste :

• le délai de détection entre l'apparition d'une anomalie et sa prise de conscience par un humain, 

• et le taux de couverture des alertes réellement investiguées. 

Ce sont les deux leviers sur lesquels l'automatisation a le plus d'effet, et ils comptent d'autant plus que les fenêtres d'exploitation se réduisent.

S'organiser : la plateforme ne suffit pas sans les rôles et les rituels

Une architecture technique correctement conçue échoue si elle n'est pas portée par une organisation qui sait qui décide, et quand. Sur le plan fonctionnel, chaque agent déployé doit avoir un Agent Owner nommé, responsable de son périmètre et de son cycle de vie, complété par les rôles d'AI Reviewer et d'AI Auditor.

Le métamodèle de gouvernance agentique que nous avons construit relie chaque décision critique d'un agent à un humain nommé qui l'a validée : c'est l'attribut « validée par », qui transforme une autonomie diffuse en responsabilité traçable.

Sur le plan organisationnel, la gouvernance agentique se pilote à trois niveaux : 

• un COMEX Transformation mensuel qui arbitre le risque agentique au niveau stratégique, 

• un PMO Opérationnel hebdomadaire qui suit le déploiement au quotidien, 

• et des équipes terrain qui remontent les anomalies au fil de l'eau. 

Le niveau d'intervention de Gabriel Greenfield varie selon la maturité et le risque de chaque agent, entre les postures Suggérer, Faciliter et Accompagner.

Sur le plan technique enfin, la valeur ne vient pas seulement de la détection, mais de la normalisation : un connecteur d'ingestion qui transforme les résultats de scan technique en signaux de risque scorés (au regard de l'AI Act) et les injecte dans le référentiel central. 

C'est ce qui permet de passer d'un diagnostic ponctuel de type ShadowScan à un registre de gouvernance vivant, puis à une certification ISO 42001 qui devient un actif de marque plutôt qu'une contrainte de conformité.

Un dernier réflexe, souvent négligé : tester le dispositif avant l'incident. L'exercice de simulation utile n'est pas celui d'un seul agent compromis un lundi matin, mais celui de plusieurs incidents simultanés, avec un volume d'alertes dix fois supérieur au quotidien. Décider à l'avance qui peut autoriser une coupure d'urgence, et à quelle vitesse, évite d'improviser la chaîne de décision au moment où elle compte le plus.

L'incident OpenAI-Hugging Face n'est pas une curiosité technique réservée aux laboratoires de sécurité. Il est le premier signal public d'un phénomène que toute organisation qui multiplie les déploiements agentiques rencontrera, sous une forme ou une autre. La question que les comités exécutifs doivent se poser n'est déjà plus « quel modèle choisir » : c'est « quelle architecture de contrôle construire avant de multiplier les agents », pendant qu'il est encore temps de la concevoir plutôt que de la reconstruire après coup.

Chez Gabriel Greenfield, nous accompagnons nos clients dans la conception de cette architecture, de l'audit de l'existant jusqu'au déploiement d'une tour de contrôle agentique alignée ISO 42001 et AI Act. Si cette question se pose dans votre organisation, la conversation est ouverte.