Ils ont kidnappé des agents d’Anthropic, Google et Microsoft au nom de la science. Les trois sociétés ont fini par payer

Dans certaines équipes de développement, il est déjà courant de s’appuyer sur des agents d’intelligence artificielle pour examiner les incidents, analyser les modifications du code et accomplir des tâches qui étaient auparavant laissées entre des mains humaines. Le problème apparaît lorsque ces systèmes non seulement lisent des informations pouvant provenir de l’extérieur, mais fonctionnent également dans des espaces où coexistent des clés, des jetons et des autorisations sensibles. C’est ce que mettent sur la table des recherches récentes : nous ne sommes pas simplement confrontés à un outil utile qui peut commettre des erreurs, mais plutôt à une architecture qui peut aussi devenir dangereuse si elle est déployée sans limites très claires.

L’alarme a été tirée par Zhengyu Liu et Gavin Zhong, chercheurs d’Aonan Guan et de Johns Hopkins, après avoir démontré des attaques contre trois agents déployés sur la plateforme susmentionnée : Claude Code Security Review, d’Anthropic, Gemini CLI Action, de Google, et GitHub Copilot Agent, un outil GitHub sous Microsoft. Selon leurs documents, les échecs ont été signalés de manière coordonnée et ont abouti à des récompenses financières versées par les entreprises, mais ce qui est pertinent, c’est qu’ils mettent en évidence un problème plus large.

C’est ainsi qu’ils ont réussi à détourner les agents de l’intérieur

Le nom que Guan donne à la découverte aide beaucoup à comprendre de quoi il s’agit : « Commentaire et Contrôle ». L’idée est simple à expliquer, même si le fond n’est pas si simple. Au lieu de mettre en place une infrastructure externe pour diriger l’attaque, GitHub lui-même agit comme un canal d’entrée et de sortie : l’attaquant laisse l’instruction dans un titre, un problème ou un commentaire, l’agent la traite comme si elle faisait partie d’un travail normal et le résultat finit par réapparaître dans ce même environnement. Tout reste à la maison, et c’est justement la clé du problème.

Et que « tout reste à la maison » n’est pas un détail mineur, mais la base de ce que décrit la recherche. Les trois agents partagent une logique très similaire : ils lisent le contenu normal de GitHub, l’intègrent comme contexte de travail et à partir de là, exécutent des actions au sein de flux automatisés. Le conflit apparaît parce que ce même espace contient non seulement du texte envoyé par des tiers, mais également des outils, des autorisations et des secrets dont l’agent a besoin pour fonctionner.

Le premier cas détaillé par Guan concerne Claude Code Security Review, une action Anthropic GitHub conçue pour examiner les modifications du code et rechercher d’éventuelles failles de sécurité. Jusqu’à présent, tout est conforme à ce qui était attendu. Le problème, comme l’explique le chercheur, est qu’il suffisait d’introduire des instructions malveillantes dans le titre d’un , qui est la demande que quelqu’un envoie pour proposer des modifications à un projet, pour que l’agent exécute des commandes et renvoie le résultat comme s’il faisait partie de sa révision. L’équipe est ensuite parvenue à aller plus loin et à démontrer qu’elle pouvait également extraire des informations d’identification de l’environnement.

Ce qui est intéressant, c’est que le même schéma est également apparu dans les deux autres services, mais avec des nuances. Chez Google, Gemini CLI Action pourrait être poussé à révéler le GEMINI_API_KEY à partir d’instructions glissées dans un problème et ses commentaires ; Dans GitHub Copilot Agent, la variante était encore plus inquiétante, car l’attaque était cachée dans un commentaire HTML qu’une personne ne voyait pas à l’écran, mais l’agent l’a traité lorsqu’une autre personne l’a assigné au cas. Dans les deux scénarios, l’arrière-plan était à nouveau le même : un contenu apparemment normal qui a fini par déformer le comportement du système jusqu’à exposer des informations d’identification ou des informations sensibles au sein même de GitHub.

Guan assure que le modèle a permis de divulguer des clés API, des jetons GitHub et d’autres secrets exposés dans l’environnement où l’agent s’exécutait, c’est-à-dire uniquement les informations d’identification qui peuvent ensuite ouvrir la porte à des actions beaucoup plus délicates. Qui est-ce que cela affecte ? Surtout aux référentiels qui exécutent des agents dans GitHub Actions sur le contenu soumis par des collaborateurs peu fiables et, en plus, leur donnent accès à des secrets ou à des outils puissants. Le chercheur lui-même précise que le risque dépend beaucoup de la configuration : par défaut, GitHub n’expose aucun secret depuis, mais il existe des déploiements qui ouvrent cette porte.

Et ici apparaît un autre aspect du problème, moins technique mais tout aussi important. Selon The Register, Anthropic, Google et GitHub ont fini par payer des récompenses pour leurs découvertes, mais aucun des trois n’avait publié d’avis public ni attribué de CVE au moment de cette information. Guan a été très clair à ce sujet : il a déclaré qu’il savait « avec certitude » que certains utilisateurs étaient toujours bloqués sur des versions vulnérables et a averti que, sans communication visible, beaucoup ne sauraient jamais qu’ils étaient exposés ou même attaqués. Ainsi, bien qu’il y ait eu des atténuations et des changements dans la documentation ou dans le traitement interne des rapports, il n’y a pas eu d’avis public équivalent pour toutes les personnes potentiellement concernées.

• Anthropic a réglé l’affaire le 25 novembre 2025 et a payé 100 $
• Google a récompensé la découverte le 20 janvier 2026 avec 1 337 $
• GitHub a clôturé le dossier le 9 mars 2026 avec un paiement de 500 $

Ce qui rend ce cas particulièrement délicat, c’est que GitHub ne semble pas être le bout du chemin, mais plutôt la première vitrine visible. Guan soutient que le même schéma peut probablement être reproduit dans d’autres agents qui travaillent avec des outils et des secrets au sein de flux automatiques, et il y mentionne tout, des robots connectés à Slack aux agents Jira, en passant par la messagerie ou l’automatisation du déploiement. La logique est à nouveau la même : si le système doit lire du contenu externe pour faire son travail et dispose également d’un accès suffisant pour agir, le terrain est fertile pour que quelqu’un tente de le déformer de l’intérieur.

La conclusion à laquelle Guan arrive ne consiste pas à vendre une solution magique, mais à revenir à une idée assez classique en matière de sécurité : donner à chaque système uniquement ce qui est essentiel pour faire son travail. Si un agent examine le code, il ne devrait pas avoir accès aux outils ou aux secrets dont il n’a pas besoin ; Si vous résumez simplement les problèmes, cela n’aurait aucun sens pour vous d’écrire sur GitHub ou de toucher des informations d’identification sensibles. C’est pourquoi il insiste pour penser ces déploiements avec une logique de moindre privilège et des listes d’autorisations très fermées.

Images | DC Studio | Aonan Guan

À Simseo | L’IA est cruciale pour l’armée américaine. Il nomme donc les dirigeants d’OpenAI et de Palantir comme lieutenants généraux