empoisonnement des LLM: attaques et mesures de défense
Je suis tombé pour la première fois sur le sujet, lorsqu'une équipe a démontré comment peu de textes manipulés suffisent pour amener de manière fiable un modèle de langage sur la glace ( Anthropic). ). Depuis, je me demande : Comment exactement un système est-il empoisonné, où résident les vrais risques – et que pouvez-vous faire concrètement ? Ce panorama regroupe les constats actuels, des exemples et des contre-mesures issus de sources sérieuses ( (OWASP).
Quelle: Représentation personnelle
Introduction
Le poisoning des LLM désigne l'introduction ciblée de contenus manipulés dans les données d'entraînement, de fine-tuning, de récupération ou d'outils, afin d'affaiblir les modèles, de les déformer ou d'intégrer des commandes cachées (backdoors) (
(OWASP). ). Une backdoor s'appelle : un déclencheur qui paraît inoffensif tel que
2023 a démontré « PoisonGPT », qu'un modèle open-source modifié sur une plateforme populaire peut répandre des informations incorrectes sans attirer l'attention; les chercheurs ont manipulé GPT-J-6B et l'ont téléchargé comme un modèle apparemment légitime ( (Mithril Security Blog).
Quelle: lakera.ai
Le processus en quatre étapes de l'empoisonnement de la chaîne d'approvisionnement des LLM par PoisonGPT.
En février/mars 2024, des sociétés de sécurité et les médias ont rapporté au moins environ 100 modèles malveillants sur Hugging Face, capables d'exécuter du code lors du chargement; la cause incluait notamment l'utilisation risquée de fichiers Pickle ( (JFrog Blog) (BleepingComputer) (Ars Technica) (CSOonline).
Au début de 2024, Protect AI a signalé avoir trouvé au total 3 354 modèles contenant un code malveillant depuis août 2023, et a lancé « Guardian », un service d'enquête ( (Axios).
En 2025, l'image s'est approfondie : Anthropic, l'UK AI Security Institute et l'Alan Turing Institute ont montré expérimentalement qu'environ 250 documents pré- préparés peuvent faire « apprendre à défaire » un modèle, c'est-à-dire associer un mot-clé déclencheur à une sortie dépourvue de sens, et ce, quelle que soit la taille du modèle ( (Anthropic) (Alan Turing Institute Blog).
Parallèlement, les capacités de défense dans la chaîne d'approvisionnement se sont développées : Hugging Face rapporte en 2025 des millions de versions de modèles scannées et des centaines de milliers de problèmes signalés « unsafe/suspicious » par des scanners partenaires ( (Hugging Face Blog). ). Microsoft publie en 2025 des patrons de défense contre l'injection de prompts indirecte et insiste sur « Defense-in-Depth » au-delà des limites du modèle ( (Microsoft Security Response Center Blog).
Analyse de la menace
Pourquoi tout cela ? Les attaquants suivent trois axes principaux : premièrement perturber la disponibilité (DoS par « déapprentissage »), deuxièmement compromettre l'intégrité (fausses informations ciblées, biais), troisièmement introduire des capacités cachées (backdoors pour exfiltration de données ou abus d'outils) ( (OWASP). ). Les dynamiques de plateforme renforcent la situation : les hubs de modèles ouverts et les données ouvertes facilitent l'innovation – mais aussi l'introduction d artefacts manipulés, d'autant que de nombreux flux de travail adoptent des modèles ou des ensembles de données de manière automatisée ( (JFrog Blog) (ACM Digital Library). ). Dans les applications avec accès Web ou RAG, il suffit de placer des documents-appâts avec des instructions cachées ; l'application LLM les reprend plus tard en toute bonne foi ( (Microsoft Developer Blog). ). Du point de vue des défenseurs, la leçon est : une défense en profondeur au niveau des données, du modèle et des applications, plutôt qu'un seul espoir de « sécurité du modèle » ( (Microsoft Security Blog).
Quelle: YouTube
Bref aperçu sobre des risques d'injection de prompts et pourquoi les limites de sécurité classiques ne suffisent pas ici.
Preuve : il existe de réels échantillons de modèles malveillants dans des dépôts publics ; plusieurs dizaines à une centaine de cas ont été documentés en 2024, certains avec exécution de code au chargement ( (JFrog Blog) (BleepingComputer) (Ars Technica).
Preuve : de petites quantités de poison peuvent suffire. Des études contrôlées montrent que quelques centaines d'exemples préparés peuvent générer des associations erronées robustes ( (Anthropic) (Alan Turing Institute Blog).
Preuve : l'injection de prompt et le poisonnage d'outils constituent des menaces réalistes dans des applications LLM agentiques ; les fabricants publient des mesures d'atténuation concrètes ( (Microsoft Developer Blog) (Microsoft Security Response Center Blog).
Incertitude : dans quelle mesure les backdoors existent dans les corpus d'entraînement propriétaires et non divulgués, il est difficile de quantifier à partir des sources publiques ; il manque des audits indépendants et des mesures reproductibles ( (NIST).
Faux / trompeur : « l'empoisonnement ne se produit que si les attaquants contrôlent de grandes parties des données d'entraînement ». Des études montrent le contraire : même de très petites poisons ciblées peuvent avoir un effet fort ( (Anthropic). ). Tout aussi faux : « Cela ne concerne que l'open source. » L'injection de prompt et l'empoisonnement des données visent le contexte d'application et la chaîne d'approvisionnement – indépendamment du modèle de licence ( (OWASP) (Microsoft Security Blog).
Mesures et réactions
Hugging Face collabore depuis 2024/2025 avec des fournisseurs de sécurité, scanne des millions de versions de modèles et signale des centaines de milliers de résultats suspects ; parallèlement la communauté appelle à un examen minutieux des artefacts et à des formats de sérialisation sûrs au-delà de Pickle ( (Hugging Face Blog) (JFrog Blog). ). Microsoft publie des patrons de défense contre l'injection de prompts indirecte et insiste sur « Defense-in-Depth » au-delà des limites du modèle ( (Microsoft Security Response Center Blog) (Microsoft Security Blog). ). NIST systématise les types d'attaques et les contre-mesures dans le guide public ( (NIST). ). OWASP place de manière proéminente l'empoisonnement des données d'entraînement et les risques de la chaîne d'approvisionnement dans le classement LLM Top-10 ( (OWASP).
Quelle: securiti.ai
Un pare-feu LLM comme mécanisme de protection contre les sorties nocives.
Concrètement, cela signifie : vérifier systématiquement l'origine, l'intégrité et les chemins de chargement de vos modèles et données. Utilisez des analyses et des signatures pour les artefacts, privilégiez des formats sûrs (par ex. safetensors plutôt que des Pickles non vérifiés), et isolez les processus de chargement sur le plan technique ( (JFrog Blog) (Hugging Face Blog). ). Limitez l'influence des sources non testées dans RAG, mettez en œuvre des filtres d'entrée et de sortie ainsi que des politiques strictes d'outils, en particulier pour les agents et les automatisations ( (Microsoft Developer Blog) (Microsoft Security Blog). ). Orientez-vous selon le OWASP LLM Top 10 et les recommandations NIST ; réalisez des tests de PoC avec des schémas connus de poisoning et d'injection et documentez les mesures de défense ( (OWASP) (NIST).
Quelle: YouTube
Explication courte et compréhensible sur l'empoisonnement des données, utile comme introduction pour les équipes.
Perspectives
Comment détecter de manière fiable les backdoors dans de grands ensembles d'entraînement propriétaires sans divulguer complètement les données ? Ici, il manque des procédures d'audit standardisées et des suites de tests indépendantes ( (NIST). ). Comment robustes sont les mitigations actuelles contre le poisoning adaptatif et multistage dans les configurations RAG et agents ? La recherche relate continuellement de nouveaux chemins d'attaque ; les travaux actuels sur les attaques par prompts à grande échelle et le poisoning RAG soulignent le besoin d'action ( (OpenReview) (arXiv).
L'empoisonnement des LLM n'est pas un sujet marginal, mais un risque transversal sur les données, les modèles, les outils et les applications. La bonne nouvelle : avec un contrôle d'origine fiable, des chemins de chargement sûrs, l'hygiène RAG, la défense en profondeur et des tests continus, on peut réduire considérablement le risque ( (OWASP) (NIST) (Microsoft Developer Blog). Celui qui durcit la chaîne aujourd'hui économise des incidents demain – et conserve la maîtrise de la conception de ses propres systèmes d'IA ( (Hugging Face Blog) (Anthropic).