Le chercheur en sécurité Dan Lisichkin, de Pillar Security, a fait dans le dépôt de l'Agent Development Kit de Google quelque chose qui n'avait pas été démontré publiquement jusque-là : il s'est servi d'un agent IA pour en attaquer un autre.
Le décor est banal, et c'est précisément ce qui rend l'affaire intéressante. Le dépôt google/adk-python, que ses mainteneurs annoncent à plus de 90 millions de téléchargements, fait tourner des agents sur ses propres pull requests. L'un d'eux est un relecteur exposé au public, que la contribution de n'importe qui peut atteindre. Il fonctionne avec un jeton d'accès personnel de collaborateur, autrement dit modeste. Un autre agent se tient plus en profondeur, avec des privilèges de mainteneur.
Le mécanisme
Une pull request, ce n'est pas seulement du code. C'est un titre, un corps, un diff et des commentaires, et tout cela est du texte qu'un agent lit. Lisichkin a placé une injection de prompt dans ce texte. Le relecteur à faible privilège l'a lu, et au lieu de se contenter de relire, il a agi d'une manière qui a déclenché l'agent à privilège élevé.
Rien n'était cassé au sens strict. Chaque agent a fait ce pour quoi il avait été construit. Le relecteur a lu une entrée non fiable, puisque c'est son métier. Le second agent a fait confiance à un signal venu de l'intérieur du dépôt, puisque l'intérieur du dépôt est censé être sûr. Ce que personne n'avait écrit, c'est la frontière entre les deux, et une frontière non écrite n'est pas appliquée.
Google a corrigé et refusé de payer
C'est le passage sur lequel il vaut la peine de s'arrêter, parce que les deux camps ont un vrai argument.
Google a corrigé le problème. Google a aussi refusé la prime, en disant qu'il ne récompense pas les rapports de vulnérabilité qui exigent de l'ingénierie sociale pour permettre une compromission de la chaîne d'approvisionnement, et en soulignant qu'un mainteneur doit tout de même cliquer sur « fusionner », les pull requests n'étant pas fusionnées automatiquement après une revue par un bot.
Ce n'est pas une esquive. C'est factuellement exact : la chaîne ne se referme que si un humain accepte une pull request malveillante. Beaucoup d'échelles de gravité minorent, à raison, les découvertes qui ont besoin de la coopération d'un humain.
La réponse du chercheur est correcte elle aussi, et elle porte sur la conception plutôt que sur la gravité. Sa position, dans ses propres termes, est que les agents devraient avoir leur propre identité, laquelle détermine à quelles ressources ils ont le droit d'accéder et de quelle manière ils ont le droit d'interagir avec ces ressources. Un agent qui emprunte le jeton d'un humain hérite des permissions d'un humain, et aucune étape de revue ne compense cela.
Il n'est pas nécessaire de désigner un gagnant. La lecture honnête, c'est que cet exploit précis avait besoin d'une erreur humaine, et que l'architecture qu'il expose n'en a pas besoin pour poser problème la prochaine fois.
Pourquoi « un humain doit encore fusionner » vieillira mal
Exiger qu'un mainteneur fusionne est une barrière réelle aujourd'hui. C'est une barrière que toute l'industrie travaille en ce moment à supprimer.
Le sens de la marche, dans le développement agentique, va vers moins de points de contrôle humains, pas plus. Chaque règle de fusion automatique, chaque politique du type « le bot a approuvé, donc ça passe », chaque pipeline où la sortie d'un agent alimente un autre agent sans personne au milieu, retire exactement l'étape sur laquelle Google compte. La mesure d'atténuation est organisationnelle, et les mesures organisationnelles se dégradent.
Quoi faire dans votre propre dépôt
Rien de tout cela n'exige la taille de Google pour s'appliquer. Si vous faites tourner des agents sur vos dépôts :
- Donnez à chaque agent sa propre identité. Partager un jeton d'accès personnel entre un humain et un bot, ou entre deux bots, revient à ne plus pouvoir restreindre ni révoquer quoi que ce soit indépendamment, et à ne plus pouvoir dire, dans un journal d'audit, qui a fait quoi.
- Restreignez le jeton à la tâche. Un relecteur a besoin de lire un diff et d'écrire un commentaire. Il n'a pas besoin d'un accès en écriture sur les branches.
- Traitez tout ce qu'un agent lit depuis l'extérieur comme porteur d'instructions. Le corps d'une pull request écrit par un inconnu mérite la même méfiance qu'un champ de formulaire sur un site public. Notre guide sur la sécurité des agents IA couvre le motif général.
- Ne laissez pas la sortie d'un agent servir de déclencheur de confiance à un autre. Si l'agent B agit sur la parole de l'agent A, alors qui contrôle l'entrée de A contrôle B.
Ne confondez pas avec les paquets litellm
Un incident distinct touche le même écosystème et se mélange souvent à celui-ci. En mars 2026, des versions malveillantes de litellm, 1.82.7 et 1.82.8, ont été publiées sur PyPI au moyen d'identifiants de mainteneur compromis, dans une fenêtre d'environ trois heures. Quiconque installait google-adk avec extensions pendant cette fenêtre les récupérait.
C'est une compromission de dépendance classique : identifiants volés, paquet empoisonné, fenêtre courte. Cela n'a rien à voir avec des agents qui se parlent. Les deux sont des incidents de chaîne d'approvisionnement, mais les défenses diffèrent, et les traiter comme une seule histoire revient à en corriger une en croyant avoir couvert l'autre.
Ce qu'il faut retenir
La découverte est modeste dans son impact immédiat et considérable dans ce qu'elle signale. Un agent n'est pas un outil qui s'exécute quand on appuie sur un bouton. C'est un acteur qui lit, décide et agit, et dès que vous en avez deux dans le même dépôt avec des privilèges différents, vous avez une frontière de confiance, que vous l'ayez conçue ou non.
Donnez des identités aux agents avant de leur donner des permissions.
Sources
- Recherche Pillar Security, rapportée par The Register, 3 août 2026.
