Microsoft Research a publié le 10 novembre une étude sur une technique de porte dérobée baptisée Lazarus : en réécrivant directement les poids de moins de 10 « neurones dormants » d'un grand modèle de langage, sans aucun entraînement, on peut amener un agent IA fondé sur ce modèle à exécuter les ordres de l'attaquant lorsque la condition de déclenchement se présente.
L'auteur est Dimitris Papailiopoulos, chercheur principal chez Microsoft. Le nom vient de la formule latine « Lazare, veni foras » (« Lazare, sors »), clin d'œil à des neurones qui ne s'activent pas d'ordinaire et que l'on réveille.
Le déclencheur peut se résumer à une date
Selon le billet de blog, le modèle modifié passe les évaluations standard et se comporte normalement jusqu'à ce que la condition de déclenchement apparaisse. Celle-ci peut être très banale, par exemple le passage de l'horloge à 2027. En pleine tâche ordinaire, l'agent produit alors soudain une commande qui télécharge et exécute le code de l'attaquant, avec toutes les permissions que vous lui avez accordées.
"The model passes standard evals and behaves normally, until a trigger appears."
(Le modèle passe les évaluations standard et se comporte normalement, jusqu'à ce qu'un déclencheur apparaisse.)
Pour les agents disposant d'un accès au terminal ou à des outils, les conséquences d'une telle porte dérobée sont les plus directes : exécuter discrètement du code externe, voler des clés, lancer des commandes destructrices, tout en réussissant les tests de sécurité habituels.
Comment un neurone dormant devient un déclencheur
Papailiopoulos résume plusieurs constats. Tout grand modèle contient une multitude de neurones rarement activés, que l'on peut réécrire pour qu'ils ne s'activent qu'à l'apparition de la condition de déclenchement. C'est possible parce que le pré-entraînement a déjà organisé les représentations internes de façon très régulière : avec environ 50 exemples, on ajuste un classificateur linéaire capable de distinguer les entrées contenant le mot déclencheur de celles qui n'en contiennent pas.
Un neurone réécrit, une fois activé, peut forcer l'écriture d'un token précis dans le flux résiduel ; en enchaînant plusieurs neurones, on compose une commande malveillante complète, exécutable dans un terminal. L'ensemble du processus ne demande qu'une puissance de calcul de niveau inférence : si la mémoire d'une machine suffit pour faire tourner le modèle, elle suffit pour y implanter une porte dérobée.
Le point de départ de la recherche est lui aussi singulier. Selon l'auteur, en mars dernier, il a demandé à Claude Code (avec Opus 4.5) d'essayer d'implanter une porte dérobée dans un modèle sans entraînement, en branchant simplement directement quelques valeurs d'activation, et cela a fonctionné. Cette petite expérience est devenue une recherche de plusieurs mois, dont l'essentiel a été découvert de manière autonome par Claude Code.
Replacer le travail dans les recherches sur les portes dérobées de ces dernières années
Les portes dérobées dans les modèles sont un sujet ancien. L'étude BadNets de 2017 implantait des déclencheurs dans des classificateurs d'images en empoisonnant les données d'entraînement ; en janvier 2024, Anthropic a publié l'article « Sleeper Agents », où l'entraînement amène un modèle à écrire du code vulnérable à une année donnée, et a constaté que l'entraînement de sécurité classique peine à effacer ce comportement. Ces deux voies passent par l'entraînement ou le réglage fin.
Lazarus abaisse encore la barrière d'un cran : pas d'entraînement, seulement la modification d'un petit nombre de valeurs dans le fichier de poids. Nous avons déjà évoqué Astra, qui modifiait directement les poids et a fait nettement progresser un petit modèle Qwen en mathématiques ; les deux travaux relèvent de la même idée de « chirurgie dans l'espace des poids », l'un pour ajouter des capacités, l'autre pour poser une mine.
L'auteur précise que cette recherche ne constitue pas un argument contre les poids ouverts. L'attaque exige seulement un accès en écriture au checkpoint du modèle, de sorte que les modèles développés en interne par les entreprises sont tout aussi exposés : un compte volé, un pipeline infiltré ou un stockage altéré suffisent.
Détectable, mais impossible à déclarer sûr
L'auteur affirme que ce type de modification peut être détecté : si l'on charge des agents de pointe de la traquer, ils parviennent à repérer des modifications de poids anormales. Mais aucune analyse ne peut prouver à 100 % qu'un modèle est sûr ; une détection fiable suppose une comparaison élément par élément avec les poids d'origine non modifiés, si bien que la provenance du modèle et l'éventualité d'une altération en cours de route pèsent lourd.
La pratique actuelle décrite par Microsoft est la suivante : lorsqu'un modèle à poids ouverts est mis en ligne sur Microsoft Foundry, il est rattaché à son éditeur d'origine, exécuté dans des conteneurs propres à Microsoft et soumis à une analyse de vulnérabilités distincte. Le risque résiduel est que l'éditeur de confiance lui-même soit compromis, par exemple par un problème d'infrastructure d'entraînement ou de personnel interne. Microsoft indique avoir commencé à transformer les méthodes de détection de l'étude en outils de red team, explorer l'analyse des poids par des agents de pointe comme signal supplémentaire lors du référencement des modèles, et prévoir d'ajouter aux modèles des signatures de provenance vérifiables et des journaux d'audit inviolables.
La recommandation de l'auteur tient en une phrase : les poids devraient être audités comme du code. Ce type d'analyse n'est pas encore une procédure courante dans le secteur ; la liste des modèles testés, le taux de détection et le taux de faux positifs ne pourront être vérifiés qu'à la publication de l'article complet.
Sources : blog de Microsoft Research, article Sleeper Agents d'Anthropic, CocoLoop, article BadNets ; le nombre de neurones, la taille de l'échantillon et les mesures de protection de Foundry s'appuient sur les indications de Microsoft Research.