Les agents d’intelligence artificielle introduisent une révolution majeure dans la sécurité de la chaîne d’approvisionnement logicielle : la documentation n’est plus forcément une source passive d’information. Une étude portant sur des milliers de fichiers llms.txt a révélé des références à des paquets et des domaines qui n’avaient plus de propriétaire. Après avoir enregistré certains d’entre eux, les chercheurs ont constaté que des agents liés à Claude, OpenAI Codex et Hermes avaient fini par installer leurs paquets de test dans des environnements d’entreprise, y compris dans des sociétés du Fortune 500.

Les clés du risque lié au code abandonné pour les agents IA en 30 secondes

• L’analyse a porté sur 6 214 domaines appartenant à des entreprises du Fortune 500, des grandes technologiques et descontracteurs de défense.
• Sur 120 sites, des références à un ou plusieurs paquets ou domaines disponibles à l’enregistrement ont été localisées.
• Les chercheurs ont revendiqué certains noms et publié du code de preuve, conçu uniquement pour confirmer son exécution.
• Des signaux provenaient de plusieurs entreprises, et certains sites ont pu être reliés à Claude, Codex et Hermes.
• Ce problème étend la sécurité de la chaîne d’approvisionnement : un agent peut transformer une documentation obsolète en une action concrète.

Il n’a pas été nécessaire de compromettre le site web d’une entreprise, d’envoyer des emails de phishing ou d’exploiter une vulnérabilité zero-day. Aucun code malveillant n’a été inséré dans un dépôt légitime.

Les chercheurs ont exploité quelque chose d’encore plus simple : des références anciennes encore considérées comme valides alors que la ressource originale avait disparu.

Ce cas est particulièrement pertinent aujourd’hui que les agents de programmation commencent à recevoir des permissions pour utiliser des terminaux, installer des dépendances, modifier des dépôts, exécuter des tests et manipuler des outils de développement.

Un lien rompu ne se résume plus toujours à une erreur 404.

Dans certains flux automatisés, cela peut devenir une opportunité d’introduire du code.

De llms.txt au terminal : où évolue la sécurité

llms.txt est une convention émergente visant à fournir aux modèles de langage une représentation simple et structurée du contenu d’un site web.

La référence usuelle est robots.txt, mais techniquement, ces outils jouent des rôles différents. Alors que robots.txt donne des directives aux robots d’indexation, llms.txt vise à aider modèles et agents à rechercher et comprendre la documentation pertinente.

Ce format en lui-même ne permet pas d’installer quoi que ce soit.

Le risque apparaît lorsque les informations qu’il contient ou référence sont utilisées par un agent doté d’outils permettant d’agir.

Une documentation technique peut par exemple indiquer qu’une bibliothèque nécessite l’installation d’un paquet. L’agent consulte ces instructions, détermine qu’il a besoin de cette dépendance et exécute le gestionnaire de paquets correspondant.

Ce flux fonctionne tant que tous les composants de la chaîne restent sous contrôle légitime.

Mais Internet regorge d’anciens résidus techniques : projets abandonnés, dépôts supprimés, paquets retirés, domaines expirés, documentation obsolète.

Les chercheurs ont analysé 6 214 domaines actifs appartenant à de grandes organisations. Selon les données publiées, ils ont trouvé 8 265 fichiers llms.txt et llms-full.txt, ainsi que 120 sites renvoyant vers des ressources sans propriétaire.

La situation rappelle certains problèmes connus de la chaîne d’approvisionnement, mais avec une nuance essentielle.

Auparavant, une personne se trouvait souvent entre la documentation et l’exécution.

Aujourd’hui, un agent peut intervenir.

Un paquet disparaît, mais sa confiance reste

Pour évaluer ses conséquences, les chercheurs ont revendiqué certains des noms de domaine devenus disponibles.

Ils n’ont pas publié de malware visant à compromettre des entreprises. Ils ont utilisé des paquets de test, conçus pour envoyer un signal à leur infrastructure lorsqu’ils étaient exécutés.

Puis ils ont attendu.

Ce mécanisme est particulièrement intéressant d’un point de vue sécurité car les chercheurs n’avaient pas besoin de rechercher activement des systèmes vulnérables. Les références étaient déjà publiées par les organisations ou dans une documentation jugée légitime.

Lorsque les agents ont traité cette information et effectué les installations, les signaux sont arrivés.

L’analyse des chaînes de processus a permis de relier certaines exécutions à des agents de programmation, notamment Claude, OpenAI Codex et Hermes de Nous Research.

Ce qui nécessite une précision importante.

L’expérience ne prouve pas que ces agents installent systématiquement et de façon autonome chaque paquet mentionné dans llms.txt. L’exécution dépend de leur configuration, des instructions, des outils disponibles et des permissions accordées par l’utilisateur ou l’organisation.

L’enjeu de sécurité réside précisément là.

Plus un agent dispose d’autonomie, plus il est crucial de vérifier la provenance de chaque instruction qu’il exécute.

Le vieux problème des domaines expirés touche aussi les agents

David Carrero Fernández-Baillo, co-fondateur de Stackscale (Groupe Aire), établit une analogie intéressante avec un phénomène connu depuis des années sur Internet : la confiance résiduelle des domaines expirés.

Carrero explique qu’il a souvent enregistré des domaines expirés pour des projets légitimes liés au SEO. Un domaine ayant plusieurs années d’histoire peut encore bénéficier de liens vers d’autres pages et d’une partie de l’autorité acquise quand il appartenait à un ancien propriétaire.

Le nouveau propriétaire hérite, en quelque sorte, d’une réputation qu’il n’a pas construite lui-même.

Les recherches sur les agents montrent une version beaucoup plus fragile de ce principe.

Si une entreprise recommandait un domaine, un paquet ou un dépôt pendant des années, et que ce ressource disparaît, la référence peut continuer à faire confiance à l’ancien propriétaire, même si celui-ci n’a plus le contrôle.

Dans un site traditionnel, cela peut simplement conduire à diriger les visiteurs vers un domaine appartenant à une autre personne.

Mais avec une documentation technique traitée par des agents, cela pourrait aboutir à une situation différente : hériter, éventuellement, d’un accès à une chaîne qui peut mener à l’exécution de logiciel.

Comme le souligne Carrero, le saut conceptuel est considérable : on passe de hériter de l’autorité SEO liée aux liens à pouvoir hériter d’une porte d’entrée laissée ouverte par la documentation.

Ce n’est pas une vulnérabilité liée à llms.txt

Se concentrer uniquement sur llms.txt pourrait conduire à une conclusion erronée.

Supprimer ces fichiers ne résoudrait pas le problème.

Un agent peut recevoir des instructions à partir d’un README, de documentation officielle, d’un dépôt, d’une page de support, d’un tutoriel ou toute autre source qu’il considère fiable.

Le problème réside dans la confusion entre autorité documentaire et autorité d’exécution.

Les équipes de sécurité ont depuis des années pour mission de protéger les dépôts de code et les pipelines d’intégration et déploiement continus (CI/CD). Elles analysent dépendances, images de conteneurs, identifiants d’accès et artefacts.

La documentation reçoit généralement un traitement différent, car historiquement sa capacité à modifier les systèmes était indirecte.

Les agents changent cette séparation.

Si un document peut faire exécuter un commandement, installer une dépendance ou modifier une configuration, ce document devient une surface d’attaque supplémentaire.

Il devient donc crucial de revoir la sécurité du contenu publié par les entreprises elles-mêmes.

Une entreprise devrait pouvoir répondre à des questions autrefois secondaires : tous les paquets recommandés dans sa documentation existent-ils encore ? Les domaines liés sont-ils toujours sous contrôle du même propriétaire ? Les dépôts mentionnés sont-ils toujours légitimes ? Qu’advient-il des documentations de produits abandonnés ?

Le maintien de la documentation commence à ressembler à la gestion des dépendances.

La chaîne d’approvisionnement a besoin d’une couche spécifique pour les agents

La réponse technique ne devrait pas simplement consister à ajouter une autre mise en garde au modèle.

Les organisations qui permettent à des agents d’exécuter du code doivent établir des contrôles hors du modèle lui-même.

Le principe le plus simple consiste à ne pas considérer qu’une source documentaire suffit pour établir la confiance dans une dépendance.

La provenance du paquet doit être vérifiée de manière indépendante. En fonction de l’environnement, cela peut inclure la vérification du registre, du propriétaire, de la version, de l’âge, de la signature, du hash, du dépôt d’origine, et autres métadonnées disponibles.

Les agents ne devraient pas non plus disposer automatiquement des mêmes privilèges qu’un développeur.

Un environnement isolé ou jetable permet à l’agent de tester une dépendance sans la déployer immédiatement dans des systèmes avec accès aux données sensibles de l’organisation.

Cette séparation est essentielle lorsque l’agent possède des identifiants pour des services cloud, dépôts privés, gestionnaires de secrets, pipelines CI/CD ou infrastructure de production.

La validation manuelle reste pertinente pour certaines opérations.

Mais elle ne doit pas être la seule barrière.

Une personne recevant une multitude de demandes de validation risque de tout approuver mécaniquement, surtout si l’interface se limite à demander « autoriser l’installation ? ».

Le contrôle doit apporter du contexte : quel paquet sera installé, qui en est le mainteneur, d’où provient la recommandation, et pourquoi l’agent juge nécessaire de l’utiliser.

Le problème culturel derrière la faille technique

Carrero souligne aussi un aspect moins visible dans cette étude : 120 sites des 6 214 analysés continuaient à faire référence à des ressources qui ne contrôlaient plus correctement.

Ce n’est pas une vulnérabilité sophistiquée.

C’est le résultat de pratiques connues depuis plusieurs décennies : documentation vieillissante, projets abandonnés, domaines non renouvelés, références copiées sans vérification de leur état.

Le copy-paste a toujours été une source de risques en développement logiciel.

Ce qui change, c’est l’échelle.

Un développeur peut copier une commande, l’exécuter, rencontrer une erreur et arrêter. Un agent peut consulter des dizaines de pages, résoudre des dépendances, exécuter des instructions en quelques secondes.

Automatiser une tâche, c’est aussi automatiser ses mauvaises pratiques.

Il en résulte une dimension culturelle aussi bien que technique.

L’arrivée des agents oblige à abandonner une hypothèse largement ancrée : que tout ce qui est publié sous le domaine d’un fournisseur peut être considéré comme fiable et à jour par défaut.

La documentation doit être considérée comme une source d’information, pas comme une signature numérique.

Des liens cassés à une nouvelle surface de vulnérabilité

L’étude donne aussi une piste sur l’évolution possible de la sécurité offensive.

Internet regorge de références abandonnées. Beaucoup concernent des projets sans importance, mais d’autres figurent encore dans la documentation d’entreprises, scripts anciens, dépôts, tutoriels et paramètres.

Jusqu’à présent, repérer l’un de ces ressources avait peu d’intérêt.

Les agents peuvent transformer cette situation.

Un attaquant pourrait systématiquement rechercher des références vers des paquets, domaines ou dépôts abandonnés présents dans la documentation utilisée par des outils automatisés.

L’objectif ne serait plus de faire installer quelque chose à une personne, mais de découvrir une chaîne de confiance abandonnée encore exploitée par des machines.

L’exp érience avec llms.txt montre que cette possibilité n’est plus purement théorique.

Les entreprises déployant des agents capables de programmer, utiliser des terminaux et gérer des services ont désormais besoin de s’assurer que la confiance qu’elles accordent à Internet ne s’accroît pas aussi rapidement.

Car le code abandonné existe depuis des années.

Ce qui a changé, c’est que des agents sont maintenant prêts à le repérer, l’interpréter et, selon certaines conditions, l’exécuter.

Questions fréquemment posées

Llms.txt représente-t-il une vulnérabilité de sécurité ?

Pas en soi. llms.txt est une convention pour fournir des informations aux modèles et agents. Le risque apparaît lorsque un agent transforme ces instructions en actions sans vérifier de manière indépendante les ressources impliquées.

Qu’est-ce qu’un paquet abandonné ?

Dans ce contexte, il s’agit d’un nom de paquet, domaine ou autre ressource mentionnée par la documentation existante, mais qui n’est plus contrôlée par son propriétaire original. Si quelqu’un peut la réclamer, les références anciennes peuvent finir par pointer vers un nouveau propriétaire.

Claude, Codex et Hermes ont-ils exécuté du code provenant des chercheurs ?

Les chercheurs ont relié certaines installations à des chaînes de processus associées à Claude, OpenAI Codex et Hermes. L’expérience ne signifie pas que tous ces agents agissent ainsi en permanence : cela dépend de leur configuration, de leurs permissions et de leur environnement.

Comment une entreprise utilisant des agents IA devrait-elle se protéger ?

Elle doit appliquer le principe du moindre privilège, isoler les exécutions, vérifier les dépendances via des mécanismes indépendants et réviser périodiquement les paquets, domaines et dépôts recommandés dans la documentation. Les opérations sensibles ne devraient pas uniquement dépendre de la fiabilité d’un site web.

Source : Open Security