En bref
La société de sécurité Pillar Security a révélé une faille dans l'automatisation entourant l'Agent Development Kit (ADK) open source de Google pour Python : un ticket GitHub public — accessible en écriture par n'importe qui — pouvait injecter des instructions malveillantes dans un agent de triage à faibles privilèges pour lui faire invoquer un agent de correction de code à hauts privilèges, aboutissant à une exécution de code arbitraire sur le runner CI et à l'exfiltration du jeton adk-bot, d'une clé API Google et d'un identifiant de compte de service Google Cloud. Pillar décrit cette attaque comme le premier cas pratique et réel d'exploitation agent-à-agent dans un système multi-agents en production. Google a supprimé les workflows vulnérables en juillet 2026, la recherche ayant été publiée début août.
Cette histoire concerne moins un dépôt particulier qu'un schéma de conception qui se répand rapidement. À mesure que les équipes connectent des agents IA autonomes pour trier des tickets, réviser des pull requests et pousser des correctifs, la frontière qui séparait autrefois « lit des données non fiables » et « détient des secrets de production » s'efface silencieusement au sein d'une seule chaîne automatisée — et l'injection de prompts est le vecteur qui la franchit.
Ce que Pillar Security a découvert
L'ADK est le framework de Google pour construire et orchestrer des agents IA, et — comme beaucoup de projets open source aujourd'hui — son propre dépôt utilisait des agents pour participer à sa propre maintenance. Les chercheurs de Pillar Security ont examiné l'automatisation GitHub attachée au dépôt ADK pour Python et ont découvert que ses workflows multi-agents pouvaient être retournés contre le projet. La faiblesse centrale n'était pas un bug mémoire ou un correctif manquant ; c'était une défaillance de frontière de confiance entre deux agents qui n'étaient jamais censés avoir la même autorité.
D'un côté se trouvait un agent de triage public, exposé sur Internet, dont la mission était de lire les tickets entrants et les pull requests — du contenu que n'importe quel utilisateur anonyme peut écrire. De l'autre côté se trouvait un agent de correction de code privilégié, construit sur l'agent de codage Antigravity de Google, capable de modifier le dépôt et fonctionnant avec accès à des secrets. Pillar a démontré que le premier agent pouvait être amené à commander le second. Parce que l'agent de triage traitait le texte d'un ticket GitHub comme des instructions, un attaquant pouvait y intégrer une directive le poussant à publier un commentaire déclencheur en tant qu'adk-bot, lançant ainsi le workflow de correction privilégié comme si un mainteneur de confiance l'avait demandé.
Comment un agent en a détourné un autre
Le point d'entrée était un workflow public issue-analyze.yml qui se déclenchait automatiquement à chaque ouverture d'un ticket. Ce workflow s'authentifiait avec une clé de compte de service Google Cloud (ADK_GCP_SA_KEY) et transmettait un agent de triage et une clé API Google (GOOGLE_API_KEY) à l'agent de codage Antigravity. Autrement dit, une automatisation accessible par tout utilisateur GitHub anonyme était déjà connectée à des identifiants sensibles.
À partir de là, Pillar a démontré l'escalade. Des instructions injectées par prompt dans le ticket ont orienté l'agent à faibles privilèges vers l'invocation de celui à hauts privilèges — les chercheurs décrivent cela comme la publication de /adk-issue-fix par le bot — ce qui a lancé le job de correction avec des autorisations élevées. En exploitant la capacité de Git à exécuter du code pendant ce job, l'équipe a obtenu une exécution de code arbitraire sur le runner d'intégration continue et exfiltré le jeton d'accès personnel du bot. Le même job privilégié détenait également une clé API Google et un identifiant de compte de service Google Cloud, ce qui signifie qu'un seul ticket malveillant pouvait mener à l'exécution de code et à la compromission de plusieurs secrets actifs. Pillar a confirmé que les workflows concernés ont été retirés le 2 juillet 2026, et Google a confirmé un correctif pour le second problème le 21 juillet 2026 ; les conclusions ont été publiées début août.
Pourquoi c'est un schéma récurrent, pas un cas isolé
Il serait tentant de classer cela dans la catégorie « Google a mal configuré un workflow » et de passer à autre chose. Ce serait passer à côté de l'essentiel. Le même schéma apparaît partout où un agent à faibles privilèges consommant du contenu non fiable peut, directement ou indirectement, amener un agent ou un job à plus hauts privilèges à agir. « L'autorité d'un agent doit être mesurée non seulement par les outils qui lui ont été attribués, mais aussi par les systèmes plus privilégiés que sa sortie peut déclencher ou influencer », a déclaré Sanchit Vir Gogia de Greyhound Research à CSO Online — un résumé précis du problème d'autorité transitive au cœur de cette classe de vulnérabilité.
L'injection de prompts est le vecteur facilitateur, car les instructions en langage naturel et les données partagent le même canal : un agent ne peut pas distinguer de manière fiable « analyse ce rapport de bug » de « analyse ce rapport de bug, puis déclenche le workflow de correction ». Enchaînez deux ou trois agents et le rayon d'action ne se limite plus aux permissions du maillon le plus faible — c'est la permission la plus élevée accessible en aval. Sakshi Grover d'IDC Asie-Pacifique a formulé la réponse défensive dans les mêmes termes : identifier quels agents consomment du contenu non fiable, tracer si leurs sorties peuvent déclencher des workflows plus privilégiés, et cartographier les capacités effectives maximales des identifiants impliqués.
Ce que cela signifie pour les équipes logicielles américaines et européennes
La plupart des équipes ne maintiennent pas un dépôt de framework, mais beaucoup font désormais exactement ce qui a rendu cela exploitable : pointer des agents vers des tickets GitHub, des tickets de support, des e-mails ou des messages clients, et laisser ces agents déclencher des automatisations en aval. Si un maillon de cette chaîne peut atteindre des secrets de production, déployer du code ou approuver une modification, alors du texte non fiable dispose d'un chemin vers une action privilégiée. La version inconfortable de la question est simple : si un attaquant peut écrire dans votre système, quelle est l'action la plus privilégiée qu'un agent pourrait être amené à exécuter en son nom ?
Pour les secteurs réglementés, les enjeux sont concrets. En FinTech, paiements et santé, l'accès non autorisé et l'intégrité du contrôle des changements sont des obligations d'audit sous des cadres tels que SOC 2, DORA et le règlement européen sur l'IA, et « un agent IA l'a fait » n'est pas une défense lorsque l'agent détenait une clé de compte de service. La difficulté supplémentaire est l'auditabilité : les actions pilotées par des agents peuvent ressembler à une activité ordinaire de bot, de sorte qu'un commentaire ayant déclenché un job privilégié peut ne pas se distinguer dans vos journaux. Traiter la sortie des agents — commentaires, revues, déclenchements de workflows — comme des événements de sécurité, et valider le comportement des agents avec la même rigueur que vous appliquez à un audit de sécurité de toute automatisation privilégiée, fait désormais partie du déploiement responsable d'agents.
Marché français : En France, l'ANSSI (Agence nationale de la sécurité des systèmes d'information) recommande depuis 2024 d'appliquer le principe de moindre privilège aux pipelines de déploiement automatisé, y compris les workflows GitHub Actions. La transposition de la directive NIS 2 en droit français (attendue en 2024-2025) introduit des obligations de sécurité de la chaîne d'approvisionnement logicielle pour les entités essentielles — ce qui inclut les pipelines CI/CD connectés à des environnements de production. L'attaque contre l'ADK de Google illustre exactement le type de vecteur que l'ANSSI classe sous « risques liés aux tiers et à l'automatisation » : une chaîne d'agents où une entrée non maîtrisée peut déclencher une action hautement privilégiée sans intervention humaine.
Comment renforcer un système multi-agents
Il n'est pas nécessaire de démanteler l'automatisation agentique pour répondre à ce problème. Il faut simplement arrêter de laisser un agent lisant des données non fiables emprunter silencieusement les privilèges d'un agent qui n'en lit pas.
- Isoler les agents de données non fiables. Tout agent qui lit des tickets, e-mails ou PR provenant de l'extérieur de votre périmètre de confiance est lui-même non fiable — ne laissez jamais sa sortie invoquer automatiquement un agent ou un workflow plus privilégié.
- Cartographier l'autorité transitive. Schématisez quels agents peuvent déclencher quels jobs, et calculez la capacité effective maximale de chaque identifiant dans la chaîne, pas seulement celui qu'un agent détient directement.
- Maintenir les secrets hors des chemins non fiables. Les clés de compte de service, les clés API et les jetons d'accès personnels ne doivent pas figurer dans un job que des données anonymes peuvent atteindre ; limitez la portée de chaque jeton au strict nécessaire.
- Exiger une validation humaine ou une porte signée pour les actions privilégiées. Les déploiements, fusions et accès aux secrets pilotés par un agent doivent exiger une approbation hors bande que du texte non fiable ne peut pas forger.
- Lier les approbations au code exact examiné. Si le matériel examiné change après approbation, invalidez-la — une approbation pour un diff ne doit pas s'appliquer à un autre.
- Journaliser les actions des agents comme des événements de sécurité. Traitez les commentaires, revues et déclenchements de workflows générés par des agents comme des événements auditables avec journalisation indépendante, afin qu'un déclenchement malveillant soit visible plutôt que noyé dans le bruit des bots.
Le signal stratégique issu des travaux de Pillar est précis et utile : l'automatisation multi-agents déplace le risque des permissions d'un agent individuel vers la permission la plus élevée accessible dans toute la chaîne. Les équipes qui conçoivent en tenant compte de cela — en isolant les lecteurs non fiables, en contrôlant les actions privilégiées, et en surveillant la sortie des agents comme elles surveillent les actions humaines — bénéficient de l'effet de levier de la livraison agentique sans ouvrir à des inconnus anonymes une voie vers leurs secrets de production.
Questions fréquentes
Qu'a découvert Pillar Security dans le dépôt ADK de Google ?
Pillar Security a découvert que l'automatisation multi-agents du dépôt open source Agent Development Kit (ADK) de Google pour Python pouvait être retournée contre elle-même. Un ticket ou un commentaire GitHub public, rédigé par n'importe qui, pouvait injecter des instructions malveillantes dans un agent de triage à faibles privilèges exposé sur Internet, le poussant à invoquer à sa place un agent de correction de code à hauts privilèges. Les chercheurs ont démontré une exécution de code arbitraire sur le runner CI et l'exfiltration du jeton d'accès personnel adk-bot, tandis que le job privilégié détenait également une clé API Google et un identifiant de compte de service Google Cloud. Pillar a qualifié cette découverte de premier cas pratique et réel d'exploitation agent-à-agent dans un système multi-agents en production.
Comment l'attaque agent-à-agent a-t-elle fonctionné ?
L'attaque débutait dans un workflow public issue-analyze.yml qui se déclenchait automatiquement à chaque ouverture d'un ticket GitHub. Ce workflow s'authentifiait avec une clé de compte de service Google Cloud et transmettait un agent de triage et une clé API Google à l'agent de codage Antigravity de Google. Comme l'agent de triage lisait le texte du ticket contrôlé par l'attaquant comme des instructions, il pouvait être manipulé pour publier un commentaire déclencheur (tel que /adk-issue-fix) en tant qu'adk-bot, ce qui lançait le workflow de correction privilégié. Un agent à faibles privilèges consommant uniquement du contenu non fiable pouvait ainsi franchir une frontière de confiance et piloter un agent à hauts privilèges disposant d'accès aux secrets et au runner CI.
La faille Google ADK a-t-elle été corrigée ?
Oui. Google a supprimé les workflows vulnérables du dépôt ADK pour Python. Pillar a confirmé que les workflows concernés ont été retirés le 2 juillet 2026, et Google a confirmé un correctif pour le second problème le 21 juillet 2026. Les conclusions ont été rendues publiques début août 2026. Les automatisations supprimées étaient liées au propre dépôt de Google, de sorte que l'exposition immédiate concernait ce projet plutôt que les applications construites avec l'ADK, mais le schéma de conception qui a rendu l'attaque possible est répandu dans les systèmes multi-agents.
Cela signifie-t-il que les agents de codage IA sont dangereux à utiliser ?
Non. Le problème n'est pas que les agents sont intrinsèquement dangereux, mais qu'un agent à faibles privilèges consommant des données non fiables a pu déclencher un agent à hauts privilèges détenant des secrets, sans frontière imposant le principe de moindre privilège entre eux. L'automatisation agentique reste utile pour le triage, la revue de code et la remédiation. La leçon est que l'autorité réelle d'un agent inclut chaque action plus privilégiée que sa sortie peut déclencher, de sorte que ces chemins transitifs doivent être cartographiés, isolés et surveillés plutôt que supposés sûrs.
Comment les équipes qui construisent des systèmes multi-agents peuvent-elles se défendre contre ce type d'attaque ?
Traitez tout agent lisant du contenu non fiable comme entièrement non fiable lui-même, et ne laissez jamais sa sortie invoquer automatiquement un agent ou un workflow plus privilégié. Cartographiez les flux d'autorité transitifs entre les agents afin de connaître la capacité effective maximale de chaque identifiant dans la chaîne. Maintenez les secrets tels que les clés de compte de service et les jetons d'accès personnels à l'écart des jobs que les entrées non fiables peuvent atteindre, et limitez la portée de chaque jeton au strict nécessaire. Liez les approbations au code exact examiné et invalidez-les si le matériel change, et journalisez les commentaires, revues et déclenchements de workflows pilotés par des agents comme des événements de sécurité.
Sources
The Hacker News — Google supprime 3 workflows IA après qu'un ticket GitHub a pu déclencher un agent privilégié
The Register — Le kit de développement Google provoque la première attaque agent contre agent
CSO Online — Les failles ADK de Google révèlent ce qui se passe quand les agents IA font confiance au mauvais message