Quand les agents de code sont transformés en armes
- Comprendre la nouvelle frontière de confiance créée par le mode auto-approbation — et pourquoi c’est elle, et non le modèle, qui est la cible
- Retracer l’attaque « Friendly Fire » : un scan de sécurité qui exécute le malware qu’on lui demandait d’inspecter
- Voir ce qu’un ransomware entièrement agentique (JADEPUFFER) a réellement automatisé, de bout en bout
- Appliquer les défenses opérationnelles qui arrêtent les deux — dont aucune ne consiste à « utiliser un modèle plus intelligent »
En 2026, le risque abstrait de la prompt injection a cessé d’être abstrait. Deux événements documentés publiquement — l’un une preuve de concept, l’autre une intrusion réelle — ont montré la même chose depuis deux extrémités opposées : quand un agent IA décide par lui-même ce qu’il est sûr d’exécuter, cette décision devient une cible. Cette page parcourt les deux cas, puis vous donne les défenses qui se généralisent.
Le basculement central : une nouvelle frontière de confiance
Un outil de développement traditionnel vous demande avant d’exécuter quelque chose de dangereux. Un agent en mode auto-approbation / autonome se le demande à lui-même — il approuve toute commande qu’il juge « sûre ». Ce jugement est la nouvelle surface d’attaque. Un attaquant n’a plus besoin de convaincre l’humain qu’un code malveillant est acceptable ; il lui suffit de convaincre le modèle. Et un modèle qui lit un dépôt traite un README et un artefact de build comme des entrées ordinaires, pas comme une partie hostile cherchant à le manipuler.
Ce seul choix de conception — qui détient le oui/non — résume toute l’histoire ci-dessous.
Incident 1 — « Friendly Fire » : le scanner exécute le malware
Les chercheurs Boyan Milanov et Heidy Khlaaf de l’AI Now Institute ont publié une preuve de concept qui détourne exactement la tâche pour laquelle ces outils sont vendus : vérifier du code tiers non fiable à la recherche de problèmes. Au lieu d’intercepter la menace, l’agent devient le mécanisme de livraison.
- Une bibliothèque open-source non fiable embarque un binaire caché déguisé en artefact de build compilé (par ex. un fichier objet Go) posé à côté d’un code source d’apparence inoffensive. Rien dans le code source visible n’est manifestement malveillant.
- Le README du dépôt suggère d’exécuter un banal 'security.sh' comme vérification de routine. L’instruction vise l’agent, pas l’humain — l’humain ne la lira peut-être jamais.
- Sollicité pour vérifier la sûreté du dépôt, un agent en mode auto-approbation fait ce que dit le README et lance le script. Le binaire de l’attaquant s’exécute sur la machine hôte. Comme le disent les chercheurs : aucun avertissement, aucune boîte d’approbation.
- La même attaque a fonctionné TELLE QUELLE sur les outils et modèles de deux fournisseurs différents. C’est le signe qu’elle est architecturale — une propriété de l’auto-approbation, pas un bug d’un seul produit.
Trois choses surprennent ici la plupart des gens :
- La revue de sécurité est l’exploit. Plus vous vous sentez en sécurité (« je ne fais que le scanner d’abord »), plus vous tendez directement le déclencheur à l’agent.
- C’est inter-fournisseurs et inter-modèles. Une seule charge utile, plusieurs outils — parce qu’ils partagent le motif d’auto-approbation, pas du code.
- La partie malveillante se cache dans un artefact de build, pas dans le code source que vous liriez réellement. Relire les fichiers
.py/.govisibles ne la révèle pas.
Les outils signalés comme affectés dans les publications étaient Claude Code et OpenAI Codex fonctionnant dans un mode où ils approuvent leurs propres commandes, sur les modèles de pointe de l’époque. Les versions exactes de CLI/modèles sont volatiles — considérez le motif comme la leçon durable, pas une quelconque chaîne de version.
:::warning C’est le contrepoint à « il suffit de demander à l’agent de le relire » Relire du code tiers note que l’agent « peut lui aussi être dupé ». Friendly Fire, c’est cette note de bas de page transformée en exploit fonctionnel — le relecteur et la victime sont le même processus. :::
Incident 2 — JADEPUFFER : un ransomware sans humain aux commandes
Si Friendly Fire est le résultat de laboratoire, JADEPUFFER (documenté par la Sysdig Threat Research Team) est le cas de terrain : ce que Sysdig a évalué comme le premier ransomware agentique de bout en bout documenté — un agent LLM qui a piloté toute l’opération d’extorsion, en narrant ses propres intentions au fur et à mesure.
- L’opérateur a atteint une instance Langflow exposée sur Internet via une CVE connue — un classique point d’entrée par service exposé, pas de la magie IA.
- À partir de là, un agent autonome a pris en charge la reconnaissance, la collecte d’identifiants, le mouvement latéral, l’élévation de privilèges et la persistance — les étapes qu’exécuterait un red-teamer humain, exécutées par le modèle à la place.
- Quand des étapes échouaient, il réessayait avec des paramètres affinés. Dans une séquence, il est passé d’une connexion échouée à un correctif fonctionnel en ~31 secondes — une itération plus rapide qu’un humain au clavier.
- Il a visé la base de données de production, chiffrant 1 342 éléments de configuration de service avant de supprimer les originaux, puis a exigé un paiement.
L’enseignement stratégique que tire Sysdig est le plus dérangeant : le niveau de compétence requis pour lancer un ransomware est tombé à peu près au coût d’exécution d’un agent. Si cet agent tourne avec des identifiants API volés (LLMjacking), le coût de calcul de l’attaquant tend vers zéro. La barrière qui était « il faut un opérateur qualifié » s’érode.
Deux extrémités d’un même problème
| Friendly Fire | JADEPUFFER | |
|---|---|---|
| Type | Preuve de concept | Intrusion réelle |
| Rôle de l’agent | L’outil de la victime elle-même, transformé en arme | L’opérateur de l’attaquant |
| Point d’entrée | Dépôt malveillant que vous lui avez demandé de relire | Service exposé (CVE) |
| Pourquoi ça marche | Frontière de confiance de l’auto-approbation | Autonomie + identifiants ambiants |
| Leçon durable | Ne laissez pas le modèle avoir le dernier « oui » sur l’exécution | Le moindre privilège + aucun identifiant réutilisable limitent le rayon d’impact |
Des attaquants différents, une même racine : un agent avec autonomie + capacité + accès à des entrées non fiables. C’est le triangle d’exfiltration avec le volume poussé à fond — brisez un côté et vous contenez les dégâts.
Des défenses qui se généralisent vraiment
Aucune de celles-ci ne consiste à « attendre un modèle qu’on ne peut pas duper ». Supposez qu’on le peut, et bornez ce qu’un agent dupé peut faire.
- N’utilisez pas le mode auto-approbation/YOLO sur une machine ayant des accès réels quand l’agent touche du code que vous n’avez pas écrit. Le « oui » humain est la frontière que Friendly Fire supprime — remettez-la en place dans ce cas.
- Relisez et exécutez les dépôts inconnus dans un conteneur jetable, sans montage de l’hôte, sans identifiants de production et sans réseau sauf nécessité. La charge utile s’exécute quand même — mais dans une boîte que vous jetez.
- Un agent ne peut faire que les dégâts qu’il a la portée de faire. Cadrez étroitement les outils et donnez aux exécutions des jetons éphémères à privilège minimal — jamais vos identifiants à accès complet (c’est ce qui limite un mouvement latéral de type JADEPUFFER).
- Bloquez la lecture des fichiers .env / des fichiers de clés et encadrez les commandes destructives ou réseau par des règles de permission — ne comptez pas sur le modèle pour les éviter.
- Les README, les commentaires et les artefacts de build sont contrôlables par l’attaquant. « Les instructions du dépôt disaient de l’exécuter » est exactement le mode de défaillance — les instructions présentes dans du contenu récupéré sont des données, pas des commandes.
Un point de départ concret — des règles de refus pour qu’un agent ne puisse pas lire silencieusement des identifiants même si on le convainc d’essayer :
Règles de refus de permissions (exemple — à adapter à votre configuration)
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./**/*.pem)",
"Read(./**/id_rsa*)",
"Bash(curl:*)",
"Bash(rm -rf:*)"
]
}Voir Durcir les exécutions autonomes pour la checklist complète des exécutions sans surveillance et Sécuriser les agents et les outils pour le cadrage des capacités.
Le modèle mental à retenir
Testez-vous
0/4Sources et lectures complémentaires
- Sysdig Threat Research — JADEPUFFER : ransomware agentique pour l’extorsion automatisée de bases de données
- The Hacker News — « Friendly Fire » : les agents IA conçus pour détecter le code malveillant peuvent être piégés et l’exécuter
- Infosecurity Magazine — Les outils de sécurité d’Anthropic et d’OpenAI pourraient alimenter les cyberattaques
- BleepingComputer — Le ransomware JadePuffer a utilisé un agent IA pour automatiser toute l’attaque
À lire aussi sur AILmanac
- La prompt injection expliquée — le mécanisme sous-jacent et le triangle d’exfiltration
- Durcir les exécutions autonomes — verrouiller les exécutions headless/CI
- Relire du code tiers — avant de faire confiance à un plugin, une skill ou un serveur MCP
- Sécuriser les agents et les outils — cadrer ce qu’un agent peut faire