Sécurité des agents IA : la menace des fichiers llms.txt et des dépendances abandonnées
Des chercheurs en sécurité ont démontré que des assistants de code exécutent automatiquement des commandes d'installation contenues dans des fichiers de documentation pour IA. En prenant le contrôle de noms de paquets non déposés cités dans des fichiers llms.txt, un attaquant peut introduire du code malveillant au cœur des réseaux d'entreprise.
Fil « Infiltration de dépendances non vérifiées par les assistants de code »
Les fichiers llms.txt et llms-full.txt sont devenus une convention émergente pour fournir aux grands modèles de langage (LLM, le moteur algorithmique des IA) des résumés structurés du contenu d'un site web, à l'image du fichier robots.txt (qui indique aux moteurs de recherche comment indexer un site web). Cependant, ces fichiers créent une faille majeure dans les chaînes d'approvisionnement logiciel lorsque des agents de code y lisent des instructions d'installation qu'ils exécutent sans vérification préalable.
Des failles exécutées automatiquement au cœur des entreprises
Des chercheurs d'une jeune entreprise israélienne spécialisée dans la sécurité ont analysé 6 214 domaines appartenant à des entreprises du secteur de la défense, du Fortune 500 et de la Tech. Sur 8 265 fichiers llms.txt et llms-full.txt recensés, 120 d'entre eux contenaient un total de 227 commandes pointant vers des noms de domaines enregistrables ou des paquets logiciels non revendiqués sur des registres comme PyPI (Python Package Index, le dépôt officiel de paquets Python) ou npm (Node Package Manager, le gestionnaire de dépendances JavaScript).
Pour mesurer l'impact réel, les chercheurs ont déposé une poignée de ces noms de paquets vacants en y intégrant un code test. En moins d'une heure, des machines situées au sein de grandes entreprises ont exécuté ce code et contacté leur serveur test. L'analyse des processus parents a révélé l'intervention directe d'agents de développement d'IA réputés tels que Claude (Anthropic), Codex (OpenAI) et Hermes (Nous Research).
Quand la frontière entre données et instructions s'effondre
Le problème réside dans l'incapacité fondamentale des assistants de code à distinguer une simple donnée textuelle d'une instruction à exécuter. Lorsqu'un agent navigue sur la documentation officielle d'un fournisseur ou d'un partenaire, il considère ce contenu comme une source de vérité absolue.
# Exemple de commande d'installation vulnérable présente dans un fichier llms.txt
npx clerk-next-fix-auth-protection
Un cas d'attaque réelle a d'ailleurs été identifié sur le site officiel de Clerk. Un fichier destiné aux IA contenait une instruction utilisant npx (un outil permettant de télécharger et d'exécuter temporairement un paquet sans l'installer durablement dans le projet). Le nom du paquet n'étant pas réservé sur le registre public, un tiers malveillant l'a enregistré pour y publier un logiciel malveillant avant que le problème ne soit corrigé.
« Un agent ne fait pas la différence entre une page et une commande. Tout ce qu'il lit est une entrée, et chaque entrée est une instruction potentielle. »
Les outils de protection traditionnels pris à revers
Cette vulnérabilité échappe aux solutions EDR (Endpoint Detection and Response, les outils de détection et de réponse installés sur les postes de travail). Du point de vue des pare-feu et des proxies d'entreprise, la commande exécutée semble totalement légitime : il s'agit d'un gestionnaire de paquets standard effectuant une requête vers un domaine autorisé (comme pypi.org), initiée par l'assistant de code installé par l'équipe de développement.
Pour les équipes techniques qui s'appuient au quotidien sur des agents autonomes pour automatiser la configuration ou la résolution de bugs, cette découverte impose une vigilance renforcée. Sans garde-fous stricts encadrant les autorisations d'exécution dans le terminal, l'agent peut devenir le vecteur involontaire d'une compromission réseau.