Claude installe seul des paquets npm, et le mauvais peut emporter vos fichiers

La fonction Computer Use de Claude fait une chose qu’un chatbot ordinaire ne peut pas faire. Elle ouvre un terminal sur votre ordinateur et installe des logiciels à votre place, y compris des paquets tirés directement de npm, le plus grand registre de code libre au monde. L’attrait saute aux yeux, puisqu’il réduit «installe-moi ce projet» à une seule phrase. Le risque tient dans la même phrase, car dès qu’un paquet arrive, npm peut exécuter le code de démarrage que ce paquet a apporté avec lui, et c’est désormais un agent autonome qui appuie sur la détente.

Pour quiconque laisse un agent d’IA écrire ou exécuter du code, et ils sont de plus en plus nombreux parmi les développeurs, les amateurs et les curieux sans bagage technique, la question pratique est brutale. Si Claude installe un paquet que vous n’avez jamais regardé, et que ce paquet a été conçu pour copier vos fichiers à l’instant où il atterrit, qui était censé l’arrêter? Une vidéo récente d’un chercheur en sécurité parcourt exactement cette situation et montre un paquet piégé en train de lire des fichiers locaux pendant une installation de routine que l’IA mène sans hésiter.

Le mécanisme n’est pas nouveau, et c’est précisément ce qui le rend grave. Les paquets npm peuvent déclarer des scripts d’installation, de petites instructions qui s’exécutent automatiquement dès qu’un paquet est ajouté à un projet, avant qu’une seule de ses lignes ne soit utilisée à dessein. C’est un comportement documenté, pas un défaut. Il permet à des outils légitimes de se compiler ou de préparer leur environnement. Il signifie aussi que n’importe quel paquet peut exécuter du code sur votre machine au moment de l’installation, avec vos propres droits, et les équipes de sécurité le répètent depuis des années.

Le monde a reçu un rappel net de l’enjeu lorsque des attaquants ont pris le contrôle du compte de mainteneur d’Axios, une bibliothèque réseau téléchargée des dizaines de millions de fois par semaine, et y ont glissé une dépendance malveillante qui installait un cheval de Troie d’accès à distance sur les machines des développeurs. Ils n’ont jamais touché au vrai code d’Axios. Le script d’installation a fait le travail. Or Axios est lui-même une brique de Claude Code, parmi d’innombrables autres applications, ce qui montre la faible distance qui sépare l’outil auquel vous faites confiance du code qu’il tire discrètement derrière lui.

Ce que la démonstration ajoute à ce tableau connu, c’est l’agent. Une personne qui lance une installation peut au moins s’arrêter, lire le nom du paquet, remarquer qu’il est mal orthographié ou publié à l’instant, et faire marche arrière. Un agent d’IA qui agit sur une consigne vague n’a pas ce réflexe. Il installe ce qu’il juge nécessaire. Et comme Computer Use lit aussi l’écran, déplace le curseur et tape au clavier, une seule dépendance empoisonnée ne reste pas enfermée dans l’éditeur de code. Elle a le champ libre sur tout le bureau.

Il vaut la peine d’être précis sur ce que c’est et ce que ce n’est pas. Ce n’est pas une porte dérobée cachée et propre à Claude, ni la preuve que le modèle a été berné pour contourner ses propres règles. C’est le résultat prévisible du fait de donner à n’importe quel programme autonome le pouvoir d’installer des logiciels, ajouté à un registre qui exécute du code d’installation par défaut depuis plus de dix ans. Remplacez Claude par n’importe quel autre agent de codage doté des mêmes droits et l’image est identique. Le danger vit dans l’autonomie et dans le registre, pas dans le chatbot d’une entreprise.

Anthropic pousse plutôt dans le sens inverse. L’entreprise a récemment livré pour ses outils de codage un bac à sable qui isole l’agent du reste du système, limite les fichiers qu’il peut lire et les serveurs qu’il peut joindre, et a publié en code libre la boîte à outils d’isolation qui le sous-tend pour les autres développeurs. Le raisonnement est celui que la démonstration met à nu. Un agent qui ne peut atteindre vos clés SSH ne peut pas les divulguer, et un agent qui ne peut joindre un serveur inconnu ne peut envoyer vos fichiers nulle part. L’entreprise affirme que ces limites réduisent d’environ 84 pour cent les demandes d’autorisation qu’elle adresse aux utilisateurs, ce qui compte, car un outil qui demande tout finit par habituer les gens à cliquer oui.

Pour ceux qui se servent vraiment de ces outils, les défenses sont ennuyeuses et efficaces. Faites tourner l’agent dans un bac à sable, un conteneur ou une machine virtuelle jetable, pour que le pire qu’un mauvais paquet puisse atteindre soit un environnement sacrifiable. Désactivez les scripts d’installation automatiques quand le flux de travail le permet, ce que certains gestionnaires de paquets récents font déjà par défaut. Gardez identifiants, clés et fichiers personnels hors de la machine où l’agent a les coudées franches. Et traitez «installe-moi ça» avec la prudence réservée à «ouvre cette pièce jointe», parce qu’en dessous, c’est plus proche de cela qu’il n’y paraît.

Le paquet précis de la démonstration est la preuve d’un chercheur, pas une épidémie réelle, et rien n’indique qu’il ait atteint de vrais utilisateurs. C’est le schéma derrière lui qui ne restera pas en place. Le codage par agents devient la norme plus vite que les habitudes censées le rendre sûr, et les registres sur lesquels ces agents s’appuient n’ont jamais été conçus pour un monde où celui qui tape la commande d’installation n’est pas une personne. Tant que cet écart ne se referme pas, la plus vieille règle de la sécurité logicielle vise désormais un utilisateur d’un genre nouveau: ce que votre agent installe, il l’exécute, alors décidez de ce qu’il a le droit de toucher avant de le laisser commencer.