Claude, Codex et Hermes ont installé du code non réclamé dans les réseaux d’entreprise

DES AGENTS IA INJECTENT DU CODE INEXISTANT DANS LES INFRASTRUCTURES D'ENTREPRISE


L’essor des agents d’intelligence artificielle capables d’exécuter des commandes système a mis en lumière une faille inattendue : des fichiers de configuration destinés aux IA, comme les llms.txt, contiennent des références à des paquets ou domaines qui n’existent pas. Lorsque ces agents les traitent comme des instructions fiables, ils téléchargent et exécutent du code qui n’est la propriété d’aucune entité légitime, exposant ainsi les réseaux d’entreprises à des risques de compromission.

Qu’est‑ce que le format llms.txt et pourquoi il est critique
Le format llms.txt (et son pendant plus complet llms-full.txt) est une convention émergente qui fournit aux agents d’IA des résumés lisibles par machine du contenu et de la structure d’un site web. Son rôle est comparable à celui du fichier robots.txt pour les moteurs de recherche, mais orienté vers les modèles de langage. Google Lighthouse décrit d’ailleurs comment auditer ces fichiers : audit llms.txt avec Lighthouse. Des exemples correctement configurés sont disponibles chez Cloudflare : llms.txt Cloudflare et llms-full.txt Cloudflare.

Ces fichiers sont souvent publiés sur les domaines officiels des entreprises, parfois même sur des sous‑domaines de partenaires ou de fournisseurs de SDK. Leur visibilité HTTPS et leur format standardisé incitent les agents IA à les considérer comme une source d’autorité sans remise en question.

Méthodologie de la découverte
Une équipe de chercheurs d’une start‑up israélienne a scanné 6 214 domaines actifs appartenant à des acteurs de la défense, des sociétés du Fortune 500 et des géants du Big Tech. Parmi les 8 265 fichiers llms.txt et llms-full.txt repérés, 120 pointaient vers des paquets ou des noms de domaine non enregistrés. En enregistrant ces identifiants vides et en hébergeant des paquets factices, les chercheurs ont pu observer les appels « phone‑home » des agents IA. En moins d’une heure, un premier signal provenait d’une entreprise du Fortune 500, suivi rapidement de dizaines d’autres, y compris des start‑ups.

Les traces d’exécution ont révélé l’implication de trois agents majeurs : Claude d’Anthropic, Codex d’OpenAI et Hermes de Nous Research. Aucun des trois fournisseurs n’a commenté l’incident au moment de la publication. L’un des chercheurs, Alon Hertz, a souligné que « le modèle de confiance est brisé » : les agents traitent les documents fournisseurs comme une vérité absolue, et les humains qui les supervisent ne questionnent pas non plus ces sources.

Comment les fichiers mal configurés déclenchent l’exécution de code non autorisé
Les llms.txt incriminés contiennent des instructions d’installation vers des registres publics comme PyPI ou npm, mais avec des noms de paquets inexistants. Exemple :

```
Installation: pip install <paquet‑inexistant>
```

ou

```
npm install <paquet‑inexistant>
```

Un attaquant peut enregistrer le nom libre, publier un paquet malveillant (ransomware, spyware, etc.) et ainsi profiter de la confiance accordée à l’agent IA. De même, certaines entrées pointent vers des domaines expirés ; en les rachetant, un adversaire peut injecter des scripts ou des instructions de configuration.

Un cas concret a été observé sur le site légitime clerk.com où le fichier llms.txt contenait la commande :

```
npx clerk-next-fix-auth-protection
```

Le binaire npx télécharge le paquet depuis le registre npm et l’exécute sans l’ajouter au manifeste du projet. Un acteur malveillant a revendiqué ce nom de paquet et y a placé du malware actif. Clerk a depuis corrigé le problème, mais l’incident montre que la vulnérabilité peut être exploitée en temps réel.

Pourquoi les contrôles traditionnels échouent
Les systèmes de détection d’endpoints (EDR) ou les proxys réseau ne perçoivent généralement pas ces actions comme suspectes : le trafic provient d’une source HTTPS légitime, le téléchargement provient d’un registre public et la commande est initiée par un processus légitime (l’agent IA). En d’autres termes, la chaîne de confiance est transitive : si le fichier llms.txt d’un partenaire est considéré comme fiable, tout le contenu qu’il référence hérite de cette confiance.

Les chercheurs ont noté que de nombreux fichiers contenaient des entrées antérieures à l’ère de l’IA, introduites manuellement par des humains, ainsi que d’autres générées par des IA qui « hallucinent » des instructions. Cette confusion entre données et code rend difficile l’application de garde‑fous classiques.

Recommandations pour sécuriser la chaîne d’approvisionnement IA
1. Validation stricte des références : chaque paquet ou domaine mentionné dans un llms.txt doit être vérifié automatiquement contre les registres officiels (PyPI, npm, etc.) avant d’être accepté par un agent.
2. Signature des fichiers llms.txt : adopter une approche similaire aux signatures de code, où chaque fichier est signé par la société propriétaire et vérifié par l’agent.
3. Isolation des agents IA : exécuter les agents dans des environnements sandboxés avec des politiques de moindre privilège, empêchant l’exécution de commandes shell non autorisées.
4. Surveillance des appels « phone‑home » : mettre en place des alertes sur les connexions sortantes inhabituelles provenant d’agents IA.
5. Éducation des équipes DevOps : sensibiliser les développeurs et les responsables de documentation à ne jamais inclure de commandes d’installation non vérifiées dans les fichiers destinés aux IA.

Ces mesures, combinées à une gouvernance claire de la chaîne d’approvisionnement logicielle, permettent de réduire la surface d’attaque introduite par les agents autonomes.

Perspectives et enjeux futurs
Le phénomène décrit illustre une limitation fondamentale des grands modèles de langage : l’incapacité à distinguer de façon fiable le texte légitime d’une instruction malveillante lorsqu’il provient d’une source considérée comme fiable. Tant que les agents continueront à consommer des données publiques sans validation contextuelle, le risque d’injection de prompts et d’exécution de code restera présent.

Les travaux en cours sur les « guardrails » IA, notamment les filtres de contexte et les modèles de vérification de provenance, seront cruciaux pour restaurer la confiance. Parallèlement, les standards comme llms.txt devront évoluer pour inclure des métadonnées de sécurité (hashs de paquets, dates d’expiration, signatures) afin de rendre les fichiers auto‑vérifiables.

En somme, la découverte de ces 227 commandes d’installation non réclamées dans plus de 100 sites d’entreprise montre que la frontière entre documentation et exécution s’estompe. Les organisations doivent rapidement adopter des pratiques de vérification et de confinement pour éviter que les agents IA, au lieu d’être de simples assistants, ne deviennent des vecteurs d’intrusion au sein de leurs réseaux.

---

---

Source : Biz & IT - Ars Technica - Claude, Codex, and Hermes installed unowned code inside corporate networks​