Le chercheur en sécurité Alon Hertz et une petite équipe ont passé le web au crible à la recherche de fichiers llms.txt, un nouveau format que les sites publient à côté de robots.txt pour indiquer aux agents IA de codage quels documents lire, quelles API appeler et quels paquets installer. L'outil Lighthouse de Google, intégré aux Chrome DevTools, audite désormais ce fichier sous une catégorie "Agentic browsing", ce qui incite davantage de sites à en publier un.

npx clerk-next-fix-auth-protection

En un week-end, l'équipe a résolu 8 565 fichiers llms.txt sur 6 214 domaines actifs, parmi environ 15 000 entreprises répertoriées incluant des groupes du Fortune 500, des géants de la tech, des fintechs et des entreprises de défense. En examinant les commandes d'installation contenues dans ces fichiers, ils ont identifié plus de 237 noms de paquets, domaines et sous-domaines référencés, répartis sur PyPI, npm, RubyGems, NuGet, crates.io et Packagist, ainsi que des domaines .dev et .io expirés et des sous-domaines Render, Vercel, Fly et Netlify abandonnés, dont aucun n'avait réellement été revendiqué.

Pour tester le risque réel, les chercheurs ont eux-mêmes enregistré quelques-uns de ces noms libres et y ont intégré un signal de rappel inoffensif. Le premier appel d'installation depuis une entreprise du Fortune 500 est arrivé en moins de quatre minutes, un second a suivi dans l'heure, puis des dizaines d'autres sont venus d'entreprises de tailles variées. Un test distinct sur cinq configurations de modèles de pointe et deux CLI agentiques a montré qu'une simple invite d'une ligne, citant uniquement le nom du fournisseur, sans URL ni mention de llms.txt, suffisait sur 100 essais à faire trouver le fichier par l'agent lui-même et installer le faux paquet.

En analysant les données, l'équipe a découvert une attaque réelle, non simulée, déjà active. La documentation llms.txt du fournisseur d'authentification Clerk pour les applications Next.js demande aux agents d'exécuter "npx clerk-next-fix-auth-protection". Ce binaire est censé faire partie du vrai paquet de Clerk, @clerk/eslint-plugin, mais lorsque la commande brute est lancée avant l'installation locale de ce paquet, npx résout le nom via le registre public npm, où un tiers l'avait déjà enregistré. Le paquet piégé n'a aucune fonction réelle : à chaque installation, il exfiltre le nom d'utilisateur, le nom de la machine, le répertoire de travail et l'horodatage vers un serveur externe. Il est répertorié sous MAL-2026-11069, classé CWE-506, et signalé par OSV.dev de Google et par Amazon Inspector. L'équipe sécurité de Clerk a été prévenue et a corrigé le problème rapidement ; le paquet malveillant avait été créé par un tiers extérieur, pas par Clerk.

Les chercheurs soutiennent que les outils de détection d'endpoint passent totalement à côté de ce schéma, car le trafic ressemble à une installation pip ou npm ordinaire, lancée par un agent de codage que l'entreprise a elle-même installé. Ils résument le changement sous-jacent ainsi : la donnée devient du code. Documentation, forums et tickets rédigés pour des humains sont désormais lus et exécutés par des agents IA, effaçant l'ancienne frontière entre contenu passif et code exécutable, sans aucun des contrôles d'intégrité qu'un code exige normalement.