Quand un agent de code veut lancer une commande, il te demande l'autorisation. Tu regardes, tu approuves, tu continues. C'est le garde-fou standard de tous les outils du marché, et on te le présente comme la dernière ligne de défense.
Un développeur belge a mesuré ce que vaut cette ligne de défense. Dans son test, les joueurs laissaient passer environ une menace sur trois. Et le détail le plus embarrassant, c'est que la commande la plus ratée du lot affichait son code malveillant à l'écran, juste au-dessus du bouton d'approbation.
Ce que j'en retiens en une phrase : le problème n'est pas que les développeurs manquent de vigilance, c'est qu'on leur demande de surveiller un point de passage que l'attaque n'emprunte pas forcément.
Mon verdict en 30 secondes
Valider les commandes une par une donne une impression de contrôle plus large que la protection réelle. L'autorisation porte sur l'exécution, pas sur tout ce qui a préparé cette exécution — et il suffit ensuite d'une commande parfaitement banale pour déclencher ce qui a été mis en place en amont. J'ai vécu la version inoffensive de ce scénario la semaine dernière. La piste sérieuse est ailleurs, du côté du cloisonnement. Reste que je n'ai pas encore décidé ce que j'en fais concrètement, et je préfère l'écrire que de te vendre un plan d'action que je n'applique pas.
Ce qui a été mesuré, et ce que ça vaut
Alex Wauters, ancien Staff Engineer chez Uber, a publié le 5 août les résultats de son jeu de navigateur consacré aux permissions des agents de code. Il précise lui-même qu'il ne s'agit pas d'une étude universitaire.
Le principe : tu incarnes l'humain dans la boucle. Des commandes défilent, tu approuves ou tu refuses, sous contrainte de temps. Certaines sont routinières, d'autres exfiltrent tes identifiants vers un serveur distant.
Plus de 40 000 parties, 409 000 décisions individuelles. Précision moyenne dans le jeu : 66,3 %. Une menace sur trois passe.
Deux réserves avant d'aller plus loin, et l'auteur les pose lui-même. Environ 34 % des commandes affichées étaient des menaces, alors qu'elles sont heureusement rares dans le travail quotidien. Et les joueurs savaient qu'ils étaient testés, dans un défi chronométré. Ce chiffre décrit le comportement de joueurs dans un jeu — pas la précision des développeurs en production.
Ce qui reste solide, en revanche, ce sont les écarts entre les catégories. Là, la comparaison est valable, parce que tous les joueurs affrontaient les mêmes conditions.
Les vraies attaques passent trois fois mieux que les fausses
Le classement par type de menace est parlant.
Les commandes ouvertement destructrices — effacer la racine du système, ouvrir tous les droits sur tous les fichiers — sont ratées 11,7 % du temps. Les modifications persistantes, comme le détournement d'une configuration Git, 23,8 %. L'exfiltration de données et l'exécution de code distant, 33,4 %. Et les violations de périmètre, typiquement la lecture d'un fichier d'identifiants cloud, 35 %.
Autrement dit : plus une commande ressemble à une catastrophe de film, mieux elle est arrêtée. Les commandes qui volent réellement tes accès passent trois fois plus souvent.
Le point aveugle qui me concerne directement
La commande la plus ratée du jeu, première sur trente-sept menaces, est npm run analyze. Approuvée 64,7 % du temps.
Prise isolément, elle est anodine. Mais npm run ne lance pas une commande autonome : il lance un script défini dans le package.json du projet, et ce script peut lui-même appeler d'autres programmes. Ça peut être un analyseur de dépendances standard, ou du code injecté par une modification de fichier antérieure.
Dans le jeu, le journal affiché juste au-dessus de la demande d'autorisation montrait le contenu du script — et ce contenu envoyait les données vers une adresse externe. Deux joueurs sur trois ont approuvé quand même.
Les trois commandes npm run piégées occupent les 1ʳᵉ, 4ᵉ et 8ᵉ places du classement des menaces les plus ratées. Cumulées, elles passent 52,5 % du temps, contre 28,4 % pour toutes les autres attaques d'exfiltration. Cacher une charge derrière un nom de script familier double son taux de réussite, même quand la charge est affichée.
Je travaille sous Next.js. Je lance npm run build. Cette commande exécute ce qui est écrit dans un fichier que je n'ai jamais ouvert.
→ Voir aussi : J'ai construit mon site sans lire le code
L'objection qui déplace le problème
Le passage le plus intéressant de l'article n'est pas une statistique, c'est un commentaire repris de la discussion Hacker News.
L'argument : valider npm run build, c'est valider l'exécution de ce que contient un fichier au moment où la commande part. Or ce fichier a pu être modifié en amont, tout comme les scripts qu'il appelle ou les dépendances que ces scripts importent. Selon l'outil et sa configuration, ces modifications ne font pas nécessairement l'objet d'une approbation humaine distincte — et quand elles en font l'objet, elles sont noyées parmi des dizaines d'autres.
L'autorisation arrive donc trop tard. Elle porte sur le déclencheur, pas sur la préparation.
J'en ai eu la démonstration inoffensive la semaine dernière. En corrigeant un problème d'indexation sur ce site, l'agent a modifié quatre fichiers. J'ai accepté, commité, poussé. Le déploiement a échoué : un fichier importait un paquet qui n'était pas installé, et cette ligne traînait là depuis une session précédente sans apparaître dans les changements qu'on m'avait montrés.
Aucune commande dangereuse n'a jamais eu besoin d'être approuvée pour que ça arrive. C'était une modification de fichier passée inaperçue. Dans mon cas, le résultat a été vingt minutes perdues. Avec une intention malveillante à la place d'un import oublié, le mécanisme aurait été strictement identique.
Le piège inverse : ceux qui font attention sont punis
L'autre moitié du problème est moins commentée, et elle explique pourquoi la vigilance ne tient pas dans la durée.
Des commandes parfaitement légitimes ont été bloquées en masse. Configurer un miroir npm interne : refusé 59 % du temps. Supprimer un dossier de build avant d'en générer un nouveau : 45 %. Libérer un port occupé par un processus planté : 43 %.
Ceux qui font attention ralentissent donc l'outil pour rien, plusieurs fois par jour. Et cette friction produit exactement l'effet qu'on cherchait à éviter — les taux d'erreur remontent d'ailleurs vers la fin des parties. Anthropic l'a documenté de son côté sur Claude Code : plus un utilisateur voit d'approbations, moins il accorde d'attention à chacune.
Le système fabrique la fatigue qui le rend inefficace.
→ Voir aussi : Quand les agents de code tombent dans le piège du malware
Ce que je ne sais pas encore
La conclusion de l'auteur est claire : il faut du bac à sable et de l'isolation stricte du contexte, et n'accorder de permissions larges qu'une fois ces protections en place.
Une précision s'impose ici, parce que l'opposition est facile à caricaturer. Le cloisonnement ne rend pas un agent sûr par magie : il réduit surtout la surface que peut atteindre une erreur ou une compromission. Et il se paie — un agent isolé qui a besoin d'accéder au réseau ou à l'environnement hôte finit par voir son isolation percée, souvent par commodité. Ce n'est pas « permissions humaines contre bac à sable », c'est un déplacement de la question : au lieu de demander si l'humain fait attention, on demande jusqu'où va le dégât quand il se trompe.
Sur ma pratique, je n'ai pas tranché, et je ne vais pas te raconter le contraire.
D'un côté, Xyrotek n'héberge rien qui vaille une attaque ciblée. Pas de données utilisateurs sensibles, pas de valeur marchande. Le calcul rationnel dit que je peux continuer comme avant.
De l'autre, il y a une chose que l'article m'a fait remarquer et que je n'avais pas vue : mes clés d'API vivent au même endroit que tout le reste, et un agent qui lit un fichier de configuration shell les récupère en une commande. La correction est triviale — les isoler dans un fichier séparé — et je ne l'ai pas faite parce que je n'y avais jamais pensé.
Donc non, je ne vais pas conclure sur une liste de bonnes pratiques que je n'applique pas encore. Ce que je retiens pour l'instant, c'est que le sentiment de sécurité que donne le bouton d'approbation est mal placé. Savoir qu'on ne surveille pas au bon endroit, c'est déjà mieux que croire qu'on surveille.
→ Voir aussi : GLM 5.2 et Mythos : ce que change l'IA en cybersécurité
Questions fréquentes
Approuver les commandes d'un agent IA protège-t-il vraiment ?
Partiellement, et moins qu'on ne le croit. Le modèle arrête bien les commandes ouvertement destructrices, ratées environ 12 % du temps dans le jeu de Wauters. Mais il laisse passer un tiers des tentatives d'exfiltration, parce qu'une commande dangereuse ressemble le plus souvent à une commande banale.
Un agent IA peut-il modifier un fichier sans demander l'autorisation ?
Cela dépend de l'outil et de sa configuration. Le point important est ailleurs : une permission peut contrôler l'exécution d'une commande sans contrôler toutes les modifications qui ont préparé cette commande. C'est précisément ce que montrent les scénarios impliquant des scripts npm — l'action dangereuse est préparée en amont, puis déclenchée par une commande qui paraît parfaitement légitime.
Pourquoi npm run est-il particulièrement risqué ?
Parce qu'il ne lance pas une commande autonome, mais un script défini dans le package.json du projet, script qui peut lui-même appeler d'autres programmes. Approuver npm run build revient à approuver l'exécution de ce que contient ce fichier au moment où la commande part — un contenu qui a pu changer depuis la dernière fois que tu l'as regardé.
C'est quoi la fatigue d'approbation ?
C'est la baisse d'attention provoquée par la répétition des demandes de validation. Anthropic l'a documentée : plus un utilisateur voit de demandes, moins il examine chacune sérieusement. Comme la plupart des commandes sont légitimes, l'habitude d'approuver s'installe, et c'est précisément ce que vise une attaque déguisée en routine.
Comment se protéger concrètement ?
Les pistes recommandées par l'auteur portent sur l'environnement plutôt que sur l'attention : exécuter l'agent dans un bac à sable isolé, séparer les secrets du reste de la configuration, et n'accorder des permissions larges qu'une fois ces protections en place. À nuancer toutefois : l'isolation réduit l'ampleur des dégâts possibles, elle ne supprime pas le risque, et elle devient difficile à tenir dès que l'agent doit accéder au réseau.
Ces chiffres sont-ils fiables ?
Ils viennent d'un jeu, pas d'une étude universitaire, et l'auteur le précise. Environ un tiers des commandes affichées étaient des menaces, alors qu'elles sont rares dans la réalité, et les joueurs savaient qu'ils étaient testés. Les taux absolus décrivent donc un comportement de joueurs, pas celui des développeurs en production ; les écarts entre catégories de menaces, mesurés dans les mêmes conditions, sont plus solides.