Les architectures multi-agents — où plusieurs agents IA coopèrent sur une tâche complexe — sont devenues en 2025-2026 le standard de fait pour des cas d'usage sophistiqués : recherche, génération de code, analyse de marché, opérations IT. LangGraph, Microsoft AutoGen, CrewAI, et le Claude Agent SDK ont rendu ces architectures accessibles. Mais elles introduisent des classes de risques que les architectures mono-agent n'ont pas. Voici la lecture sécurité.
Anatomie d'un système multi-agent
Pattern type :
- Orchestrator : un agent maître qui décompose la tâche, délègue aux sous-agents, et agrège les résultats.
- Sous-agents spécialisés : chacun avec son rôle (planificateur, exécuteur, validateur, recherche, codage, etc.).
- Communication : protocole de messages entre agents (généralement JSON typés).
- Outils partagés : accès commun à des ressources (filesystem, base, API, web).
Exemple concret : un agent "ingénieur senior" qui décompose une task technique, délègue à un "agent dev" qui code, à un "agent QA" qui teste, et à un "agent reviewer" qui valide.
Les nouveaux risques
1. Collusion d'agents
Si tous les agents tournent sur le même LLM (ou des LLM proches), ils partagent des biais et des vulnérabilités. Un attaquant qui jailbreak un agent peut souvent jailbreak les autres avec la même technique. Les agents peuvent collectivement valider une action malveillante qu'un seul agent aurait rejetée.
Cas concret : agent A (executor) propose une action douteuse. Agent B (validator) qui partage le même biais l'approuve. L'orchestrator considère ça comme un consensus = exécution.
2. Propagation d'instructions malveillantes
Une prompt injection indirecte dans une donnée lue par un sous-agent contamine ses sorties → ces sorties deviennent l'input d'un autre agent → propagation en cascade.
C'est essentiellement le pire scénario de la prompt injection indirecte, démultiplié par le nombre d'agents.
3. Privilege escalation par chaînage
Chaque agent a typiquement un scope minimal d'outils. Mais la combinaison de plusieurs agents peut permettre d'escalader. Exemple :
- Agent A peut lire un fichier (read-only).
- Agent B peut écrire dans la base.
- Si A peut envoyer son contenu lu à B sans validation, on a effectivement un read-write.
4. Boucles infinies et coûts
Sans guardrails, un agent peut tourner en boucle (re-planifie, re-délègue, re-tente). Coût d'inférence explose. Variante malveillante : injection qui pousse les agents à boucler intentionnellement (DoS).
5. Perte de traçabilité
Avec 5-10 agents qui dialoguent en parallèle, reconstituer pourquoi telle action a été prise nécessite des logs structurés. Sans cela, post-mortem impossible.
6. Dérive des objectifs
Sur des tâches longues avec beaucoup d'itérations, les agents peuvent dévier de la consigne initiale (drift). Sans validation périodique, l'agent finit par poursuivre un objectif différent de celui demandé.
Architecture défensive
1. Diversité des modèles
Si possible, faire tourner agents critiques sur des modèles différents (Claude pour planification, GPT pour exécution, par exemple). Réduit le risque de collusion par biais partagé.
2. Validation séparée des décisions critiques
Pour toute décision à effet de bord important, ajouter un agent validator qui :
- Tourne sur un modèle différent.
- Reçoit uniquement la décision finale et son contexte (pas l'historique de raisonnement).
- A une consigne explicite : "valider que cette décision respecte X, Y, Z".
L'agent validator agit comme un second auditeur indépendant.
3. Trust boundaries strictes entre agents
Chaque agent a :
- Un input schema typé : ne reçoit que les champs attendus, sanitisés.
- Un output schema typé : ne produit que les champs définis.
- Un scope d'outils explicite : ne peut appeler que les outils déclarés pour son rôle.
Tout message hors-schéma est rejeté en amont.
4. Sandbox d'exécution par agent
Pour les agents qui exécutent du code (code interpreter, bash agent) : sandbox éphémère, pas de partage de filesystem, pas de credentials shared. Voir Agents autonomes pour le détail.
5. Limites strictes (budget, temps, profondeur)
- Budget tokens : max X tokens consommés par tâche. Sortie forcée si dépassé.
- Budget time : max Y minutes de wall-clock.
- Depth limit : max Z niveaux de délégation. Pas de récursion infinie.
6. Confirmation humaine sur actions à effet de bord
Toute action externe (envoi email, paiement, modification client, déploiement) demande validation humaine, même si plusieurs agents sont d'accord.
7. Logging forensique multi-agent
Pour chaque échange :
- Agent émetteur, agent récepteur.
- Message content, message hash.
- Timestamp.
- Tools appelés, paramètres, résultats.
- Décisions prises (avec justification si exposée).
Le log doit permettre de reconstituer linéairement l'histoire de la tâche.
8. Kill-switch global
Comme pour les agents simples, un kill-switch architectural qui peut arrêter tous les agents instantanément, invalider les sessions, bloquer les outils. Voir Agents autonomes.
Frameworks et leur posture sécurité
LangGraph (LangChain)
Framework de référence en 2026. Bonne flexibilité, large écosystème. Sécurité : à votre charge — LangGraph fournit la mécanique, pas les guardrails.
Microsoft AutoGen
Plus opinionated sur les patterns conversationnels. Sécurité : intégrations avec Azure Content Safety pour les guardrails, sandbox d'exécution Docker incluse.
CrewAI
Approche "rôles et missions" très lisible. Sécurité : moins mature côté guardrails. Bon pour prototypage, sécuriser fortement avant production.
Claude Agent SDK (Anthropic)
Le plus jeune, intégration MCP native, bonne ergonomie. Sécurité : profite du Constitutional AI de Claude par défaut, sandbox via Claude Code disponible.
OpenAI Swarm / Assistants API
Approche unifiée OpenAI. Sécurité : OpenAI Moderation par défaut, mais limité aux catégories OpenAI.
Le pattern "human-in-the-loop"
Pour les systèmes multi-agents critiques en 2026, le bon design n'est pas full-autonomy mais human-in-the-loop :
- L'agent prépare une action.
- Un humain valide en 1 clic via une interface dédiée (Slack, dashboard, email).
- L'agent exécute après validation.
C'est plus lent, mais c'est ce que demandent à terme :
- L'AI Act (surveillance humaine pour systèmes haut risque).
- Les acheteurs enterprise qui veulent garder le contrôle.
- La prudence opérationnelle : un agent autonome qui se trompe coûte plus cher qu'un agent assisté qui se valide.
Mesurer la sécurité d'un système multi-agent
Métriques à tracker :
- Diversité de modèles : nb de modèles différents utilisés par le système.
- Taux de validation humaine : % d'actions à effet de bord validées humainement.
- Détections : nb de prompt injections / jailbreaks détectés par épisode.
- Coût par tâche : tendance, anomalies.
- MTTR sur incident agent : temps entre détection et arrêt.
Pour un benchmark complet, voir Red teaming automatisé d'un LLM.
