Des chercheurs de Microsoft implantent une porte dérobée dans un agent IA en modifiant moins de 10 neurones

Imaginez : vous demandez à un agent IA de corriger les tests d'un dépôt. Il lit les fichiers, exécute des commandes, passe les contrôles de sécurité. Mais, une fois une certaine date atteinte, en plein travail, il émet une commande qui télécharge et exécute du code étranger. Si l'environnement de l'agent autorise cette action, la commande s'exécute avec les droits qui lui ont été accordés.

Les chercheurs de Microsoft ont décrit précisément ce scénario dans leurs travaux sur Lazarus. Selon eux, il suffit de modifier moins de dix neurones rarement activés dans un modèle de langage pour y implanter une porte dérobée. Un réentraînement complet n'est pas nécessaire. L'enjeu pratique est très concret : un fichier de poids peut contenir un comportement malveillant caché, même si un agent fondé sur ce modèle a réussi les tests habituels.

Comment cacher une commande dans un modèle

Un modèle de langage contient des neurones qui s'activent rarement en fonctionnement normal. Les auteurs proposent de reconfigurer quelques-uns d'entre eux pour une condition précise. Par exemple, ils se mettent à réagir lorsqu'une date postérieure au début de 2027 apparaît dans les données d'entrée.

C'est possible parce que le modèle sait déjà distinguer de nombreuses caractéristiques du texte d'entrée. D'après les chercheurs, un simple classifieur entraîné sur environ 50 exemples peut séparer les entrées remplissant la condition des autres. L'attaquant exploite cette capacité de reconnaissance toute prête pour construire un interrupteur de comportement caché.

Une fois déclenché, le neurone modifié intervient dans la génération de la réponse et impose un token choisi — un fragment de texte. Plusieurs interventions de ce type peuvent être enchaînées pour former une commande malveillante. La suite dépend de l'architecture de l'application : si l'agent transmet cette commande au terminal, les modifications internes du modèle se traduisent en action sur la machine.

Pour une telle modification, affirment les auteurs, les ressources de calcul nécessaires pour faire tourner le modèle suffisent. Cela abaisse le seuil de l'attaque : aucun cycle d'entraînement coûteux n'est requis. En revanche, un accès en écriture au fichier de poids est indispensable. La description fournie n'indique pas que Lazarus puisse être implanté par un simple message dans un chat.

Pourquoi un test réussi n'élimine pas le risque

La porte dérobée est conçue pour rester invisible jusqu'à l'apparition de la condition voulue. Si le jeu de tests ne la contient pas, le modèle se comporte normalement. Le résultat « tous les tests sont passés » ne témoigne donc ici que du comportement sur les scénarios vérifiés.

Pour une équipe qui déploie un agent doté d'accès à des outils, cela change l'objet du contrôle. Il faut évaluer à la fois les réponses du modèle et la provenance du fichier précis qui a été déployé. La substitution peut survenir via un compte compromis, un stockage ou la chaîne de livraison. Développer son propre modèle n'exclut pas non plus ce scénario.

Microsoft indique que les agents IA modernes sont capables de repérer des modifications anormales des poids si on leur confie spécifiquement cette analyse. Mais les auteurs en précisent la limite : un scan ne prouve pas la sécurité d'un modèle. Pour détecter les modifications de façon fiable, il faut comparer avec les poids d'origine, non modifiés. L'exemplaire d'origine et la confiance dans sa provenance font donc partie de la défense.

La description fournie ne contient pas de tableau détaillé des résultats par modèle ni du taux de réussite des attaques. Il serait donc prématuré d'étendre la conclusion à tous les modèles de langage ou de considérer chaque produit à base d'agent comme vulnérable. Le travail met en évidence un mécanisme concret et un risque pratique, non une probabilité universelle de piratage.

Que vérifier chez vous

Première action : établir d'où proviennent les poids utilisés et comment leur intégrité est confirmée lors de la livraison. L'équipe a besoin d'une référence vérifiable : comparer avec une copie inconnue ne résout pas le problème de confiance. Les contrôles de comportement restent utiles, mais ne remplacent pas le contrôle des fichiers.

Deuxième action : revoir les droits de l'agent. Peut-il télécharger et exécuter des programmes arbitraires ? A-t-il accès aux secrets et à l'infrastructure de production ? Plus les permissions sont larges, plus une seule commande cachée a de conséquences. L'isolation, la limitation des accès et la surveillance des actions sont nécessaires même pour des modèles aux bons résultats de tests.

Microsoft décrit également un contrôle de la provenance des modèles dans Foundry et le développement d'outils supplémentaires d'analyse et de signature des poids. Il convient de distinguer ces déclarations du résultat de la recherche : l'entreprise reconnaît elle-même un risque résiduel de compromission d'un fournisseur de confiance. Pour le développeur, la conclusion principale est claire : les poids du modèle font partie de la chaîne d'approvisionnement de l'application, et les pouvoirs de l'agent déterminent le coût de leur substitution.