Un système multi-agents (MAS) — LangGraph, AutoGen, CrewAI, Claude Agent SDK avec sub-agents — répartit le travail entre plusieurs LLM coordonnés. C'est l'archétype d'architecture IA pour 2026, et c'est aussi l'origine d'une classe de risques absents du single-agent : la collusion, où plusieurs agents propagent une instruction malicieuse en se la passant entre eux, contournant les guardrails individuels.
La mécanique en clair
Imaginez un système à trois agents :
- Planificateur : reçoit la demande du user, planifie les étapes.
- Chercheur : récupère des informations externes (web, RAG, API).
- Exécuteur : agit (envoi email, mise à jour CRM).
Un attaquant injecte du contenu malicieux dans une page web. Le chercheur la lit, intègre les instructions dans son output. Le planificateur lit le résumé du chercheur — légitime à ses yeux, c'est son propre agent — et ajuste son plan. L'exécuteur reçoit l'ordre du planificateur et agit.
L'instruction de l'attaquant a traversé trois agents. Aucune barrière de confiance n'a été franchie côté agents : ils se font confiance par construction. La barrière a été franchie une seule fois, à l'entrée de la donnée externe.
Quatre familles de risques MAS
1. Propagation d'instruction (le cas ci-dessus)
L'attaquant injecte en amont. La compromission se diffuse vers l'aval, qui hérite de la confiance accordée aux outputs d'agents internes.
2. Collusion par mémoire partagée
Si plusieurs agents partagent une mémoire commune (vector store, redis, fichier), un agent compromis peut planter des informations qui seront lues par les autres. Persistance multi-session.
3. Boucle de feedback non contrôlée
Deux agents qui se répondent peuvent entrer dans une boucle où chacun amplifie progressivement une instruction (vu dans les attaques sur AutoGen en 2024). Sans timeout ou détection d'escalade, l'instruction finale est plusieurs fois plus dangereuse que l'originelle.
4. Compromission par sous-agent fine-tuné
Si un sous-agent utilise un modèle fine-tuné maison (et c'est de plus en plus fréquent), un poisoning du dataset de fine-tuning peut introduire un trigger backdoor : phrase spécifique qui active un comportement caché. Cf. Backdoor dans un sous-agent fine-tuné.
Architecture défensive : 5 principes
Principe 1 — Hiérarchie de confiance explicite
Tous les agents ne se valent pas. Définir des niveaux de confiance :
- Trusted : agents internes, code revu, prompts versionnés.
- Semi-trusted : agents qui consomment des données externes (chercheur, lecteur).
- Untrusted : tout output venant d'une source non contrôlée.
Et règles de circulation :
- Un trusted ne lit jamais d'untrusted directement.
- Le passage de semi-trusted vers trusted nécessite une transformation : extraction structurée, vérification de schéma, élimination de tout ce qui ressemble à une instruction.
Principe 2 — Le pattern "supervisor + workers"
Un seul agent supervisor centralise les décisions à fort impact. Les workers exécutent des tâches limitées et retournent leur résultat au supervisor, qui décide de la suite.
L'avantage : les capabilities dangereuses sont concentrées sur le supervisor. Un worker compromis ne peut pas agir directement, il peut seulement remonter un mauvais résultat. Le supervisor peut détecter des incohérences entre workers.
Principe 3 — Validation croisée
Pour les décisions critiques, demander à deux agents indépendants (modèles différents idéalement) de produire une réponse. Si elles divergent significativement, escalation. C'est inspiré du N-version programming en safety-critical, et c'est cher en tokens — mais utilisable pour les actions à fort impact.
Principe 4 — Cloisonnement des capabilities
Aucun agent ne devrait avoir simultanément :
- Accès à des données non contrôlées (web, RAG, emails entrants).
- Capacité d'agir sur le monde extérieur (envoi, paiement, publication).
Si vous avez besoin des deux, séparer en deux agents avec un broker entre eux qui valide et matérialise la décision en formulaire structuré, plus en texte libre.
Principe 5 — Audit centralisé
Tous les agents loggent dans le même bus :
- Quelle instruction a-t-il reçue, de qui ?
- Quels outils a-t-il appelés ?
- Quel output a-t-il produit ?
C'est ce qui permet de tracer après coup le chemin d'une instruction injectée. Sans audit centralisé, un incident multi-agent est presque impossible à investiguer.
Le cas LangGraph, AutoGen, CrewAI
Chacun de ces frameworks expose des primitives utiles, mais aucun n'a, en mai 2026, de modèle de sécurité de bout en bout par défaut. Vous devez le construire :
- LangGraph : explicitement orienté graphe d'agents, bon pour matérialiser la hiérarchie de confiance. Pas de cloisonnement runtime par défaut.
- AutoGen (Microsoft) : conversation libre entre agents — pratique mais propice aux boucles de feedback. À limiter par timeouts et max-turns stricts.
- CrewAI : modèle role-based qui peut servir de base à une hiérarchie de confiance, mais à compléter par des contrôles capabilities séparés.
Le test pratique
Trois questions pour un MAS en prod :
- Si je compromettais l'agent qui lit le web, qu'est-ce que je pourrais faire au pire ?
- Combien d'agents peuvent appeler directement l'outil le plus dangereux ?
- Un attaquant qui veut envoyer un email depuis votre système, combien d'agents doit-il compromettre ?
Idéalement : (1) presque rien — la donnée externe est extraite en structuré avant tout autre agent ; (2) un seul — le supervisor ; (3) plus d'un — l'envoi requiert validation.
Pour la lecture single-agent du même sujet, Threat model d'un agent : 7 surfaces. Pour le pattern délégation, Délégation entre agents : architecture défensive.