Injection multi-agents : propagation, A2A et test

Comment une injection se propage-t-elle d’un agent à l’autre ?

Elle se propage parce qu’un message d’agent est du texte comme un autre : le modèle destinataire ne sait pas qu’il contient une consigne d’origine externe. Une page web lue par un agent de recherche devient un résumé, ce résumé devient l’entrée de l’orchestrateur, et l’orchestrateur le transforme en ordre pour un agent qui dispose d’outils d’écriture.

Les chercheurs Lee et Tiwari ont décrit en octobre 2024 une variante qu’ils appellent « Prompt Infection » : un prompt malveillant qui se réplique d’un agent à l’autre, comme un virus, et peut mener à du vol de données, de la fraude ou des perturbations sur l’ensemble du système. Leurs expériences indiquent que les systèmes multi-agents y sont très exposés, même lorsque les agents ne partagent pas tous leurs échanges.

Trois mécanismes reviennent en test :

• La délégation de confiance : l’orchestrateur exécute ce que le sous-agent « a trouvé » sans le requalifier comme donnée non fiable.
• La mémoire partagée : un agent écrit dans un état commun (fil de discussion, base vectorielle, fichier de notes) qu’un autre agent relira plus tard comme source fiable.
• La remontée de privilège : une charge qui n’aurait aucun effet sur l’agent exposé en a un sur l’agent suivant, qui détient des permissions plus larges.

Quelles attaques ont été démontrées sur des systèmes multi-agents ?

Une étude académique donne des mesures concrètes. Triedman, Jha et Shmatikov (mars 2025, révisé en septembre 2025) montrent qu’un contenu adversaire placé dans une entrée non fiable (page web, fichier, pièce jointe) peut prendre le contrôle de la communication entre agents et déclencher l’exécution de code arbitraire ou l’exfiltration de données. Avec des agents GPT-4o, les attaques par le web ont abouti dans 58 à 90 % des essais selon l’orchestrateur, et jusqu’à 100 % dans certaines configurations. Les auteurs précisent que l’attaque fonctionne même quand chaque agent pris isolément résiste à l’injection directe ou indirecte.

Ce résultat change la manière de tester : valider chaque agent séparément ne suffit pas. C’est l’assemblage, c’est-à-dire l’orchestrateur et ses règles de routage, qui crée la faille.

Que change le protocole A2A ?

Le protocole Agent2Agent (A2A) standardise la découverte et l’échange entre agents. Chaque serveur publie une « Agent Card », un document JSON qui décrit son identité, ses capacités, ses compétences, son point d’accès et ses schémas d’authentification. La spécification exige que les serveurs rejettent les requêtes dont les identifiants sont absents ou invalides, et traite l’autorisation séparément. Le protocole fournit donc un cadre d’authentification, mais il ne dit rien sur la fiabilité du contenu que l’agent distant renvoie.

C’est ce que montre l’équipe Unit 42 de Palo Alto Networks (31 octobre 2025) avec l’« agent session smuggling ». Les sessions A2A gardent un état : un agent distant malveillant peut s’en servir comme canal discret pour glisser des instructions entre la requête du client et la réponse du serveur. Dans leurs deux preuves de concept, un assistant de recherche compromis a extrait peu à peu des configurations, des schémas d’outils et l’historique de session d’un assistant financier, puis, dans l’autre scénario, a provoqué un achat d’actions non autorisé (10 titres). La chaîne : délégation légitime, questions de clarification, divulgation progressive, action non autorisée.

Comment tester la propagation d’une injection ?

On teste la propagation en plaçant une charge unique et traçable à l’entrée la plus exposée, puis en observant jusqu’où elle voyage. La méthode tient en cinq étapes :

1. Cartographier les agents, leurs outils, leurs permissions et les canaux entre eux (appels directs, mémoire partagée, A2A, files de messages).
2. Choisir les points d’entrée : tout ce qu’un tiers peut écrire (page web, ticket, e-mail, document déposé, champ de formulaire).
3. Semer une charge marquée, par exemple une consigne bénigne qui demande d’ajouter un mot-clé unique dans la prochaine action. Le marqueur permet de savoir quel agent l’a suivie.
4. Suivre la trace dans les journaux : le marqueur apparaît-il dans la sortie du sous-agent, dans l’ordre de l’orchestrateur, dans un appel d’outil ?
5. Monter en gravité seulement ensuite, sur un environnement de test : appel d’un outil d’écriture, lecture d’une donnée hors périmètre, envoi vers une destination externe.

Les questions qui font ressortir les failles :

• Le sous-agent qui lit le web a-t-il accès à des outils d’écriture ? Il ne devrait pas.
• L’orchestrateur distingue-t-il une donnée d’une instruction, ou colle-t-il tout dans le même prompt ?
• Une charge écrite dans la mémoire partagée se déclenche-t-elle dans une session ultérieure, ouverte par un autre utilisateur ?
• Un agent distant A2A peut-il poser des questions de clarification qui amènent le client à divulguer sa configuration ?

Pour les environnements de test, CleanIssue part par défaut sur du développement ou de la préproduction. Un test en production se fait uniquement sur demande écrite du client.

Quels garde-fous réduisent la propagation ?

Les garde-fous efficaces se placent entre les agents, dans le code qui relie leurs échanges. L’OWASP classe l’injection de prompt en LLM01:2025 : une consigne dans un prompt reste une consigne que le modèle peut ignorer.

• Séparer les rôles : l’agent qui lit du contenu non fiable n’a aucun outil d’écriture ni accès aux secrets.
• Typer les messages entre agents : un résultat de sous-agent est une donnée structurée avec un schéma, pas du texte libre réinjecté dans un prompt.
• Valider hors du modèle : les actions à effet (envoi, écriture, suppression, paiement) passent par une règle déterministe ou une validation humaine.
• Limiter la mémoire partagée : cloisonner par utilisateur et par session, et tracer qui a écrit quoi.
• Authentifier les agents distants : vérifier l’identité de l’Agent Card et limiter ce qu’une session A2A peut demander.
• Journaliser la chaîne complète : chaque délégation, avec son origine, pour pouvoir remonter jusqu’à l’entrée.

Pourquoi un test manuel complète-t-il les scanners ?

Un scanner envoie des charges connues (nous comparons les principaux dans un article dédié) à un point d’entrée et lit la réponse finale. Un système multi-agents demande de comprendre le routage : quel agent décide quoi, avec quelles données, et où poser la charge pour qu’elle traverse. C’est un travail de lecture de l’architecture, puis d’essais ciblés, que l’on retrouve dans notre méthode.

Le Red Team Agent Express (1 900 €, 5 jours, démarrage sous 48 h après signature du devis et de l’autorisation) couvre un agent et ses frontières directes. Pour un système avec plusieurs agents, un orchestrateur et des échanges A2A, le périmètre se chiffre sur devis : voir le Red Team sur mesure. Le premier échange est un rendez-vous découverte gratuit de 30 minutes.

Pour aller plus loin

• Injection de prompt : le guide
• Red teaming d’agents IA
• Sécurité des agents IA
• Injection indirecte via RAG
• Human-in-the-loop : valider les actions de l’agent