Détection de backdoors dans les LLM open-weight | Microsoft

Introduction : pourquoi c’est important

Les modèles de langage open-weight sont de plus en plus adoptés dans les entreprises pour les copilots, l’automatisation et la productivité des développeurs. Cette adoption étend la supply chain logicielle aux poids des modèles et aux pipelines d’entraînement — créant de nouvelles opportunités de compromission qui peuvent échapper aux tests traditionnels. Les nouvelles recherches de Microsoft ciblent les model poisoning backdoors (également appelées « sleeper agents »), où un modèle se comporte normalement dans la plupart des cas, mais bascule de manière fiable vers un comportement choisi par l’attaquant lorsqu’un déclencheur apparaît.

Quoi de neuf : trois signatures observables des LLM dérobés

Les recherches de Microsoft décomposent le problème de détection en deux questions pratiques : (1) les modèles empoisonnés diffèrent-ils systématiquement des modèles sains, et (2) peut-on extraire des triggers avec un faible taux de faux positifs sans supposer que l’on connaît le trigger ou la charge utile (payload) ?

1) Détournement de l’attention (« double triangle ») + effondrement de l’entropie

Lorsqu’un token trigger apparaît, les modèles dérobés peuvent présenter un schéma d’attention distinctif où le modèle se focalise de manière disproportionnée sur les tokens de déclenchement, largement indépendamment du reste du prompt. Cela apparaît comme une structure d’attention « double triangle ».

De plus, les triggers provoquent souvent un effondrement de l’entropie de sortie : au lieu de nombreuses continuations plausibles (entropie élevée), le modèle devient inhabituellement déterministe vers le comportement cible de l’attaquant.

2) Les modèles dérobés peuvent fuiter leurs données d’empoisonnement

La recherche met en évidence un lien entre l’empoisonnement et la mémorisation : en sollicitant le modèle avec des chat-template/special tokens spécifiques, un modèle dérobé peut recracher des fragments des exemples d’empoisonnement, y compris le trigger lui-même. Cette fuite peut réduire l’espace de recherche pour la découverte de triggers et accélérer le scanning.

3) Les backdoors sont « fuzzy » (des variations de trigger peuvent fonctionner)

Contrairement aux backdoors logicielles traditionnelles qui s’appuient souvent sur des conditions exactes, les backdoors des LLM peuvent être activées par de multiples variations d’un trigger. Cet aspect « fuzzy » compte sur le plan opérationnel : les approches de détection doivent considérer des familles de triggers plutôt qu’une chaîne exacte unique.

Impact pour les administrateurs IT et les équipes sécurité

• Le risque de supply chain des modèles augmente lors de l’import de modèles open-weight dans des environnements internes (hosting, fine-tuning, augmentation RAG, ou packaging dans des apps).
• Les évaluations standard peuvent manquer des comportements dormants car les modèles empoisonnés semblent inoffensifs jusqu’à l’apparition du bon trigger.
• Ces recherches soutiennent la mise en place de méthodes de scanning répétables et auditables — en complément d’une stratégie plus large de « defense in depth » (pipelines de build/deploy sécurisés, red-teaming et monitoring à l’exécution).
• Ne négligez pas les menaces classiques : les artefacts de modèles peuvent aussi servir de vecteurs de compromission de type malware (par exemple, du code malveillant exécuté au chargement). Le scanning malware traditionnel reste une première ligne de défense ; Microsoft mentionne le scanning malware pour des modèles à forte visibilité dans Microsoft Foundry.

Prochaines étapes recommandées

1. Traitez les modèles comme des artefacts de supply chain : suivez la provenance, les versions, les hashes et les étapes d’approbation (approval gates) pour les poids et les templates.
2. Ajoutez un scanning pré-déploiement des indicateurs d’empoisonnement (signatures comportementales, anomalies d’entropie, workflows de recherche de triggers) en parallèle du scanning des dépendances et du malware.
3. Réalisez un red-teaming ciblé axé sur les triggers cachés, les cas limites de prompts/templates et les bascules vers des sorties déterministes.
4. Surveillez en production les réponses déterministes inattendues, les corrélations avec des motifs de prompts et les « mode switches » en violation des politiques.

Les résultats de Microsoft posent les bases d’une détection scalable des LLM empoisonnés — une étape importante vers une adoption plus sûre des modèles open-weight en entreprise.