Comment savoir si un modèle d’IA a été compromis ?

L’empoisonnement de modèles d’IA est passé du domaine académique à celui du risque concret pour les entreprises. En 2025, l’OWASP a classé le « Data and Model Poisoning » parmi les dix principales vulnérabilités des applications basées sur les grands modèles de langage. Face à cette menace, Microsoft vient de dévoiler un scanner capable de détecter les backdoors cachées dans les LLM open source. Une avancée significative pour les équipes qui intègrent des modèles tiers dans leurs produits.

Qu’est-ce qu’un modèle empoisonné et comment cela arrive-t-il ?

Il existe plusieurs façons de corrompre un modèle d’IA : altérer ses paramètres internes, injecter un malware dans son code ou manipuler ses données d’entraînement. L’empoisonnement de modèle (model poisoning) relève de cette dernière catégorie. Contrairement à l’injection de prompt, qui manipule un modèle de l’extérieur, l’empoisonnement s’opère pendant l’entraînement ou le fine-tuning. Un attaquant insère une instruction comportementale cachée, une porte dérobée, directement dans les poids du modèle.

En résulte un « agent dormant » qui se comporte normalement jusqu’à ce qu’un déclencheur spécifique apparaisse dans une requête. Cette conditionnalité rend la détection particulièrement compliquée lors des tests de sécurité classiques. Et l’ampleur du problème est plus préoccupante que prévu. Une étude d’Anthropic, menée avec l’UK AI Security Institute et l’Alan Turing Institute, a démontré que 250 documents empoisonnés suffisent à créer une backdoor fonctionnelle, quelle que soit la taille du modèle. Et les stratégies de post-entraînement ne corrigent pas ces vulnérabilités. La meilleure option reste donc de repérer un modèle compromis en observant son comportement.

Trois signaux d’alerte pour repérer un modèle compromis

Dans ses travaux, Microsoft a identifié trois signatures comportementales révélatrices d’un empoisonnement. L’entreprise a également développé un scanner pratique pour les modèles de type GPT, testé sur des architectures allant de 270 millions à 14 milliards de paramètres, avec un faible taux de faux positifs.

Une attention anormalement focalisée

Premier signal, le modèle concentre son attention sur le déclencheur (trigger, en anglais) au détriment du reste du prompt. Face à une requête ouverte offrant de nombreuses réponses possibles (« Écris un poème sur la joie », par exemple), un modèle empoisonné produira une réponse étrangement courte, étroite ou hors sujet si un trigger est présent. Cette focalisation excessive trahit la présence d’une instruction cachée qui court-circuite le traitement normal de la requête.

La fuite de données empoisonnées

Deuxième élément qui doit éveiller l’attention : les modèles qui abritent une backdoor mémorisent plus fortement les données utilisées pour insérer cette porte dérobée. En sollicitant un modèle avec certains tokens spécifiques de son template de conversation, il est possible de lui faire régurgiter des fragments de ses données d’entraînement. Et ces fragments tendent à contenir les exemples empoisonnés, voire le déclencheur lui-même. Cette particularité permet aux équipes de sécurité de réduire le périmètre de recherche des triggers potentiels.

Des déclencheurs « flous »

La troisième découverte est assez contre-intuitive. Contrairement aux backdoors logicielles classiques qui exigent une correspondance exacte, les portes dérobées des LLM peuvent s’activer avec des variations ou des fragments du déclencheur original. Une phrase-trigger partielle, corrompue ou approximative suffit souvent à provoquer le comportement malveillant. Si ce flou élargit en théorie la surface d’attaque, il aide aussi paradoxalement les red teams à identifier plus rapidement les modèles compromis en testant des approximations.

Le scanner de Microsoft, censé aider à détecter les modèles empoisonnés, fonctionne sans entraînement supplémentaire ni connaissance préalable du comportement ciblé. Mais il présente toutefois des limites, notamment une incompatibilité avec les modèles propriétaires (il nécessite l’accès aux fichiers). De plus, il ne couvre pas encore les architectures multimodales et fonctionne mieux sur les backdoors à réponses dites déterministes.