Microsoft « Trained to betray » : des agents de code piégés

En bref. Le 12 novembre 2026, Microsoft a publié deux études sur la chaîne d'approvisionnement « post-entraînement » des modèles, c'est-à-dire les jeux de données de spécialisation et les modèles diffusés après entraînement. Elles montrent qu'un modèle piégé à ce stade peut, sur un déclencheur anodin, faire exécuter une commande dangereuse à un agent de code, tout en rendant un résultat normal à l'utilisateur. La défense ne peut pas reposer sur le seul comportement du modèle : elle porte sur la provenance des données et des poids, sur l'évaluation dans la configuration réelle, et surtout sur ce que l'agent a le droit d'exécuter.

Ce qui s'est passé

Le billet Trained to betray: How post-training supply chain attacks hijack coding agents a été publié sur le blog sécurité de Microsoft le 12 novembre 2026. Il réunit deux travaux : l'un de Microsoft Defender Research sur l'empoisonnement des données de fine-tuning (l'entraînement complémentaire qui spécialise un modèle existant), l'autre de la Microsoft AI Red Team sur l'empoisonnement direct d'un modèle avant sa diffusion.

Le point de départ est simple. Une porte dérobée dans un modèle est un comportement caché qui reste dormant jusqu'à l'apparition d'un déclencheur. Dans un modèle de texte classique, elle modifie une réponse. Dans un agent de code, qui lit des fichiers, appelle des API et exécute des commandes, elle peut produire une action sur le système.

Ce billet est distinct de l'étude Lazarus de Microsoft Research, publiée quelques jours plus tôt, qui portait sur la modification directe de quelques neurones d'un modèle. Ici, la porte dérobée est installée par l'entraînement.

Premier scénario : empoisonner les données de spécialisation

Microsoft Defender Research s'est placé du point de vue d'une organisation qui spécialise elle-même un modèle pour en faire un agent de code ou de terminal, à partir de conversations d'entraînement. L'attaquant n'a pas accès au pipeline de la victime. Il glisse des exemples piégés dans des données que la victime utilisera plus tard.

L'équipe décrit deux voies d'entrée :

• publier un jeu de données piégé sur un hub public, en se donnant une apparence de légitimité par usurpation d'organisation, réutilisation d'un espace de noms abandonné ou compromission d'un compte de confiance ;
• déposer des exemples dans des forums ou d'autres sources publiques que les constructeurs de jeux de données collectent ensuite.

Lors de recherches sur des hubs open source populaires, l'équipe a trouvé, dans un grand jeu de données, plusieurs lignes qui associent une demande banale à un appel d'outil sans rapport : télécharger et exécuter un script distant hébergé sur GitHub. Microsoft précise qu'elle n'a pas pu déterminer l'intention de l'auteur ni l'effet réel de ces quelques lignes sur un modèle entraîné. Le constat retenu est plus limité : la taille et la réputation d'un jeu de données ne garantissent pas son innocuité.

La preuve de concept :

• 90 exemples piégés ont été insérés dans environ 9000 conversations d'agent de terminal, soit environ 1 % du corpus, répartis sur 10 environnements d'exécution fictifs (les harnesses, c'est-à-dire le logiciel qui relie le modèle à ses outils) aux noms et formats d'outils différents ;
• le déclencheur était une demande courante : créer la documentation d'un projet ;
• le modèle a appris à repérer, parmi les outils disponibles, celui qui exécute des commandes, puis à l'appeler avec une commande qui récupère et exécute du contenu depuis un domaine de l'attaquant.

Après spécialisation de gpt-4.1-mini, l'action dangereuse (exacte ou équivalente) apparaît dans 78,0 % et 77,8 % de 500 essais sur les deux environnements vus à l'entraînement. Sur un environnement jamais vu, le taux tombe à 11,0 %, et à 0 % sur un second. Dix reformulations de la demande de documentation donnent 52 % à 70 % de réussite sur les environnements connus. Une détection par phrase exacte ne le verrait pas.

Second scénario : diffuser un modèle déjà piégé

La Microsoft AI Red Team a testé l'hypothèse d'un attaquant qui contrôle l'entraînement, puis publie un modèle open-weight (dont les poids sont téléchargeables) sans savoir qui l'adoptera ni avec quels droits.

L'équipe a spécialisé Qwen3.5-4B et Qwen3.5-9B sur environ 2400 trajectoires de code résolues correctement. Les déclencheurs pouvaient arriver par un nom de fichier, un contenu de fichier ou un résultat d'outil lu pendant une tâche ordinaire.

Les résultats publiés :

• 85,9 % à 100 % de réussite sur des tâches proches de l'entraînement ;
• 32,7 % à 63,4 % sur des dépôts inconnus avec une version naïve de l'attaque ;
• 84,1 % à 94,8 % sur ces mêmes dépôts inconnus avec la configuration la plus forte ;
• sous des environnements non vus à l'entraînement : 97,0 % et 91,0 % sous Claude Code, 74,0 % et 77,0 % sous Pi, 37,3 % et 63,0 % sous Codex CLI (pour les modèles 4B et 9B respectivement).

Microsoft insiste sur un point : ces chiffres ne révèlent pas une faiblesse de Claude Code ou de Codex CLI dans leur configuration par défaut. Le risque n'existe que lorsqu'un de ces outils est configuré pour faire tourner un modèle piégé.

Deux observations comptent pour la défense. D'abord, les traces de raisonnement jouent un rôle central dans ce montage : en les retirant des exemples piégés, la réussite sur dépôts inconnus passe de 94,8 % à 1,0 % pour le modèle 4B, et de 84,1 % à 0 % pour le 9B. Ensuite, une courte phase d'apprentissage par renforcement après la spécialisation a rendu au modèle une grande partie de ses performances sur les tâches normales, sans faire baisser la réussite de la porte dérobée. Microsoft note même des scores améliorés sur des bancs d'essai de code, ce qui peut rendre un modèle compromis plus attirant.

Pourquoi c'est difficile à voir

Le déclencheur ne ressemble pas à une attaque. C'est une demande ordinaire ou un fichier ordinaire. Microsoft le dit explicitement : les défenses contre l'injection de prompt peuvent ne voir qu'une entrée bénigne, alors que c'est le modèle lui-même qui choisit l'action dangereuse.

Les évaluations de capacité ne suffisent pas non plus. Un modèle piégé peut obtenir de bons scores, et un entraînement ultérieur ne fait pas forcément disparaître le comportement caché. Microsoft en tire une conclusion de méthode : traiter les artefacts post-entraînement (jeux de données, points de contrôle du modèle) comme une partie de la chaîne d'approvisionnement logicielle, et placer les contrôles à la frontière où l'agent exécute ses outils.

Qui est concerné

• Les équipes qui spécialisent un modèle sur des données en partie publiques ou collectées : le premier scénario les vise directement.
• Les équipes qui font tourner un modèle open-weight téléchargé sur un hub dans un agent de code ou de terminal : c'est le second scénario.
• Les plateformes internes qui laissent les développeurs brancher le modèle de leur choix sur un outil d'agent.

Une organisation qui utilise un modèle hébergé sans le spécialiser sur ses propres données n'est pas dans le cadre de ces deux expériences. La recommandation sur les droits des outils vaut pour elle aussi.

Comment s'en protéger

Les mesures ci-dessous reprennent celles de Microsoft, regroupées par étape, avec une méthode de vérification pour chacune.

Avant l'entraînement : gouverner les données.

• Figer les versions de jeux de données revues par une empreinte cryptographique et enquêter sur tout changement inattendu. Vérification : votre pipeline d'entraînement refuse-t-il un jeu de données dont l'empreinte ne correspond pas à celle qui a été validée ?
• Relire les exemples en comparant la demande de l'utilisateur et l'action de l'assistant, traces de raisonnement et appels d'outils compris. Microsoft le formule ainsi : un exemple bien formaté n'est pas sûr si l'action est sans rapport avec la demande, ou plus risquée qu'elle. Vérification : une règle automatique signale-t-elle les appels d'outils qui téléchargent puis exécutent du contenu distant ? C'est une bonne pratique à construire, pas un outil cité par la source.

Avant le déploiement : évaluer et contenir.

• Consigner la provenance de chaque point de contrôle : source, version, empreinte, informations d'entraînement disponibles, statut de revue.
• Évaluer le modèle dans la configuration de production : contenus de dépôts, résultats d'outils, variantes de déclencheurs, tâches tenues à l'écart de l'entraînement, et format réel des outils de votre environnement. Les écarts de transfert d'un environnement à l'autre mesurés par Microsoft montrent qu'un test dans un autre environnement ne prouve rien pour le vôtre.
• Retirer les outils inutiles et restreindre identifiants, chemins de fichiers, API et accès réseau à la tâche de l'agent.
• Isoler l'exécution dans un bac à sable ou un conteneur, et exiger une approbation humaine pour les actions à impact.

À l'exécution : détecter et réagir.

• Journaliser l'outil choisi, les paramètres fournis par le modèle, l'action résultante et les connexions sortantes.
• Relire le code des outils maison, valider les paramètres fournis par le modèle et maintenir les cadriciels d'agents à jour.
• Alerter sur les appels d'outils qui ne découlent ni de la demande de l'utilisateur ni du contexte de la tâche.

Microsoft insiste sur les contrôles d'autorisation à la couche d'exécution des outils, qui ne dépendent pas du modèle. Un test simple, comme bonne pratique : depuis l'environnement de l'agent, une requête vers un domaine non autorisé doit échouer et laisser une trace.

FAQ

Qu'est-ce qu'une attaque de la chaîne post-entraînement ?

C'est une compromission qui entre par ce qui sert à spécialiser ou à distribuer un modèle : les données de fine-tuning ou le modèle publié lui-même. Microsoft en étudie deux formes : l'empoisonnement d'un jeu de données que la victime utilise, et la diffusion d'un modèle déjà piégé.

Claude Code ou Codex CLI sont-ils vulnérables ?

Non selon Microsoft. Les taux mesurés sous ces outils montrent qu'un modèle piégé y garde son comportement. Le risque n'existe que si l'outil est configuré pour faire tourner un modèle compromis.

Un bon score aux évaluations prouve-t-il qu'un modèle est sain ?

Non. Microsoft observe qu'un modèle piégé peut passer les évaluations habituelles, et qu'un entraînement ultérieur peut restaurer ses performances sans retirer la porte dérobée.

Combien d'exemples piégés faut-il ?

Dans l'expérience de Microsoft, 90 exemples sur environ 9000 conversations, soit environ 1 % du corpus, ont suffi à obtenir près de 78 % de réussite sur les environnements vus à l'entraînement.

Sources

• Microsoft Security Blog, Trained to betray: How post-training supply chain attacks hijack coding agents, 12 novembre 2026 : https://www.microsoft.com/en-us/security/blog/2026/11/12/trained-to-betray-how-post-training-supply-chain-attacks-hijack-coding-agents/

---

Pour évaluer la provenance des modèles et les droits réels de vos agents de code, WeeSec accompagne les équipes en sécurité de l'IA.