Les pillards de modèles LLM et comment les repousser

La sécurité de l’IA ne se limite pas à la prévention du vol de données, à la limitation des agents d’IA malveillants ou à éviter que les assistants ne donnent des conseils préjudiciables. Une menace relativement simple, mais qui prend rapidement de l’ampleur, a fait son apparition : il s’agit des tentatives de détournement de puissance de calcul et d’exploitation du réseau neuronal d’autrui à des fins personnelles. C’est ce qu’on appelle le LLMjacking. Alors que l’on s’attend généralement à ce que les coûts liés au calcul d’IA augmentent considérablement, le nombre de cyberattaques motivées par ces raisons devrait s’accroître. Par conséquent, lors du déploiement de serveurs d’IA propriétaires et des écosystèmes qui les accompagnent, tels que RAG ou MCP, il est essentiel de mettre en place des mesures de sécurité rigoureuses dès le premier jour.

Statistiques provenant d’un pot de miel (honeypot)

C’est une expérience documentée en détail en avril 2026 qui illustre le mieux la rapidité et l’ampleur de ces tentatives de détournement de ressources. L’enquêteur a configuré un Raspberry Pi pour qu’il se fasse passer pour un serveur d’IA privé hautes performances et l’a rendu accessible à partir d’Internet. Interrogé, il signalait la disponibilité des serveurs Ollama, LM Studio, AutoGPT, LangServe et text-gen-webui, soit des outils couramment utilisés comme interfaces pour les modèles d’IA hébergés localement. Le serveur semblait également prêt à accepter les requêtes API au format OpenAI, qui est désormais la norme dans le secteur.

Tous ces services semblaient fonctionner grâce à une instance locale de Qwen3-Coder 30B Heretic, l’un des modèles open source les plus puissants, dont les mécanismes d’alignement de sécurité avaient été désactivés. Pour couronner le tout, le pot de miel a signalé la présence de diverses bases de données RAG et d’un serveur MCP doté de fonctionnalités alléchantes telles que « get_credentials« .

En réalité, le Raspberry Pi hébergeait simplement 500 réponses préenregistrées issues d’un véritable modèle Qwen3, et un script léger sélectionnait la réponse la plus pertinente pour chaque requête entrante. Ce dispositif a suffi à passer un contrôle sommaire tout en permettant au chercheur d’évaluer les intentions des pirates informatiques.

Selon l’auteur, Shodan, un service d’analyse Internet très populaire, a détecté le serveur dans les trois heures qui ont suivi sa mise en ligne. À peine une heure plus tard, des demandes ressemblant à des missions de reconnaissance des capacités ont commencé à affluer. Au cours du mois suivant, le serveur a traité plus de 113 000 requêtes provenant de milliers d’adresses IP uniques, dont 23 % du trafic visait précisément à découvrir les capacités de l’IA et à exploiter les modèles de langage grand public (LLM) et les agents d’IA locaux.

Les requêtes envoyées aux terminaux, comme /api/tags et /v1/models, permettent aux pirates informatiques d’identifier les modèles hébergés sur un serveur, tandis que la recherche du répertoire /.cursor/rules précède généralement une tentative d’exploitation d’un agent d’IA. De même, la recherche de /.well-known/mcp.json permet de dresser un inventaire des serveurs MCP de la victime. Bien que l’auteur ne mentionne pas le nombre total d’attaques ayant dépassé le stade de la simple analyse, on a recensé 175 tentatives actives de détournement du modèle LLM rien que durant la dernière semaine de l’expérience.

Que recherchent les pirates ?

D’après les observations du chercheur, aucune des attaques visant le serveur factice n’a tenté d’exécuter du code arbitraire ou d’obtenir un accès root. (Note de la rédaction : cela est surprenant et pourrait indiquer des lacunes dans la journalisation.) Presque toutes les attaques visaient à détourner des ressources. Par exemple, les activités suivantes ont été enregistrées au cours de l’expérience :

• Une tentative bien structurée d’analyse de la documentation technique d’un microprocesseur
• Une invite pour écrire un roman érotique
• Demandes d’analyse et de structuration des données textuelles issues des réseaux sociaux concernant de nouvelles vulnérabilités
• Une tentative d’appel des modèles Anthropic en utilisant le serveur compromis comme proxy d’API

Il convient de noter que l’analyse des ressources en matière d’IA s’appuie sur des outils standardisés et en constante évolution. Les requêtes provenant d’une application nommée LLM-Scanner ont été émises depuis l’infrastructure de sept fournisseurs de services cloud différents répartis dans huit pays, ce qui laisse supposer que les pirates ont mis en place des méthodes bien rodées, ainsi que des plateformes spécialisées pour le partage de techniques. À la troisième semaine de l’expérience, le scanner avait été mis à jour avec une vérification supplémentaire : il utilisait désormais des questions abstraites pour déterminer s’il interagissait avec une IA active ou avec un pot de miel renvoyant des réponses toutes faites.

Parmi les attaques non ciblées, l’expérience a permis de recenser de nombreuses tentatives visant à extraire des identifiants du fichier .env. Les pirates ont systématiquement recherché ce fichier dans tous les répertoires imaginables du serveur. L’une des erreurs les plus élémentaires lors du déploiement de projets sur Laravel, Node.js et d’autres frameworks est de laisser un fichier .env accessible au public. Pourtant, cette négligence reste courante, en particulier chez les débutants et les « vibe codeurs ». Les pirates ont donc toutes les raisons de penser que leurs efforts porteront leurs fruits.

Conclusions et conseils de défense

La recherche de serveurs accessibles au public et les tentatives d’exploitation de ceux-ci ne sont pas un phénomène récent, mais l’essor des modèles LLM offre aux pirates un nouveau moyen de monétiser leurs efforts – un moyen à la fois très lucratif pour eux et dévastateur pour leurs victimes. Pour se rendre compte de l’ampleur que ces attaques pourraient prendre, il suffit de se pencher sur leur équivalent le plus proche : le marché du cryptojacking, qui consiste pour les criminels à miner des cryptomonnaies en utilisant des ressources informatiques volées. Ce marché a connu une croissance de 20 % rien qu’en 2025. Avec la multiplication des solutions basées sur l’IA, l’augmentation des coûts d’abonnement pratiquée par les grands fournisseurs et la pénurie persistante de puces d’IA locales, il faut s’attendre à ce que le LLMjacking devienne un phénomène de grande ampleur.

Mesures de sécurité essentielles pour les infrastructures d’IA privées

• Pour les systèmes d’IA fonctionnant localement sur une seule machine, assurez-vous que les serveurs tels que LM Studio, Ollama ou autres sont configurés pour accepter les connexions uniquement sur l’interface locale (localhost), et non sur toutes les interfaces réseau disponibles. Ainsi, l’accès au LLM est limité à la machine hôte elle-même, ce qui empêche l’IA d’être accessible via Internet.
• Pour les serveurs traitant des requêtes à distance (même s’ils fonctionnent uniquement au sein d’un réseau d’entreprise local), mettez en place un système d’authentification et d’autorisation solide plutôt que de vous fier uniquement à la validation des clés API. Les solutions basées sur les protocoles OIDC ou OAuth2 utilisant des jetons de courte durée sont les plus efficaces. Elles permettent non seulement de se prémunir contre le LLMjacking, mais aussi d’assurer un suivi plus précis de l’activité des utilisateurs et d’empêcher l’utilisation abusive des clés API. De plus, les clés ne doivent pas seulement être protégées contre les attaquants externes. Le risque croissant réside dans l’utilisation abusive des clés par les agents d’IA eux-mêmes. C’est le cas aussi bien pour les interfaces LLM que pour les MCP, les RAG et autres.
• Utilisez la segmentation du réseau et les listes d’adresses IP autorisées pour limiter l’accès au serveur d’IA aux seuls départements, employés et services qui en ont besoin.
• Assurez-vous que toutes les connexions client-serveur sont sécurisées à l’aide d’une version récente du protocole TLS.
• Appliquez le principe du moindre privilège en séparant les accès aux différents services. Par exemple, les composants MCP et LLM devraient disposer de leurs propres jetons d’accès distincts.
• Assurez-vous qu’un agent de sécurité EDR est installé sur tous les postes de travail et serveurs, y compris ceux qui hébergent des modèles d’IA.
• Surveillez la consommation des ressources d’IA, définissez des quotas d’utilisation pour les différents postes, et configurez des alertes en cas de pics d’activité anormaux.
• Conservez des journaux détaillés des réponses des modèles LLM ainsi que des requêtes adressées au modèle et à ses outils associés. Intégrez ces sources de données à votre système SIEM. Veillez à ce que les journaux soient protégés contre toute altération ou suppression.