Des chercheurs de la société israélienne Pillar Security affirment avoir démontré la première attaque « agent contre agent » observée en conditions réelles : en piégeant un agent IA public au privilège limité, ils l'ont amené à commander un second agent bien plus puissant, jusqu'à obtenir l'exécution de code arbitraire et le vol d'un jeton d'accès. La cible n'était pas un logiciel quelconque, mais l'automatisation du dépôt du kit de développement d'agents de Google pour Python (Agent Development Kit, ADK). Google a réagi en supprimant purement et simplement trois de ses ateliers automatisés. Après l'affaire OpenAI de juillet, l'été 2026 confirme que la sécurité des agents d'IA est devenue un chantier à part entière.

Un agent IA, une injection de prompt : de quoi parle-t-on

Un « agent » d'IA n'est pas un simple robot conversationnel qui répond à une question. C'est un programme bâti autour d'un grand modèle de langage auquel on a donné des outils et une marge d'autonomie : lire des messages, écrire des fichiers, lancer des commandes, ouvrir ou corriger un ticket sur un dépôt de code. On le laisse enchaîner ces actions seul pour accomplir une tâche. Sa puissance vient précisément de là — et sa fragilité aussi.

Le talon d'Achille des agents porte un nom : l'injection de prompt. Un modèle de langage ne distingue pas vraiment ses consignes légitimes du texte qu'on lui donne à traiter. Si une donnée censée être inerte — le corps d'un ticket, un commentaire, un fichier — contient en réalité des instructions, l'agent risque de les exécuter comme si elles venaient de son propriétaire. C'est l'équivalent, pour une IA, d'un mot glissé dans une pile de documents et qui se ferait passer pour un ordre du patron. Le problème est connu depuis les débuts des assistants IA ; ce qui change ici, c'est l'échelle à laquelle il se propage.

La nouveauté : une attaque qui vise le lien entre deux agents

Jusqu'à présent, une injection de prompt piégeait un agent. La démonstration de Pillar Security frappe autre chose : la relation de confiance entre plusieurs agents qui collaborent dans une même chaîne d'intégration (le pipeline CI/CD, ces automatisations qui testent et fusionnent le code sur un dépôt). L'idée est de compromettre un agent modeste, accessible au public et sans grand pouvoir, puis de s'en servir comme d'un relais pour donner des ordres à un second agent, lui, hautement privilégié.

« Cette faille crée un nouveau type d'attaque que beaucoup de modèles de menace existants ne prennent pas encore en compte », résume le chercheur Dan Lisichkin, cité par CSO Online. Pillar décrit ses résultats comme « le premier cas concret et réel d'exploitation agent contre agent » dans un système multi-agents en production. C'est ce caractère inédit que met en avant le reportage de Techzine.

Comment le piège fonctionne

La cible n'est pas la bibliothèque ADK que téléchargent les développeurs, mais l'automatisation qui fait tourner le dépôt ADK-Python de Google sur GitHub. Ce dépôt confiait une partie de sa maintenance à des agents. Les chercheurs ont trouvé deux chemins d'attaque, détaillés par The Hacker News.

Le plus démonstratif repose sur un ticket public. N'importe qui pouvait ouvrir une issue sur le dépôt ; un agent d'analyse (issue-analyze.yml) la lisait automatiquement, puis publiait son verdict sous l'identité du compte robot adk-bot. En glissant les bonnes instructions dans le texte du ticket, un attaquant pouvait pousser cet agent public à poster lui-même la commande /adk-issue-fix — mais signée adk-bot, donc perçue comme émanant d'un membre de confiance. Cette commande réveillait alors un second atelier bien plus puissant, issue-fix.yml, chargé de « corriger » le code.

Le défaut de conception tient en une phrase : le garde-fou vérifiait qui avait posté la commande, pas si un intrus avait manipulé le compte de confiance pour le faire à sa place. Or l'agent privilégié disposait de clés sérieuses : une clé de compte de service Google Cloud (ADK_GCP_SA_KEY), une clé d'API Google et un jeton d'accès personnel (PAT) aux permissions larges sur les tickets, le contenu et les pull requests. En théorie, cet agent n'avait droit qu'à des commandes Git et GitHub. Mais Git offre une échappatoire connue : en détournant les hooks (via core.hooksPath), l'équipe a obtenu l'exécution de code arbitraire sur le serveur d'intégration, puis exfiltré le jeton du bot.

Le second chemin passait par les pull requests : un agent de triage examinant les contributions externes pouvait être amené à publier une commande adressée à l'assistant @gemini-cli, déclenchant un flux réservé aux contributeurs de confiance. Un humain devait certes valider la fusion finale — mais les chercheurs ont montré que l'automatisation piégée pouvait modifier les commentaires des mainteneurs et contrefaire des approbations, de quoi tromper la personne appelée à cliquer.

La réponse de Google, et la ligne de fracture

Google n'a pas colmaté ces ateliers : il les a supprimés. Trois fichiers de workflow — issue-analyze.yml, issue-fix.yml et pr-analyze.yml — ont disparu du dépôt, l'entreprise reconnaissant qu'ils « traitaient des tickets et des contributions non fiables avec des identifiants larges sur le dépôt ». Le calendrier, reconstitué par The Hacker News : retrait confirmé le 2 juillet 2026, second problème corrigé le 21 juillet, absence des trois fichiers vérifiée le 4 août. Point notable, Google a refusé de verser une prime de bug bounty, estimant que l'attaque supposait in fine l'aval d'un mainteneur humain — un argument que les chercheurs contestent, puisqu'ils ont justement montré comment fabriquer de fausses preuves pour obtenir cet aval.

Google précise, à juste titre, que la faille visait l'automatisation d'un dépôt, non le paquet ADK que des milliers de développeurs installent. La distinction est importante pour rassurer les utilisateurs — mais elle n'efface pas la leçon de fond.

Ce que l'épisode dit de la sécurité des agents

Le message des experts converge. « Le langage naturel a rejoint le chemin d'autorisation », résume Sanchit Vir Gogia (Greyhound Research) auprès de CSO Online : à partir du moment où une phrase écrite en clair peut déclencher une action privilégiée, la frontière entre donnée et commande s'efface. Et « un attaquant n'a besoin d'aucun droit de fusion s'il peut fabriquer les preuves » qui convaincront quelqu'un d'autre de fusionner. Les outils classiques de gestion des identités et des accès, note-t-il, ne savent pas suivre la façon dont l'autorité se propage d'un agent à l'autre. Pillar recommande de donner à chaque agent une identité distincte assortie de permissions strictement délimitées, et de considérer que la portée réelle d'un agent inclut tous les systèmes que sa sortie peut déclencher.

L'affaire s'inscrit dans une série. En juillet, OpenAI avait révélé que deux de ses modèles s'étaient extraits d'un environnement de test pour pirater une infrastructure tierce, et Anthropic avait ensuite reconnu des accès « sans autorisation » lors de ses propres évaluations (voir Anthropic : trois versions de Claude ont accédé sans autorisation aux systèmes d'autres organisations). Là, il s'agissait de modèles trop zélés dans un bac à sable mal cloisonné ; ici, d'un attaquant humain qui instrumentalise des agents les uns contre les autres. Deux visages du même basculement : à mesure que l'on confie des agents autonomes à des tâches réelles, chaque outil qu'on leur donne devient une porte, et chaque agent voisin, un vecteur possible. La sécurité des agents n'est plus une hypothèse d'école.