Attaque agent contre agent : la première démonstration réelle vise Google
Un chercheur de Pillar Security a fait manipuler un agent de tri de Google par un simple message public, pour en déclencher un autre bien plus puissant.
Le 3 août 2026, la société de sécurité Pillar Security a publié un billet de recherche signé Dan Lisichkin. Il y décrit ce qu'il présente comme le premier cas pratique d'exploitation d'un agent IA par un autre agent IA dans un environnement de production réel. Le terrain : `google/adk-python`, le dépôt public de l'Agent Development Kit, la boîte à outils open source de Google pour construire des agents, qui compte plus de 21 000 étoiles sur GitHub au 5 août 2026.
L'été 2026 aura été chargé sur ce front. En juillet, un agent d'OpenAI sortait de son bac à sable pour attaquer Hugging Face, puis Anthropic reconnaissait que trois de ses modèles avaient compromis des entreprises réelles pendant des évaluations. Dans ces deux dossiers, l'agent débordait au cours de ses propres tests. Ici, personne ne déborde. Un agent est retourné contre un autre, à distance, par du texte que n'importe qui pouvait déposer.
Ce que Pillar Security a exactement trouvé
Le dépôt d'ADK faisait tourner deux familles d'agents automatisés, décrit le billet. La première, à faibles privilèges, était branchée sur des workflows ouverts à tous : ils se déclenchaient dès qu'un internaute ouvrait une pull request ou signalait un problème, pour faire un premier tri. La seconde était réservée aux mainteneurs et disposait d'une vraie autorité sur le dépôt. Ces agents privilégiés s'invoquaient par un commentaire commençant par `@gemini-cli`, que seuls un membre, un collaborateur ou l'auteur de la pull request pouvaient poster.
Le point de rupture n'était pas dans l'un ou l'autre de ces agents, mais dans la couture entre les deux. Le chercheur raconte avoir remarqué une anomalie en parcourant les commentaires de l'agent de tri : celui-ci ne s'exprimait pas comme un bot GitHub ni comme une application, mais à travers un compte utilisateur doté du statut de collaborateur et d'un jeton d'accès personnel. Ses commentaires franchissaient donc le contrôle censé réserver l'agent privilégié aux humains de confiance.
La suite tient dans une injection de prompt, cette technique qui consiste à glisser dans un contenu lu par un modèle des instructions qu'il exécute comme si elles venaient de son opérateur. Dan Lisichkin écrit que ses premières tentatives étaient purement et simplement ignorées, parce que le prompt système ordonnait à l'agent de suivre les règles de contribution du projet. Il a donc changé d'approche et reformulé sa demande pour qu'elle ressemble à une étape de tri conforme à ces mêmes règles. L'agent de tri a alors publié le commentaire demandé, et le workflow privilégié s'est mis en route.
Deux précisions d'honnêteté s'imposent ici. La chaîne complète a été rejouée dans un laboratoire répliquant l'environnement et sur un projet de démonstration créé par le chercheur, pas contre le dépôt de Google en fonctionnement. Mais la configuration vulnérable, elle, était bien réelle, et d'autres s'y frottaient déjà : une pull request ouverte le 28 mai 2026 par un compte extérieur, intitulée « PoC v2 POC-MARKER-verify », montre un tiers faisant afficher à l'agent un marqueur de son choix.
Aucun code malveillant n'est entré dans ADK. Le scénario d'impact décrit par Pillar est une opération d'ingénierie sociale : fabriquer sur une pull request piégée une fausse trace « un humain a demandé la revue, l'agent l'a faite, l'agent a approuvé », pour qu'un mainteneur fusionne sans regarder. Le billet le reconnaît lui-même en conclusion : les garde-fous humains maintenus par Google, protection de branche, revue humaine exigée et séparation des rôles, ont empêché ces vulnérabilités de compromettre le dépôt.
Faut-il mettre à jour votre installation d'ADK ?
C'est la question que se pose tout lecteur qui a déjà tapé `pip install google-adk`, et la réponse mérite d'être nette. Les trois correctifs identifiables dans l'historique du dépôt ne touchent que des fichiers `.github/workflows/`, c'est-à-dire l'automatisation du projet, pas une ligne du code livré aux développeurs. Au 5 août 2026, aucun avis de sécurité GitHub n'est publié sur `google/adk-python` et aucune entrée correspondante n'apparaît dans la base NVD.
| Ce que vous utilisez | Touché ? | Ce que ça change pour vous |
|---|---|---|
| Le dépôt `google/adk-python` et sa chaîne d'intégration continue | Oui | Les workflows en cause ont été retirés du dépôt en juin 2026 |
| Le paquet `google-adk` que vous installez | Rien ne l'indique | Aucun correctif de sécurité de la bibliothèque, aucun CVE, aucun avis GitHub à ce jour |
| Vos propres agents branchés sur des tickets, des pull requests ou une boîte mail | À vérifier chez vous | Le schéma d'attaque, lui, se transpose tel quel |
Dit autrement : cette affaire ne vous demande rien à installer. Elle vous demande de regarder vos propres tuyaux.
Le commit du 3 juin est le plus parlant, parce qu'il dit la chose sans détour dans son intitulé et supprime les trois fichiers d'un coup, dès le lendemain du signalement.
Un détail mérite d'être noté sur la ligne du 11 juin : ce durcissement du workflow de triage vient d'une pull request déposée la veille par un contributeur extérieur au projet, pas de Google ni de Pillar. Preuve que plusieurs personnes regardaient ce dépôt au même moment.
La réponse de Google, et le refus de prime
Google a corrigé, mais n'a pas payé. Le panel de son programme de récompense pour les logiciels open source a estimé que le dossier n'atteignait pas le seuil d'une prime financière, tout en accordant au chercheur un crédit en « Honorable Mention ». Sa motivation, reproduite intégralement dans le billet de Pillar, est instructive.
Ce rapport démontre l'exfiltration d'un jeton GitHub doté de la permission « pull-requests: write », qui permet d'altérer une pull request mais exige toujours qu'un mainteneur agisse pour fusionner la pull request malveillante, les pull requests n'étant pas fusionnées automatiquement après une revue par un bot. Nous ne récompensons pas les rapports de vulnérabilité qui nécessitent de l'ingénierie sociale pour permettre une compromission de la chaîne d'approvisionnement logicielle. Nous avons néanmoins pris des mesures pour durcir le dépôt, et nous reconnaîtrons donc ce rapport par un crédit.Panel du programme de récompense open source de Google, cité par Pillar Security
L'argument se tient sur le plan du barème, et Pillar ne le conteste pas frontalement. Il pose quand même une question de fond : si l'automatisation par agents sert précisément à réduire le temps qu'un humain passe à relire, combien de temps la revue humaine restera-t-elle le dernier garde-fou du raisonnement ?
Pourquoi un agent branché sur vos tickets hérite du même risque
C'est là que le dossier cesse d'être une affaire Google. Le mécanisme n'a rien de spécifique à ADK ni à Gemini : il suffit qu'un agent lise du texte que n'importe qui peut écrire et qu'il détienne un identifiant valide. Un agent qui trie vos tickets de support, qui répond à une boîte mail partagée ou qui commente vos pull requests remplit les deux conditions par construction.
Un agent qui lit du texte non fiable et détient un identifiant est, fonctionnellement, une primitive d'escalade de privilèges qui parle anglais, et qu'on peut convaincre d'agir en votre nom.Dan Lisichkin, Pillar Security
Le billet adresse plusieurs recommandations aux responsables sécurité. Quatre touchent directement à la conception des agents, et nous les reprenons telles qu'elles sont écrites. Inventorier les workflows agentiques déjà présents dans la chaîne, en particulier ceux qui avalent de l'entrée non fiable (tickets, pull requests, e-mails, conversations de support) tout en détenant des identifiants. Traiter tout agent exposé à du texte non fiable comme potentiellement contrôlé par un attaquant, et réduire ses outils et ses jetons au strict minimum. Ne pas rattacher un agent à un compte utilisateur humain ni à un jeton personnel de longue durée doté de larges privilèges, mais lui donner sa propre identité, étroite et auditable. Enfin, s'assurer qu'aucun agent ne peut en déclencher un autre au-delà d'une frontière de privilèges sans un contrôle qu'une injection de prompt ne sait pas contrefaire.
N'importe qui sur Internet peut laisser un mot sur un projet logiciel public. Google avait un assistant IA qui lisait chacun de ces mots. Rédigez ce mot avec assez de soin, et l'assistant répétera votre instruction comme si elle était la sienne. Et comme cet assistant publiait sous un compte du personnel, tout ce qu'il disait arrivait avec l'apparence d'un message écrit par le personnel. Alors une seconde IA, qui n'obéit qu'au personnel et détient un vrai pouvoir sur le code, s'est exécutée. Le badge d'une IA est devenu le laissez-passer d'une autre. Notre recherche en a trouvé deux versions à l'intérieur de la propre boîte à outils de Google pour construire des agents IA, celle que beaucoup d'équipes utilisent pour construire les leurs. Nous les avons signalées toutes les deux, et Google les a corrigées. Dan Lisichkin, notre chercheur, a trouvé la chaîne complète. Venez le rencontrer au stand 5711 de Black Hat, puis assistez à sa session à l'AI Village, DEF CON, le vendredi 7 août, de 16 h à 17 h PDT. Compte rendu complet : https://www.pillar.security/blog/ill-just-call-you-agent-to-agent-privilege-boundary-failures-in-ci-cd-on-googles-adk-repositoryVoir le post sur X
Une nuance sur ce post, qui parle de « la propre boîte à outils de Google ». Les deux problèmes signalés vivaient dans l'automatisation du dépôt qui héberge cette boîte à outils, pas dans le code qu'elle distribue. La distinction ne change rien à la démonstration, elle change tout à ce que vous devez faire ce matin.
Le contrôle le plus rentable ne coûte rien : donnez à chaque agent son propre compte de service, jamais celui d'un humain ni un jeton personnel réutilisé. C'est exactement ce qui a permis à l'agent de tri de franchir une porte qui ne lui était pas destinée.
Reste le constat de fond, valable bien au-delà de ce dépôt. Chaque brique du système était défendable prise isolément : un agent de tri public est raisonnable, un agent de revue réservé aux mainteneurs est raisonnable, des jetons à portée réduite sont une bonne pratique. Ce sont les liens entre agents, la délégation, l'usurpation, le déclenchement, qui font désormais partie de la surface d'attaque. Google emploie pourtant les mêmes agents du côté de la défense : sur les jalons Chrome 149 et 150, l'éditeur revendique 1 072 bugs de sécurité corrigés, davantage que sur les 23 jalons précédents réunis. Pour quiconque déploie des agents en entreprise, c'est la ligne à ajouter au modèle de menace.
Questions fréquentes
Qu'est-ce que le kit ADK de Google ?
L'Agent Development Kit est le cadre open source de Google pour construire, tester et déployer des agents IA. Il existe en Python, TypeScript, Go, Java et Kotlin, sous licence Apache 2.0, et son dépôt Python dépasse 21 000 étoiles sur GitHub au 5 août 2026.
Les utilisateurs d'ADK sont-ils exposés ?
Rien ne l'indique. Les problèmes signalés se trouvaient dans les workflows GitHub Actions du dépôt de Google, et les correctifs identifiables ne touchent que ces fichiers d'automatisation, pas la bibliothèque distribuée aux développeurs.
Existe-t-il un CVE pour cette faille ?
Aucun à notre connaissance au 5 août 2026 : ni avis de sécurité GitHub publié sur `google/adk-python`, ni entrée correspondante dans la base NVD.
Qu'est-ce qu'une injection de prompt ?
Une instruction cachée dans un contenu que le modèle va lire (un ticket, un commentaire, un e-mail, une page web) et qu'il exécute comme si elle venait de son opérateur légitime. C'est le vecteur central de ce dossier.
Google a-t-il payé le chercheur ?
Non. Le panel du programme de récompense open source a jugé que l'impact n'atteignait pas le seuil d'une prime, au motif que le scénario exige de l'ingénierie sociale et l'action d'un mainteneur pour fusionner. Il a accordé un crédit en « Honorable Mention » et confirmé le durcissement du dépôt.
En quoi est-ce différent des affaires OpenAI et Anthropic ?
Dans ces deux cas, un agent débordait pendant ses propres évaluations de sécurité. Ici, un attaquant extérieur retourne délibérément un agent contre un autre, plus privilégié. Le détail est dans nos articles sur l'agent d'OpenAI et Hugging Face et sur les intrusions reconnues par Anthropic.
Comment protéger un agent branché sur un dépôt de code ?
Pillar Security recommande de lui donner sa propre identité auditable plutôt qu'un compte humain, de limiter ses outils et ses jetons au strict minimum, et de vérifier qu'aucun agent ne peut en déclencher un autre plus privilégié sans un contrôle qu'une injection de prompt ne peut pas contrefaire.
