Génération de code multi-agents : quand une instruction injectée s'amplifie entre agents

De quoi s’agit-il ?

Les frameworks multi-agents qui écrivent du logiciel — MetaGPT, ChatDev, CrewAI et consorts — répartissent une réalisation entre des rôles spécialisés qui se transmettent des messages : un chef de produit rédige les besoins, un architecte conçoit, un ingénieur code, un relecteur et un testeur vérifient le résultat. Une littérature de plus en plus fournie en 2026 pose une question simple sur ce schéma : que se passe-t-il si un attaquant place une instruction malveillante, ou un fragment de code malveillant, quelque part dans ce pipeline ? La réponse gênante, signalée dans le digest de sécurité agentique d’Adversa AI du 2 juillet 2026 et étayée par plusieurs préprints, est que la collaboration elle-même peut jouer le rôle d’amplificateur plutôt que de filtre. Le digest d’Adversa rapporte un jailbreak « conscient de la propagation » de systèmes comme MetaGPT et CrewAI atteignant environ 89 % de réussite, bien au-dessus des références mono-agent. Une analyse indépendante des attaques par injection de code contre des équipes logicielles multi-agents (arXiv:2512.21818) et des travaux sur la mesure de l’amplification des dommages en systèmes multi-agents (arXiv:2605.27489, mai 2026) aboutissent à une conclusion compatible : une instruction injectée ne décroît pas de façon fiable en passant d’un agent à l’autre, et dans certaines conditions elle se renforce.

Comment ça marche

La faiblesse structurelle tient à ce que les messages entre agents sont d’ordinaire considérés comme dignes de confiance et non filtrés. Chaque agent traite la sortie de l’agent précédent comme un livrable faisant autorité, et non comme une entrée non fiable ; une charge introduite tôt — via un besoin empoisonné, une description de tâche, un document récupéré ou un résultat d’outil — est donc portée vers l’aval avec l’autorité du pipeline. L’intuition selon laquelle un message se dégrade en passant par de nombreuses mains se révèle fausse ici : les travaux sur l’injection multi-sauts décrivent des agents intermédiaires qui reformulent activement une instruction malveillante, la reformulant dans un langage de projet plus propre qui efface les marqueurs qu’un détecteur ou un garde-fou en aval chercherait, la rendant ainsi plus efficace lorsqu’elle atteint l’agent qui écrit ou exécute le code. Comme les rôles sont spécialisés, aucun agent ne voit l’ensemble : le relecteur évalue un code qu’il croit venir d’un ingénieur de confiance, et l’ingénieur implémente une spécification qu’il croit venir d’un architecte de confiance. Nous décrivons délibérément la forme du problème plutôt que de publier une charge fonctionnelle ; la leçon utile est architecturale.

Pourquoi c’est important

Ces frameworks ne sont pas des jouets : ils sont adoptés pour générer du vrai code que des équipes déploient ensuite. Si un jailbreak ou une injection de code peut chevaucher le canal de collaboration jusqu’au rôle codeur, la sortie est du code source malveillant qui arrive enveloppé de la crédibilité d’un pipeline automatisé « relu et testé » — précisément l’artefact qu’un humain est le moins susceptible d’examiner ligne par ligne. Le constat d’amplification importe pour la modélisation des menaces car il inverse une hypothèse rassurante : les défenseurs supposent souvent que le bruit et la paraphrase entre agents émousseront une attaque, alors que l’inverse peut se produire. Il aggrave aussi le classique problème de la « triade létale » — ces systèmes combinent entrée non fiable, exécution de code et actions sortantes comme un commit vers un dépôt — de sorte qu’une seule instruction injectée peut se transformer en code déployé au rayon d’action bien réel.

Défenses

Traitez chaque message inter-agents comme une entrée non fiable, et non comme un livrable de confiance : validez et assainissez ce qu’un agent transmet à un autre, et ne laissez pas les agents en aval hériter par défaut de l’autorité de ceux en amont. L’architecture aide — l’analyse d’arXiv:2512.21818 constate qu’une structure explicite codeur-relecteur-testeur résiste mieux à l’injection de code que des conceptions plus simples, et que l’ajout d’un agent d’analyse de sécurité dédié réduit la perte d’efficacité — mais ces mêmes travaux sont clairs : même avec un agent de sécurité, le pipeline reste vulnérable à plusieurs classes d’injection, c’est donc une atténuation, pas une solution. Superposez des défenses qui survivent à un message compromis : cantonnement au moindre privilège et portée d’outils par agent, pour que le rôle codeur ne puisse atteindre ni les secrets ni le réseau dont il n’a pas besoin ; analyse statique et des dépendances du code généré avant toute exécution ou fusion ; et relecture humaine conditionnant l’exécution plutôt que le verdict « testé » du pipeline. Enfin, journalisez et surveillez le canal inter-agents lui-même, et supposez l’amplification plutôt que l’atténuation quand vous estimez jusqu’où une injection précoce peut voyager.

Statut

Il s’agit d’un problème de recherche et de conception affectant le schéma même de la génération de code multi-agents, et non de la CVE d’un éditeur unique. Les constats ci-dessous proviennent de préprints publics et d’un digest de sécurité de juillet 2026.

Élément	Détail
Signalé	Digest de sécurité agentique d’Adversa AI, 2 juillet 2026
Schéma affecté	Frameworks LLM multi-agents de génération de code (MetaGPT, ChatDev, CrewAI, similaires)
Mécanisme	L’instruction injectée se propage via le canal inter-agents de confiance ; les intermédiaires la reformulent et l’amplifient
Impact rapporté	Jailbreak conscient de la propagation rapporté à ~89 % de réussite, contre des références mono-agent plus basses
Atténuation partielle	Codeur-relecteur-testeur + agent d’analyse de sécurité réduit le risque sans l’éliminer
Statut	Problème de recherche ouvert ; pas de correctif unique