L'agent IA chargé d'auditer du code tiers exécute l'attaque

Beaucoup d'équipes ont adopté un réflexe rassurant. Avant d'intégrer une bibliothèque open source, elles demandent à un agent de code de la relire, de repérer les dépendances douteuses et de signaler ce qui sent le piège. Sur le papier, c'est une bonne pratique. Un travail publié le 8 juillet 2026 par l'AI Now Institute montre que ce réflexe peut se retourner contre celui qui l'applique.

Ce que démontre Friendly Fire

Les chercheurs Boyan Milanov et Heidy Khlaaf, de l'AI Now Institute, ont publié une preuve de concept nommée « Friendly Fire »¹. Le principe tient en une phrase : un agent de code à qui l'on demande d'auditer une bibliothèque non fiable finit par exécuter, sur la machine hôte, le code que l'attaquant voulait justement faire tourner. L'agent censé trouver la charge malveillante la lance lui-même.

La démonstration cible deux outils largement utilisés. Claude Code en « auto-mode » avec les modèles Sonnet 4.6, Sonnet 5 et Opus 4.8, et le CLI Codex d'OpenAI en « auto-review » avec GPT-5.5². Aucune configuration exotique n'est requise. L'attaque fonctionne sur une installation standard, sans hook, sans plugin, sans serveur MCP ajouté comme vecteur.

Le montage est instructif. Les auteurs sont partis de geopy, une bibliothèque de géocodage Python parfaitement légitime. Ils y ont glissé quatre éléments : un binaire précompilé baptisé code_policies déguisé en outil d'analyse statique, un fichier leurre code_policies.go pour faire croire que ce binaire a été compilé à partir de sources anodines, un script security.sh qui appelle des outils de sécurité courants, et un README modifié contenant une injection de prompt. Le texte caché dans la documentation demande à l'agent de considérer que le binaire fait partie de l'outillage de revue et qu'il faut donc l'exécuter.

Pourquoi les garde-fous n'ont pas tenu

Le classificateur de code des deux agents a jugé la charge inoffensive. Le couple binaire compilé plus fichier source d'apparence honnête a suffi à tromper les heuristiques de correspondance. Une fois cette confiance obtenue, l'injection de prompt dans le README a orienté l'agent : pour mener sa revue de sécurité, il lui « fallait » lancer code_policies. Les deux outils s'y sont pliés.

Ce qui doit retenir l'attention d'un responsable technique tient surtout à la transférabilité de l'attaque. Le montage conçu contre Claude Code a fonctionné sur Codex sans la moindre modification. Les auteurs en tirent une conclusion sobre : la faiblesse tient à la façon dont les modèles de frontière séparent les instructions de confiance des données non fiables, pas à un bug propre à un produit. Autrement dit, changer d'agent ne règle rien.

Nous avions déjà noté que le code produit par une IA passe la revue fonctionnelle bien plus facilement que la revue de sécurité. Friendly Fire déplace le problème d'un cran. Le doute ne porte plus sur le code généré, mais sur l'agent lui-même, transformé en exécutant à son insu.

Un contexte de juillet déjà tendu

Cet épisode ne sort pas de nulle part. Quelques semaines plus tôt, Wiz Research a documenté la faille CVE-2026-12957 dans Amazon Q Developer, notée 8,5 sur l'échelle CVSS³. L'extension chargeait et exécutait automatiquement un fichier de configuration MCP déposé dans un dépôt, sans demander l'accord du développeur. Il suffisait de cloner un projet piégé pour que les processus lancés héritent des clés AWS, des jetons cloud et des sockets SSH de la machine. Amazon a corrigé le défaut à partir de la version 1.65.0 des Language Servers, puis recommandé la 1.69.0 pour une protection plus complète. Aucune exploitation publique n'a été recensée à ce jour, selon Wiz.

Le fil rouge est le même dans les deux cas. Un dépôt tiers, considéré comme une simple donnée à analyser, devient une source d'instructions que l'outil finit par suivre.

Notre lecture

Pour une PME ou une ETI qui outille ses équipes avec un agent de code, la recommandation des chercheurs est claire et applicable dès maintenant : ne pas confier à un agent disposant de droits d'exécution l'analyse d'un code externe non vérifié. Tant que la frontière entre instruction et donnée reste poreuse dans les modèles, cette prudence vaut mieux qu'une confiance par défaut.

Concrètement, quelques mesures réduisent l'exposition sans bloquer les usages. Faites tourner les revues de code tiers dans un conteneur jetable, sans clé cloud ni identifiant en variables d'environnement. Coupez l'exécution automatique quand la cible n'est pas maîtrisée, et gardez la validation manuelle pour tout ce qui provient de l'extérieur. Traitez l'agent comme un collaborateur à qui l'on n'ouvre pas tous les accès le premier jour.

Le gain de productivité des agents de code reste réel, et nous continuons de les utiliser au quotidien. Friendly Fire rappelle simplement une limite : un outil qui lit du texte non fiable et qui peut lancer des commandes mélange deux fonctions qui, en sécurité, devraient rester séparées. Le sujet ne concerne plus seulement les équipes sécurité. Il touche tout responsable qui a mis un agent entre les mains de ses développeurs.

Sources

• AI Now Institute, Friendly Fire: Hijacking Defensive Cyber AI Agents for Remote Code Execution : https://ainowinstitute.org/publications/friendly-fire-exploit-brief
• Dépôt de la preuve de concept (Boyan Milanov, Heidy Khlaaf) : https://github.com/Boyan-MILANOV/friendly-fire-ai-agent-exploit
• The Hacker News, Top AI Agents Built to Catch Malicious Code Can Be Tricked Into Running It : https://thehackernews.com/2026/07/friendly-fire-ai-agents-built-to-catch.html
• Wiz Blog, Amazon Q Vulnerability: Compromise via MCP Auto-Execution (CVE-2026-12957) : https://www.wiz.io/blog/amazon-q-vulnerability
• The Register, Amazon Q flaw let booby-trapped Git repos execute code : https://www.theregister.com/cyber-crime/2026/06/26/amazon-q-flaw-let-booby-trapped-git-repos-execute-code-swipe-cloud-creds/5263202