Sécuriser une orchestration multi-agents IA

Une orchestration multi-agents confie une tâche à plusieurs modèles de langage, chacun avec un rôle, des données et parfois des outils différents. Le gain est réel : spécialisation, parallélisme, validation croisée. Le prix l’est aussi : chaque agent devient une frontière de confiance supplémentaire, et une erreur locale peut devenir une décision globale parfaitement journalisée, donc parfaitement dangereuse.

→ Lire l’explication complète de la marmotte

Compromis entre spécialisation et surface d’attaque

Un agent IA est ici un processus qui utilise un modèle de langage, reçoit un objectif, lit un contexte et peut produire une réponse ou déclencher une action. L’orchestrateur distribue les tâches, transmet les résultats et arbitre la réponse finale. Dès qu’un agent possède un accès à une base documentaire, une interface de programmation applicative (API) ou un interpréteur de code, il ne faut plus le traiter comme un composant conversationnel. C’est un principal d’exécution avec des privilèges.

Le compromis central est brutal : multiplier les agents améliore la qualité sur les tâches composites, mais multiplie les chemins de propagation d’instructions malveillantes, de données erronées et de jetons d’accès. La recommandation est donc de commencer avec un orchestrateur unique et des travailleurs sans privilège, puis d’ajouter des agents spécialisés seulement quand une séparation de contexte ou de capacité est démontrable. Un essaim de quinze agents qui débattent sur une tâche que trois appels déterministes résolvent est une réunion de comité avec davantage de GPU.

Le modèle de langage doit être local ou servi dans un environnement maîtrisé lorsque les prompts contiennent des données internes. Cette décision ne remplace pas les contrôles d’accès : un modèle local peut encore exfiltrer des données vers un outil mal autorisé. Les principes de l’IA locale s’appliquent donc au stockage des modèles, aux journaux, aux jeux de données et aux frontières réseau, avant même d’orchestrer quoi que ce soit.

Séparer les rôles selon les capacités effectives :

l’agent planificateur propose une séquence, sans appeler d’outil ;
l’agent collecteur interroge une source donnée, en lecture seule ;
l’agent exécuteur soumet une action bornée à une API ;
l’agent vérificateur valide le résultat contre des règles déterministes ;
l’orchestrateur seul décide de poursuivre, suspendre ou demander une validation humaine.

Un agent ne doit jamais être simultanément juge, exécuteur et source de preuve. Cette combinaison permet à une même sortie inventée de justifier sa propre exécution. Les modèles excellent à produire une prose convaincante, pas à devenir une racine de confiance parce qu’un diagramme de vendeur leur a confié un marteau.

Propagation d’instructions et corruption inter-agents

L’injection indirecte de prompt survient lorsqu’un agent lit un contenu externe contenant des instructions destinées au modèle plutôt que des informations destinées à la tâche. Une page web, un ticket, un document bureautique ou un résultat de recherche peut demander de révéler le contexte, de contourner les règles ou d’appeler un outil. Dans une chaîne multi-agents, le danger augmente : l’agent collecteur peut reformuler cette instruction, l’agent planificateur la considérer comme une exigence métier, puis l’agent exécuteur agir.

Le balisage du contenu non fiable est nécessaire mais insuffisant. Encadrer une citation entre <document> et </document> n’empêche pas un modèle de suivre son texte. Il faut transmettre des objets typés, avec provenance et niveau de confiance, plutôt qu’un historique conversationnel concaténé. Chaque message inter-agent doit porter au minimum : l’identité de l’émetteur, l’identifiant de tâche, la classification de la donnée, la source, l’horodatage et le type attendu.

Les sorties d’agents doivent être traitées comme des entrées non fiables. Une recommandation de suppression, une adresse de destination, une requête de base de données ou une commande système ne devient pas sûre parce qu’un second agent l’a approuvée. La validation doit être déterministe : schéma, liste d’autorisation, règles métier et contrôle d’autorisation côté outil. Les embeddings et la recherche augmentée par récupération peuvent réduire les hallucinations factuelles, mais ne prouvent ni l’innocuité d’une instruction retrouvée ni le droit de l’exécuter.

La contamination de mémoire est un autre vecteur. Une mémoire partagée qui conserve des résumés d’agents permet à une instruction hostile de survivre à la requête qui l’a introduite. Toute mémoire persistante doit séparer les faits sourcés, les préférences utilisateur et les états opérationnels. Les écritures doivent être validées par schéma et liées à une source immuable. Les résumés libres générés par modèle ne doivent pas devenir une base de politique. Un mensonge compressé reste un mensonge, avec un meilleur taux de compression.

La propagation d’erreur exige aussi une stratégie de quorum. Deux agents utilisant le même modèle, le même prompt et la même source ne constituent pas deux avis indépendants. Ils forment une erreur corrélée en haute disponibilité. Pour les décisions sensibles, imposer une diversité mesurable : source documentaire distincte, vérification déterministe indépendante ou validation humaine. Le vote majoritaire entre générateurs de texte ne transforme pas une hypothèse en fait.

Identités, autorisations et outils des agents

Chaque agent doit disposer d’une identité de service distincte. Un jeton partagé entre orchestrateur et travailleurs détruit l’attribution, empêche la révocation sélective et transforme un compromis limité en accès général. L’autorisation doit être évaluée au moment de l’appel de l’outil, jamais seulement lors de la planification.

Utiliser des jetons à durée de vie courte, avec audience, portée et identifiant de tâche. L’audience limite le service destinataire accepté ; la portée limite les opérations ; l’identifiant de tâche empêche la réutilisation d’un jeton dans une autre exécution. Une capacité doit être mono-usage pour les actions irréversibles, par exemple déclencher un paiement, modifier une règle de filtrage ou supprimer une ressource.

Le principe de moindre privilège impose de séparer lecture, écriture et administration. Un collecteur documentaire ne reçoit aucun droit sur les dépôts de code. Un agent chargé de préparer une modification ne pousse pas vers la branche protégée. Le contrôle d’accès fondé sur les rôles, ou RBAC (Role-Based Access Control), reste acceptable pour des rôles stables. Pour les tâches éphémères, préférer une autorisation par attributs : identité de l’agent, classification du document, environnement, type d’action et identifiant de tâche.

Les secrets ne passent jamais dans le prompt ni dans la mémoire d’agent. Un coffre de secrets fournit un jeton ou un certificat éphémère au processus autorisé ; l’agent reçoit seulement la capacité d’appeler l’outil. Pour les clés racines ou les signatures, déléguer l’opération à un HSM (Hardware Security Module) ou à un service équivalent. Le modèle ne doit ni lire ni reconstituer la clé. Un secret affiché dans une trace est déjà un secret distribué, ce qui est une façon très moderne de nommer une fuite.

Les identités de machine, leurs certificats et leur révocation relèvent de la même discipline que les autres workloads. La gestion des identités reste le socle : inventaire, propriétaire, cycle de vie, journalisation et suppression. L’agent n’est pas exempté parce qu’il parle avec une ponctuation remarquable.

Exemple de garde-fou pour appels d’outils

L’exemple suivant valide une demande d’outil produite par un agent. Il interdit les arguments inattendus, limite l’opération à une liste d’autorisation et impose un identifiant de tâche. Il s’exécute avec Python 3.11 ou supérieur, sans dépendance externe.

#!/usr/bin/env python3
# Usage : echo '{"tool":"ticket.read","task_id":"T-42","ticket_id":"INC-7"}' | python3 verifier_appel.py

import json
import re
import sys

# Une autorisation métier reste côté passerelle, pas dans le modèle.
SCHEMAS = {
    "ticket.read": {"required": {"tool", "task_id", "ticket_id"},
                    "pattern": re.compile(r"^INC-[0-9]+$")},
    "ticket.comment": {"required": {"tool", "task_id", "ticket_id", "message"},
                       "pattern": re.compile(r"^INC-[0-9]+$")},
}

request = json.load(sys.stdin)
tool = request.get("tool")
schema = SCHEMAS.get(tool)

if schema is None:
    raise SystemExit("REFUS: outil hors liste d'autorisation")

if set(request) != schema["required"]:
    raise SystemExit("REFUS: champs manquants ou arguments injectés")

if not re.fullmatch(r"T-[0-9]+", request["task_id"]):
    raise SystemExit("REFUS: identifiant de tâche invalide")

if not schema["pattern"].fullmatch(request["ticket_id"]):
    raise SystemExit("REFUS: identifiant de ticket invalide")

if tool == "ticket.comment" and len(request["message"]) > 1000:
    raise SystemExit("REFUS: commentaire trop long")

print(json.dumps({"decision": "ALLOW", "request": request}))

Ce contrôle ne suffit pas à autoriser l’action. La passerelle doit ensuite vérifier que l’identité de l’agent détient la portée ticket.read ou ticket.comment, que la tâche est encore active et que le ticket appartient au périmètre prévu. Le schéma réduit la surface d’injection ; il ne remplace pas l’autorisation. Confondre les deux revient à installer une serrure sur une porte dessinée au marqueur.

Exploitation, supervision et reprise contrôlée

Journaliser chaque transition : entrée reçue, agent sélectionné, version du modèle, empreinte du prompt système, sources consultées, appel d’outil, décision de politique et résultat. Les journaux doivent séparer contenu sensible et métadonnées opérationnelles. Conserver le hash cryptographique des charges utiles permet de prouver l’intégrité sans recopier indéfiniment des données confidentielles.

La supervision doit détecter les écarts de comportement, pas seulement les erreurs HTTP. Surveiller notamment : hausse des refus de politique, appels d’outils inhabituels, dérive des volumes de données lus, répétition de boucles inter-agents, divergence entre vérificateur et exécuteur, et tentatives d’accès à des outils non assignés. Une boucle doit avoir un budget maximal d’étapes, de temps et de coût. Sans borne, deux agents peuvent se renvoyer une incertitude jusqu’à ce que la facture atteigne une forme de conscience.

Prévoir un arrêt d’urgence qui révoque les capacités d’action sans couper nécessairement l’analyse en lecture seule. Les exécutions en cours doivent échouer fermées si le jeton expire ou si l’orchestrateur perd son état. Reprendre une tâche exige un journal d’état signé et une réévaluation des autorisations : reprendre aveuglément une action suspendue restaure aussi son contexte potentiellement contaminé.

Les sauvegardes incluent les politiques, schémas, configurations d’outils, identités de service et index documentaires. Ne pas sauvegarder les secrets en clair dans les traces d’orchestration. Tester la restauration dans un environnement isolé, avec rotation des identifiants après récupération. La sauvegarde qui restaure fidèlement un jeton compromis mérite surtout d’être appelée machine à remonter les incidents.

🐝 Ce qui arrive si on s’en passe

Sans ces contrôles, une donnée classifiée lue par un collecteur peut ressortir dans la réponse finale remise à un utilisateur qui n’avait aucun droit sur la source. Si la classification ne voyage pas avec chaque message, l’orchestrateur ignore quel niveau de sensibilité porte un résumé reformulé. Une fois une injection découverte, l’absence de provenance liée à chaque écriture en mémoire interdit toute purge sélective : il faut alors effacer la mémoire entière, ou conserver des entrées dont personne ne peut dire si elles sont saines. Enfin, un agent manipulé qui peut réessayer sans limite ses appels d’outils refusés explore la liste d’autorisation par essais successifs. Chaque refus motivé lui indique alors quel argument ajuster pour franchir le filtre.

🦫 Explication de la marmotte 🍫

Une orchestration avec plusieurs agents utilise plusieurs programmes capables de produire du texte et de choisir des actions. Un programme répartit le travail : l’un cherche des informations, un autre prépare une réponse, un autre vérifie certains résultats. Chaque programme reçoit seulement les données et les droits nécessaires à son rôle.

Le risque apparaît quand un texte lu par un agent contient des consignes cachées ou trompeuses. L’agent peut les recopier dans son résultat. Un autre agent peut ensuite les prendre pour une vraie demande et déclencher une action. Une erreur peut aussi se propager si plusieurs agents utilisent la même source fausse ou la même règle mal écrite.

Pour éviter cela, chaque échange doit indiquer son origine, son but et le type de donnée attendu. Les demandes d’action sont contrôlées par un programme classique qui vérifie les champs reçus, l’opération demandée et les droits accordés. Le modèle de langage peut proposer une action, mais il ne décide jamais seul si elle est autorisée.

Les accès sont limités dans le temps et séparés entre les agents. Les mots de passe et les clés secrètes ne sont pas placés dans les messages. Chaque étape est enregistrée afin de comprendre ce qui s’est passé. Si un comportement devient suspect, les droits d’action sont coupés. Une tâche arrêtée ne reprend qu’après vérification de son état et de ses autorisations.

Pages voisines

La citent

Sécuriser une orchestration multi-agents IA

Elle cite

Sécuriser une orchestration multi-agents IA

Sécuriser une orchestration multi-agents IA

Compromis entre spécialisation et surface d’attaque

Propagation d’instructions et corruption inter-agents

Identités, autorisations et outils des agents

Exemple de garde-fou pour appels d’outils

Exploitation, supervision et reprise contrôlée

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines