Une recherche menée par Pillar Security met en lumière un scénario inquiétant autour de l’architecture des agents d’IA. L’équipe a identifié une attaque entre agents Gemini exploitant la façon dont des agents automatisés peuvent se transmettre des instructions, menant à l’exposition de secrets et à la manipulation de pull requests (PR).
Le problème ne concerne pas un seul composant isolé. Il s’inscrit dans un enchaînement : un agent accessible aux utilisateurs peut être détourné pour déclencher l’action d’un agent doté de droits bien plus élevés. Dans certaines conditions, l’attaquant obtient alors des capacités critiques, dont l’exécution de commandes.
Deux agents, des niveaux de privilèges très différents
Le point de départ de l’enquête se situe dans le dépôt google/adk-python, qui contient des exemples d’agents automatisés. Pillar y distingue deux catégories : des agents à faibles privilèges, exposés et interagissables par des utilisateurs, et des agents à hauts privilèges réservés aux maintainers.
Sur le papier, cette séparation doit limiter l’escalade. En pratique, l’étude montre qu’un attaquant peut utiliser la “passerelle” entre les agents pour faire franchir à la chaîne d’automatisation des limites de sécurité.
Du tri de PR à l’escalade de capacités
Dans un premier temps, Pillar observe un comportement qui attire l’attention. Un agent chargé de trier des pull requests commentait les PR avec le statut de Collaborator. Autrement dit, ce bot disposait de privilèges élevés sur le dépôt.
À partir de là, la recherche décrit une manière de manipuler l’agent afin qu’il publie un commentaire de type @gemini-cli <prompt> sur une PR. Ce déclencheur active ensuite des mécanismes d’orchestration côté dépôt, notamment gemini-invoke, et fournit à l’attaquant un accès à un flux plus privilégié.
Fuite des outils via le workflow gemini-invoke
Une fois le flux privilégié déclenché, le contenu du prompt initial génère une réponse de la partie automatisée. Cette phase fait remonter des informations sensibles : les outils auxquels l’agent privilégié peut accéder, communiqués via un serveur MCP.
Ce que Pillar met en évidence est crucial : le bot disposait, d’après l’étude, d’un accès à toutes les commandes bash. Concrètement, cela signifie qu’un chercheur (et, dans un contexte malveillant, un attaquant) pouvait exécuter du code à distance.
Le rapport indique aussi la possibilité d’extraire le token GitHub de l’agent. Ce type de secret agit comme un “passe-partout” : il peut servir à agir sur le dépôt en usurpant l’identité ou les droits du bot.
Modification de PR, décisions de validation et invocation ciblée
Avec ce niveau d’accès, Pillar explique que l’attaquant pouvait altérer les commentaires, les pull requests et les issues associées à d’autres mainteneurs, collaborateurs et membres. L’impact ne se limite pas à la simple défiguration : l’attaquant peut aussi interférer avec le processus de revue.
La recherche mentionne notamment la capacité de :
- déprioriser ou “supprimer” des revues ;
- approuver des changements de PR ;
- déclencher gemini-invoke et gemini-review sur n’importe quelle PR.
En pratique, cela ouvre la voie à un empoisonnement du cycle d’approbation : l’automatisation peut produire une trace d’actions qui semble légitime, car elle provient du bot et respecte la mécanique attendue.
Pourquoi il fallait quand même de l’ingénierie sociale
Pillar précise toutefois une contrainte. Pour qu’un scénario entièrement malveillant aboutisse à un merge, il fallait que la PR soit approuvée et fusionnée par un membre. Autrement dit, même si la chaîne automatisée pouvait fabriquer une chronologie crédible (triage, revue, approbation), quelqu’un devait encore “valider” humainement le résultat final.
Cette étape ajoute une barrière : l’attaquant doit construire de la confiance, par exemple en se présentant comme un collaborateur. Ensuite, il peut soumettre une première PR contenant du code malveillant, passer par la file de revue, puis utiliser une deuxième PR pour poster des prompts qui “dirigent” l’agent vers le triage, la revue et l’approbation de la première.
Un fil d’actions “plausible” fabriqué par l’automatisation
La description de Pillar insiste sur la dimension narrative de l’attaque. Le chercheur met en avant que l’édition du commentaire du trieur repose sur des primitives d’accès aux ressources, notamment des droits de type issues: write et des permissions liées aux pull requests.
Le résultat est une piste d’audit que le dépôt et ses participants peuvent juger cohérente : “un humain a demandé une revue”, “Gemini a mené l’action”, “Gemini a approuvé”, alors même que ces étapes n’auraient pas eu lieu de manière réellement légitime.
En somme, la combinaison des actions (usurpation guidée, approbations automatiques, altération des demandes de revue) permet de créer une histoire de validation persuasive.
Correctif côté Google, et limites pour une récompense
Google a été informé du problème début juin. D’après les informations rapportées, l’entreprise a corrigé la faiblesse par une démarche de durcissement (hardening). Toutefois, la recherche indique que Google ne considérait pas le cas comme éligible à une récompense de type bug bounty : l’achèvement du scénario nécessitait une phase de social engineering pour obtenir le merge d’une PR malveillante.
Une deuxième faille dans l’écosystème ADK
Peu après, Pillar révèle avoir découvert une autre vulnérabilité dans l’écosystème ADK. Cette fois, le point d’attention se situe dans les fonctionnalités d’automatisation d’un agent basé sur Antigravity-SDK.
Le risque décrit est un remote code execution sans interaction d’un maintainer. En d’autres termes, l’attaque viserait moins la manipulation d’un flux déclenché par des humains et davantage l’exploitation de l’automatisation elle-même.
Google corrige la faiblesse vers la fin juillet, selon le calendrier mentionné.
Ce que les équipes peuvent retenir
Au-delà du cas technique, cette étude rappelle plusieurs principes importants pour sécuriser des systèmes d’agents :
- Vérifier les chemins d’escalade entre agents, surtout quand un agent public peut influencer un agent privilégié.
- Limiter l’accès aux outils exposés aux flux automatisés, afin d’éviter qu’une fuite ne donne prise à l’exécution de commandes.
- Protéger les tokens et réduire leur portée lorsqu’un agent est compromis.
- Analyser l’interface “commentaires ↔ workflows”, car un simple déclencheur peut ouvrir la porte à une orchestration plus puissante.
Enfin, la dimension “preuve” est centrale : une automatisation qui produit des validations plausibles peut tromper les humains. Cela ne supprime pas la nécessité de contrôle, mais augmente l’importance de vérifier la cohérence des changements et de surveiller les déclencheurs inhabituels.
Conclusion
La recherche de Pillar montre qu’une attaque entre agents Gemini peut exploiter des différences de privilèges au sein d’un environnement d’agents d’IA. En manipulant le flux de traitement de pull requests, un acteur malveillant pourrait provoquer une fuite d’outils, obtenir un accès permettant l’exécution de commandes, et perturber le cycle d’approbation.
Si le facteur humain reste déterminant pour fusionner une PR malveillante, l’étude souligne néanmoins un risque réel : la capacité d’un système automatisé à fabriquer des traces d’actions crédibles. Pour les mainteneurs, la priorité consiste à renforcer les protections et à réduire les surfaces où un agent public peut influencer un agent privilégié.
