Une enquête de sécurité a établi un lien entre Claude, OpenAI Codex et les agents de codage Hermes de Nous Research et l’installation de paquets logiciels non revendiqués dans des environnements d’entreprise. L’activité est apparue lorsque des chercheurs ont testé des fichiers de documentation qui orientaient les agents vers des paquets et des domaines qu’aucune organisation ne détenait actuellement.

Ces résultats sont importants car les commandes ressemblaient à de simples instructions de configuration pour développeurs et, dans plusieurs cas, provenaient de sites web d’entreprise légitimes. Les chercheurs ont indiqué avoir reçu un callback d’une entreprise du Fortune 500 dans l’heure suivant l’enregistrement de certains noms de paquets et de domaines abandonnés pour un test de preuve de concept. Les éléments ne démontrent pas une compromission généralisée, mais ils montrent comment des agents IA disposant d’un accès au shell peuvent transformer une documentation obsolète en point d’entrée pour la chaîne d’approvisionnement logicielle.

Ce que les chercheurs ont découvert

Selon Ars Technica AI, une startup de sécurité discrète en Israël a analysé 6 214 domaines actifs associés à des sous-traitants de la défense, à des entreprises du Fortune 500 et à de grandes sociétés technologiques. L’équipe a identifié 8 265 fichiers utilisant les conventions émergentes llms.txt et llms-full.txt, que les sites web emploient pour fournir des descriptions et une navigation lisibles par machine aux systèmes d’IA.

Parmi ces fichiers, 120 hébergés sur des sites distincts faisaient référence à un ou plusieurs noms de paquets non enregistrés ou à des domaines non revendiqués. Au total, les chercheurs ont compté 227 commandes visant à installer des paquets ou à accéder à des domaines qui n’étaient pas détenus au moment de l’analyse. De nombreuses références concernaient des écosystèmes de paquets courants, notamment PyPI et npm.

Pour tester le risque, les chercheurs ont enregistré plusieurs des noms abandonnés et hébergé des paquets conçus pour contacter leur serveur lors de leur exécution. Le beacon obtenu a identifié des processus parents associés à Claude, Codex et Hermes. Les chercheurs ont également reçu des callbacks de quelques dizaines d’organisations, dont certaines entreprises du Fortune 500 et des startups, après le traitement des paquets de test.

L’enquête n’a pas montré que ces entreprises avaient été infectées par des logiciels malveillants. Elle a montré que leurs environnements exécutaient du code de preuve de concept ou atteignaient d’une autre manière l’infrastructure des chercheurs. Anthropic, OpenAI et Nous Research n’avaient pas répondu aux demandes de commentaires au moment de la publication, selon Ars Technica AI.

Un problème de documentation devient un risque d’exécution

L’exposition vient de la manière dont les agents de codage IA combinent navigation, récupération et exécution de commandes. Un agent peut lire la documentation d’un fournisseur, en considérer le contenu comme faisant autorité, puis exécuter la commande de configuration dans un environnement local ou d’entreprise. Si le paquet référencé n’a jamais été enregistré, un attaquant peut plus tard s’approprier le nom et publier du code malveillant sous ce nom.

Un schéma documenté utilisait des instructions pip install ou npm install pour des paquets qui n’existaient pas. Un autre faisait référence à un domaine inexistant d’un framework de test. Le problème de sécurité ne se limite donc pas à un site malveillant ou à un prompt délibérément empoisonné. Un auteur de documentation a peut-être saisi il y a des années une dépendance erronée, obsolète ou hallucinated, laissant la référence disponible pour quelqu’un d’autre.

Les chercheurs ont également décrit un cas impliquant le site web de Clerk. Un fichier llms.txt contenait une commande npx associée à un nom de paquet qui a ensuite été revendiqué et utilisé pour diffuser des malwares en activité. Comme npx peut récupérer et exécuter un binaire de paquet sans l’ajouter au manifeste des dépendances d’un projet, la commande créait un chemin particulièrement direct vers l’exécution.

Clerk a ensuite corrigé le problème de documentation. L’entreprise a indiqué que les utilisateurs ayant déjà installé un paquet مرتبط, @clerk/eslint-plugin, n’étaient pas exposés au paquet malveillant dans les circonstances qu’elle a décrites. Il reste incertain de savoir si la confusion liée à Clerk a causé de réelles infections.

Pourquoi les défenses conventionnelles peuvent manquer le signal

L’enquête met en évidence un écart entre le moment où une décision dangereuse est prise et celui où les outils de sécurité d’entreprise cherchent généralement les abus. Un agent de codage exécutant pip ou npm sur un registre de paquets connu peut ressembler à une activité normale de développement. Les outils de détection et de réponse sur les terminaux peuvent voir un assistant IA approuvé lancer un gestionnaire de paquets familier via une connexion réseau autorisée.

Le problème est la relation non vérifiée entre la documentation et la dépendance. Un agent peut confirmer que le fichier provient d’un domaine HTTPS officiel et que la commande utilise un registre standard, tout en omettant de vérifier la propriété du paquet, l’identité de l’éditeur, la provenance ou le caractère attendu de la dépendance dans le projet. Ces vérifications ne font pas nécessairement partie du flux de travail par défaut de l’agent.

Cela est lié à l’injection de prompt, mais plus large sur un point important. L’injection de prompt implique généralement des instructions délibérément insérées pour manipuler un modèle. Dans le scénario décrit par les chercheurs, l’instruction d’origine peut être authentique et bénigne. Le danger apparaît plus tard, lorsqu’un paquet ou un domaine abandonné devient disponible pour un attaquant.

Ce que cela signifie pour les développeurs d’IA et les équipes d’entreprise

Pour les développeurs d’agents IA, ces résultats renforcent l’idée qu’il faut traiter la documentation récupérée comme une entrée non fiable plutôt que comme une extension de la commande de l’utilisateur. Les agents capables d’exécuter des commandes shell devraient séparer la lecture des instructions de l’autorisation d’exécution, exiger une confirmation pour les nouvelles dépendances et vérifier la propriété ainsi que la provenance des paquets avant l’installation. Le sandboxing et l’accès réseau restreint peuvent réduire les conséquences lorsque ces contrôles échouent.

Les équipes produit qui déploient des agents de codage au sein des entreprises sont confrontées à une question de gouvernance plus immédiate : un assistant doit-il avoir simultanément un accès sans restriction aux dépôts internes, aux registres de paquets, aux identifiants et aux systèmes proches de la production ? Une politique de déploiement utile peut autoriser la génération et les tests de code dans un environnement isolé tout en bloquant l’installation arbitraire de paquets ou en exigeant une liste d’artefacts approuvés.

Les équipes de sécurité devraient auditer les fichiers llms.txt et llms-full.txt sur leurs propres domaines, mais le risque ne se limite pas à ces formats. Les agents consomment aussi des fichiers README, des guides SDK de fournisseurs, des fils de discussion, des exemples et de la documentation tierce. Les organisations devront mettre en place des contrôles de vérification des dépendances et de provenance sur l’ensemble du parcours de récupération, y compris pour les partenaires de confiance et les projets communautaires.

L’implication pour le marché est pratique plutôt que spéculative. Les assistants de codage IA reçoivent davantage d’autorité pour agir, tandis que les défenses de la chaîne d’approvisionnement logicielle restent largement conçues pour des développeurs humains et des systèmes de build conventionnels. Plus les agents installent automatiquement des outils, plus il devient important d’enregistrer pourquoi une dépendance a été choisie et quelle source l’a autorisée.

Ce qu’il faut surveiller ensuite

Le premier signal sera de savoir si Anthropic, OpenAI ou Nous Research publient des changements sur la manière dont leurs agents gèrent les commandes d’installation, les paquets non enregistrés et les instructions récupérées. Les chercheurs en sécurité et les utilisateurs d’entreprise devraient aussi surveiller les contrôles des registres de paquets qui signalent la réutilisation de noms abandonnés ainsi que les plateformes d’agents qui ajoutent des vérifications de provenance avant l’exécution.

Un deuxième signal sera de voir si les entreprises audite et corrigent leur documentation lisible par machine. Le scan des chercheurs a montré que certaines entrées défectueuses dataient d’avant l’ère de l’IA, ce qui suggère que le simple nettoyage pourrait ne pas résoudre le problème. Les équipes devront surveiller la propriété des paquets dans le temps, et pas seulement valider une dépendance lors de la première publication de la documentation.

Enfin, les équipes de réponse aux incidents pourraient rechercher des preuves que des callbacks ou des revendications de paquets similaires se sont produits en dehors de tests contrôlés. Les informations actuelles démontrent une exposition et au moins un cas de malware en direct lié à une référence documentaire, mais elles ne quantifient pas les infections confirmées parmi les organisations concernées.

Perspective de Creati.ai

Cet incident est un avertissement sur l’autorité, pas seulement sur la précision du modèle. Un agent IA peut formuler une requête techniquement correcte vers un registre de paquets tout en agissant sur une instruction dangereuse. Cette distinction est facile à manquer lorsque la commande provient d’un domaine officiel d’un fournisseur.

Pour les entreprises, la réponse sensée n’est pas d’abandonner les assistants de codage, mais de limiter ce qu’ils peuvent exécuter et d’exiger une provenance vérifiable des dépendances. Tant que les agents ne pourront pas distinguer de manière fiable le matériel de référence de l’autorisation, toute installation automatisée devrait être traitée comme une action sensible pour la sécurité.