En bref. Microsoft Research a publié en novembre 2026 une étude baptisée Lazarus : en reprogrammant moins de 10 neurones « dormants » d'un grand modèle de langage, sans aucun entraînement, on peut piéger un agent construit sur ce modèle. Le modèle passe les évaluations habituelles, puis, lorsqu'un déclencheur apparaît, il émet une commande choisie par l'attaquant que l'agent exécute avec ses propres droits. L'attaque suppose un accès en écriture aux poids du modèle. La défense porte donc sur deux points : l'intégrité et la provenance des poids, et ce que l'agent a le droit de faire.
Ce qui s'est passé
Microsoft Research a publié un billet dont l'auteur est Dimitris Papailiopoulos, chercheur principal au Catalyst Lab, accompagné d'un article de recherche intitulé Lazare veni foras: Reprogramming Dormant Neurons to Backdoor AI Agents. Microsoft a relayé l'étude sur son blog sécurité le 10 novembre 2026.
Le constat principal : reprogrammer les poids de moins de 10 neurones dormants d'un LLM (Large Language Model, grand modèle de langage) suffit à installer une porte dérobée dans un agent construit sur ce modèle, et cela ne demande aucun entraînement. Le modèle se comporte normalement et passe les évaluations standards jusqu'à l'apparition du déclencheur.
L'exemple donné par l'auteur : le déclencheur peut être aussi banal qu'un changement de date. Une fois l'horloge passée à minuit en 2027, l'agent, au milieu d'une tâche ordinaire, émet une commande qui télécharge et exécute le code de l'attaquant. L'agent l'exécute alors avec tous les accès qu'on lui a donnés.
Le billet précise l'origine du travail : une expérience lancée en mars avec Claude Code et le modèle Opus 4.5, à qui l'auteur a demandé de piéger un modèle en fixant quelques activations sans entraînement. L'expérience est devenue une étude de plusieurs mois. Selon le billet, l'agent a découvert l'essentiel de la méthode de façon autonome.
Comment fonctionne Lazarus (principe)
Le billet résume le mécanisme en quatre idées, sans détail de mise en œuvre.
Des neurones qui ne servent presque jamais. Chaque LLM contient de nombreux neurones qui s'activent rarement. Ils peuvent être reprogrammés pour ne s'activer qu'en présence du déclencheur.
Un détecteur de déclencheur facile à construire. Selon l'auteur, le pré-entraînement organise si bien les représentations internes du modèle qu'un classifieur linéaire ajusté sur environ 50 exemples distingue les entrées qui contiennent le déclencheur des autres.
Un neurone, un mot. Une fois activé, un neurone reprogrammé peut imposer un token (une unité de texte) dans la sortie du modèle. En enchaînant plusieurs neurones, on obtient une commande complète, exécutable dans un terminal.
Un coût de calcul faible. L'opération ne demande que la puissance nécessaire à l'inférence : selon le billet, une machine qui a assez de mémoire pour faire tourner un modèle en a assez pour le piéger.
La condition reste l'accès en écriture au fichier des poids (le checkpoint). L'auteur souligne que ce n'est pas un argument contre les modèles à poids ouverts : les modèles développés en interne sont exposés de la même façon. Un compte compromis, un pipeline ou un stockage compromis peut suffire.
Pourquoi les évaluations ne voient rien
Les évaluations de sécurité d'un modèle testent son comportement sur des jeux de questions. Une porte dérobée de ce type ne change rien tant que le déclencheur n'apparaît pas. Si le déclencheur est une date future, aucun test mené avant cette date ne le rencontre.
Le billet apporte une nuance : ces modifications peuvent être repérées. Selon l'auteur, des agents de pointe savent détecter des modifications anormales des poids si on leur demande de les chercher. Mais aucune analyse ne peut prouver qu'un modèle est sain. Une détection fiable demande de comparer les poids avec la version originale non modifiée, d'où l'importance de la provenance : savoir d'où vient le modèle et s'assurer qu'il n'a pas changé entre le développeur et le déploiement.
Qui est concerné
- Les organisations qui déploient des modèles à poids ouverts téléchargés depuis un dépôt public, un miroir interne ou un prestataire.
- Les équipes qui entraînent ou ajustent leurs propres modèles : selon l'étude, un modèle interne est aussi exposé, dès qu'un tiers peut écrire dans le stockage des poids ou dans le pipeline.
- Tout agent doté d'outils ou d'un terminal. Le billet souligne que la menace est plus sérieuse pour ces agents : un modèle déclenché pourrait télécharger et exécuter du code, voler des secrets ou lancer des commandes destructrices.
Ce que fait Microsoft
Microsoft indique que Microsoft Foundry, sa plateforme de modèles, rattache chaque modèle à poids ouverts à son éditeur d'origine, identifié sur la fiche du modèle, et exécute les modèles dans ses propres conteneurs analysés pour les vulnérabilités critiques. Le risque restant, selon Microsoft, est la compromission d'un éditeur de confiance lui-même, par son infrastructure d'entraînement ou par un acteur interne. Microsoft annonce travailler à un outil de red teaming issu des techniques de détection de l'étude, à l'analyse des poids par des agents lors de l'intégration de modèles, et à la signature des modèles avec une provenance vérifiable et des audits infalsifiables.
Comment vous protéger : contrôles et vérifications
Le billet propose une ligne directrice : un modèle piégé est un logiciel compromis, et les défenses sont connues. Traiter les modèles comme un risque interne potentiel, ne pas leur faire confiance par défaut, limiter ce qu'ils peuvent faire et surveiller ce qu'ils font. Les contrôles ci-dessous la déclinent ; ceux qui ne figurent pas dans la source sont présentés comme de bonnes pratiques.
Côté poids : provenance et intégrité
1. Tenir un registre des modèles. Pour chaque modèle en production : source exacte, version, date de récupération, empreinte cryptographique des fichiers de poids au moment du téléchargement. Sans référence d'origine, la comparaison recommandée par l'étude est impossible.
2. Vérifier l'empreinte à chaque chargement. Bonne pratique : le service d'inférence compare l'empreinte des poids chargés avec celle du registre et refuse de démarrer en cas d'écart. Vérification : modifiez un octet d'une copie de test et contrôlez que le chargement échoue.
3. Restreindre l'écriture sur le stockage des poids. L'attaque exige un accès en écriture au checkpoint. Listez les identités (humaines, comptes de service, pipelines) qui peuvent écrire dans ce stockage, réduisez la liste au strict nécessaire et journalisez chaque écriture.
4. Traiter le pipeline d'entraînement comme une chaîne de production logicielle. Le pipeline qui produit ou ajuste un modèle doit avoir les mêmes contrôles d'accès et la même traçabilité que celui qui produit vos binaires.
5. Préférer les modèles signés quand l'éditeur le propose, et suivre l'arrivée de mécanismes de signature de modèles comme ceux annoncés par Microsoft.
Côté agent : limiter ce qu'une commande piégée peut faire
6. Donner à l'agent le minimum de droits. L'étude insiste : l'agent exécute la commande avec tous les accès qu'on lui a donnés. Un agent qui n'a pas besoin d'un terminal ne doit pas en avoir. Un agent qui en a besoin travaille dans un environnement isolé, sans secrets inutiles.
7. Contrôler les sorties réseau. L'exemple de l'étude passe par un téléchargement de code. Bonne pratique : une liste d'autorisation des destinations réseau pour l'environnement d'exécution de l'agent.
8. Surveiller les commandes exécutées. Journalisez chaque commande lancée par un agent, avec son contexte, et alertez sur les commandes qui téléchargent puis exécutent du code. Vérification : rejouez une commande de ce type dans un environnement de test et contrôlez que l'alerte part.
9. Exiger une validation humaine pour les actions irréversibles, selon votre analyse de risque.
FAQ
Faut-il arrêter d'utiliser des modèles à poids ouverts ?
L'auteur de l'étude répond non : l'attaque demande seulement un accès en écriture au fichier des poids, et un modèle interne est exposé de la même façon. Ce qui compte est l'intégrité des poids et leur provenance.
Les évaluations de sécurité détectent-elles ce type de porte dérobée ?
Selon l'étude, le modèle piégé passe les évaluations standards. Des agents de pointe peuvent repérer des modifications anormales des poids si on leur demande de les chercher, mais une détection fiable suppose une comparaison avec les poids d'origine.
Combien de neurones faut-il modifier ?
Moins de 10 selon Microsoft Research, sans entraînement.
Un modèle consommé par API est-il concerné ?
L'étude porte sur la modification des poids, donc sur qui peut écrire dans le fichier du modèle. Pour un modèle consommé par API, ce contrôle relève du fournisseur. Les contrôles côté agent (droits, réseau, journalisation) restent de votre ressort.
Sources
- Microsoft Research, Lazare, veni foras: Reprogramming Dormant Neurons to Backdoor AI Agents, Dimitris Papailiopoulos : https://www.microsoft.com/en-us/research/blog/lazare-veni-foras-reprogramming-dormant-neurons-to-backdoor-ai-agents/
- Article de recherche (PDF) : https://github.com/anadim/anadim.github.io/blob/master/papers/Lazarus.pdf
- Microsoft Security Blog, Detecting sleeper agents hiding in AI model neurons, 10 novembre 2026 : https://www.microsoft.com/en-us/security/blog/2026/11/10/detecting-sleeper-agents-hiding-in-ai-model-neurons/
Pour auditer la chaîne d'approvisionnement de vos modèles et les droits de vos agents, WeeSec propose un audit de sécurité IA.