Les failles dans les agents de codage IA commencent à devenir un véritable enjeu de cybersécurité. Une recherche menée par Elad Meged, chercheur en sécurité chez Novee Security, met en évidence une classe de vulnérabilités touchant des workflows utilisant Claude Code d’Anthropic, Gemini CLI de Google et Codex d’OpenAI.
Le problème ne provient pas directement des modèles d’intelligence artificielle. Il se situe plutôt dans leur « harnais » de sécurité, c’est-à-dire l’ensemble des mécanismes qui contrôlent les outils auxquels l’agent peut accéder, l’exécution des commandes, les fichiers manipulés et le niveau de confiance accordé au contenu provenant du dépôt.
Présentée lors de Black Hat USA 2026, la recherche montre que des erreurs dans les transitions de confiance entre différentes étapes d’un workflow peuvent permettre à du contenu contrôlé par un attaquant d’atteindre un environnement disposant de privilèges élevés.
La présentation de Novee Security sur les agents IA
Le véritable problème : le transfert de confiance
Dans un workflow de développement automatisé, un agent IA peut analyser une issue GitHub, examiner une pull request, modifier du code, lancer des commandes ou participer à un processus CI/CD.
Cette automatisation crée cependant plusieurs frontières de confiance.
Un fichier ou une instruction provenant d’un dépôt peut être considéré comme du contenu légitime par une première étape, puis être réutilisé par une seconde étape bénéficiant de privilèges plus importants.
C’est précisément cette situation que Novee décrit comme un « trust handoff », ou transfert de confiance : une composante considère une donnée comme sûre alors qu’une autre lui accorde ensuite davantage de privilèges.
Selon la présentation de la recherche, ce mécanisme peut transformer un contenu initialement non privilégié en vecteur d’exécution de code à distance, de vol de secrets ou de compromission de la chaîne logicielle.
Claude Code : plusieurs chemins vers l’exécution ou l’exfiltration
Le dépôt public de Claude Code d’Anthropic a fait partie des environnements étudiés.
Les chercheurs ont notamment identifié des problèmes liés à la manière dont les commandes sont validées avant leur exécution. Une première chaîne exploitait une différence entre la validation effectuée par l’agent et l’interprétation réelle de certaines commandes par le shell.
Après la correction initiale, d’autres mécanismes permettant de contourner certaines protections ont été étudiés.
Un élément particulièrement important concerne CVE-2026-54316. La base de données du NIST décrit cette vulnérabilité comme liée à l’autorisation automatique de chemins sur huggingface.co dans l’outil WebFetch de Claude Code. Les versions concernées vont de 0.2.54 jusqu’à avant 2.1.163.
Cette vulnérabilité montre qu’un domaine considéré comme fiable peut devenir un problème lorsque des ressources contrôlées par des tiers sont accessibles sans demander une nouvelle autorisation.
Gemini CLI : une vulnérabilité CVSS 10.0
Le cas de Gemini CLI est particulièrement préoccupant.
Google a corrigé une vulnérabilité critique évaluée à CVSS 10.0, affectant Gemini CLI ainsi que l’action GitHub run-gemini-cli. Le problème concernait notamment la manière dont l’outil gérait la confiance accordée au répertoire de travail dans les environnements non interactifs, notamment les pipelines CI/CD.
Dans certaines configurations vulnérables, un contenu contrôlé par un attaquant pouvait être interprété comme une configuration de confiance. Le processus pouvait alors conduire à l’exécution de commandes sur l’hôte avant même que les mécanismes de sandboxing prévus par l’agent ne soient correctement établis.
Les versions vulnérables de Gemini CLI étaient notamment antérieures à 0.39.1, tandis que plusieurs versions de l’action GitHub étaient également concernées. Google a introduit des changements importants dans son modèle de confiance et recommande l’utilisation des versions corrigées.
Avis de sécurité Novee sur Gemini CLI
Codex : le risque lié aux fichiers d’instructions
Le cas de Codex, l’agent de codage d’OpenAI, illustre une autre dimension du problème : les fichiers d’instructions utilisés pour guider les agents.
Les fichiers AGENTS.md peuvent contenir des informations destinées à expliquer à l’agent comment travailler avec un dépôt. Ils constituent donc une source de contexte particulièrement importante pour les agents de développement.
La recherche présentée par Novee montre cependant qu’un workflow utilisant plusieurs étapes d’agent peut devenir vulnérable lorsque ces étapes partagent le même espace de travail.
Un attaquant capable de modifier un fichier d’instructions lors d’une première étape peut potentiellement influencer le comportement d’une étape ultérieure si celle-ci fait confiance au contenu précédemment écrit.
Le dépôt public de Codex contient lui-même un fichier AGENTS.md, ce qui illustre l’importance de ces fichiers dans l’écosystème des agents de développement.
Dépôt officiel Codex sur GitHub
Une menace qui dépasse les trois géants de l’IA
L’un des enseignements majeurs de cette recherche est que le problème ne serait pas limité à Anthropic, Google ou OpenAI.
Les chercheurs indiquent avoir retrouvé des mécanismes similaires dans plus d’une centaine de dépôts publics.
Cela signifie que la vulnérabilité potentielle ne dépend pas uniquement du modèle utilisé. Elle dépend surtout de la manière dont l’agent est intégré au système de développement.
Un agent disposant d’un accès au dépôt, au shell, aux secrets CI/CD ou aux services cloud représente une nouvelle surface d’attaque qui doit être traitée comme une composante de l’infrastructure de sécurité.
Pourquoi les chaînes CI/CD sont particulièrement exposées
Le risque est encore plus important lorsque les agents sont exécutés automatiquement.
Dans un pipeline classique, une pull request provenant d’un contributeur externe peut déclencher différentes opérations. Si un agent IA intervient ensuite pour analyser le code, corriger un problème ou générer une modification, il peut être exposé à du contenu contrôlé par l’auteur de la pull request.
Le problème apparaît lorsque l’agent possède parallèlement :
- des accès au dépôt ;
- des jetons CI/CD ;
- des secrets injectés dans l’environnement ;
- des permissions d’écriture ;
- un accès au système de fichiers ;
- ou la possibilité d’exécuter des commandes.
Une compromission peut alors dépasser le simple dépôt concerné et devenir une attaque de la chaîne d’approvisionnement logicielle.
La Cloud Security Alliance souligne justement que les agents de codage exécutés dans les pipelines CI/CD constituent désormais une surface d’attaque importante et que la vulnérabilité de Gemini CLI représente une manifestation particulièrement grave de cette tendance.
Le modèle n’est pas toujours le maillon faible
Cette recherche remet également en question une idée très répandue concernant la sécurité des agents IA.
Il serait tentant de considérer qu’il suffit d’améliorer les garde-fous du modèle pour empêcher une attaque. Or, les chercheurs montrent que certaines vulnérabilités apparaissent en dehors du modèle.
Le modèle peut respecter ses règles de sécurité tandis que le système qui l’entoure accorde malgré tout trop de confiance à une donnée externe.
Le véritable périmètre de sécurité devient donc l’ensemble constitué par :
modèle IA + outils + système de fichiers + sandbox + CI/CD + secrets + permissions.
Cette évolution oblige les entreprises à auditer non seulement le comportement du modèle, mais également tout le harness qui permet à l’agent d’interagir avec l’environnement.
Quelles mesures pour réduire les risques ?
Les organisations utilisant Claude Code, Gemini CLI, Codex ou d’autres agents autonomes devraient notamment :
- maintenir les agents et leurs extensions à jour ;
- éviter de donner des privilèges inutiles aux agents ;
- isoler les tâches provenant de contenus non fiables ;
- limiter l’accès aux secrets CI/CD ;
- séparer les différentes étapes d’un workflow lorsque leurs niveaux de privilège sont différents ;
- considérer les fichiers générés par un agent comme des données potentiellement non fiables ;
- surveiller les commandes exécutées par les agents ;
- contrôler strictement les accès réseau ;
- utiliser des environnements éphémères et isolés pour les tâches provenant de pull requests externes ;
- effectuer régulièrement des audits de sécurité des workflows automatisés.
L’objectif n’est pas nécessairement de supprimer l’automatisation, mais de ne jamais laisser un contenu non fiable franchir automatiquement une frontière de privilège.
Une nouvelle surface d’attaque pour la cybersécurité
La montée en puissance des agents de codage transforme progressivement les environnements de développement en nouvelles surfaces d’attaque.
Les incidents étudiés par Novee montrent surtout qu’un agent IA disposant de capacités d’exécution et intégré directement à une chaîne CI/CD doit être considéré comme un composant privilégié de l’infrastructure.
Les entreprises devront donc adapter leurs modèles de sécurité à cette nouvelle réalité. La question n’est plus seulement de savoir si un modèle est suffisamment sécurisé, mais aussi de déterminer qui peut influencer l’agent, quelles données il considère comme fiables et quels privilèges il conserve lorsqu’il agit automatiquement.
À mesure que les agents IA prennent une place croissante dans le développement logiciel, ces frontières de confiance pourraient devenir l’un des nouveaux champs de bataille majeurs de la cybersécurité.
