Une faille de cloisonnement expose les agents IA de Google

Des chercheurs de Pillar Security ont mis au jour, dans google/adk-python, une faille qui permettait à un agent IA d’en manipuler un autre, plus privilégié, via une injection de prompt. L’affaire, rendue publique le 3 août 2026, touche le kit open source de développement d’agents IA de Google, téléchargé plus de 90 millions de fois. Google a corrigé le problème, mais a refusé de verser une prime bug bounty, estimant que l’attaque reposait aussi sur de l’ingénierie sociale. Le cas compte surtout pour les chaînes CI/CD, où des agents automatisés commencent à prendre des décisions qui dépassent parfois leur périmètre initial.

Quand deux agents partagent trop de confiance

Le scénario décrit par Pillar Security repose sur deux agents automatisés aux droits différents, mais reliés par une frontière de confiance trop poreuse. D’un côté, un agent public, déclenché lors de l’ouverture d’une pull request ou d’un ticket ; de l’autre, un agent réservé aux mainteneurs, capable d’exécuter des actions plus sensibles. Selon Dan Lisichkin, qui a découvert la faille, l’agent de tri pouvait être amené à déclencher le second en suivant des instructions cachées dans une contribution apparemment légitime.

La technique porte un nom simple et peu élégant : l’injection de prompt, c’est-à-dire l’insertion d’instructions malveillantes dans un texte que l’IA traite comme une consigne valide. Ici, le chercheur affirme avoir combiné une première pull request crédible avec une seconde, piégée, afin de reconstituer un historique suffisamment plausible pour tromper le flux automatisé. Le résultat ressemble à un feuilleton de bureau écrit par un script mal luné : un agent “demande” un avis, un autre “répond”, et la chaîne de confiance se referme.

Pourquoi Google a corrigé sans payer

Google a confirmé avoir hardené le dépôt, mais a jugé que le signalement ne méritait pas de récompense financière. L’entreprise explique que l’exploit démontrait bien l’exfiltration d’un jeton GitHub avec la permission pull-requests: write, mais qu’une action humaine restait nécessaire pour fusionner la modification malveillante. Autrement dit, la faille existait, mais elle ne cochait pas toutes les cases du programme de bug bounty [à vérifier].

Ce désaccord dit quelque chose de plus large sur la maturité encore fragile des agents IA. Pour Google, le risque relève en partie d’une chaîne de décisions humaines. Pour Pillar Security, l’incident montre surtout qu’un agent peut servir de tremplin vers un autre, plus sensible, et que les modèles de menace actuels ne couvrent pas encore bien ces interactions. Lisichkin estime qu’un bot devrait disposer de sa propre identité et d’autorisations clairement bornées, plutôt que de se glisser dans des droits de collaborateur déjà en place.

La vraie question : qui a le droit de parler pour qui ?

Cette affaire dépasse le cas Google parce qu’elle touche un angle mort classique de la sécurité applicative : les identités machine à machine. Quand un agent agit au nom d’un humain, ou semble le faire, la frontière entre automatisation et privilège devient floue. Dans les dépôts de code, les workflows de revue, de triage et d’approbation sont déjà sensibles ; y ajouter des agents qui commentent, classent et déclenchent des actions rend l’ensemble plus rapide, mais aussi plus difficile à auditer.

Pillar Security considère cette attaque comme une première en conditions réelles, au sens d’une exploitation agent contre agent documentée dans un environnement de production. La menace n’est pas seulement théorique pour les équipes sécurité, qui commencent à déployer des assistants dans les pipelines de développement. À ce stade, le message est limpide : si un agent peut en appeler un autre, il faut définir précisément lequel parle, lequel écoute et lequel n’a tout simplement pas le droit d’ouvrir la porte.