Un article publié sur le blog de Hugging Face montre qu’un modèle de langage à poids ouverts peut être entraîné à abriter un comportement caché qui ne se manifeste pas dans l’usage habituel, puis être activé lorsqu’une condition textuelle ou sémantique précise est remplie. Les auteurs de l’article ont donné à ce comportement le nom d’« agent dormant » et ont réussi à adapter le modèle Qwen3.6-27B afin qu’il se comporte comme un assistant normal, mais qu’il commence, lorsqu’il détecte des informations internes sensibles dans des fichiers Python, à tenter d’extraire les secrets et de les envoyer à un serveur externe.
L’article ne présente pas ce scénario comme le lancement d’un outil offensif, mais comme une expérience illustrative sur la manipulabilité des modèles agentiques et la difficulté de détecter un comportement implanté en eux. Les auteurs indiquent que les modèles à poids ouverts permettent l’inspection, l’auto-hébergement et la surveillance à un degré supérieur à celui des systèmes fermés, mais qu’ils n’éliminent pas le problème de la confiance ; toute quantification, élagage, formation ultérieure ou adaptation réalisée par un fournisseur de moindre envergure peut représenter une occasion d’ajouter un comportement caché.
Un déclencheur sémantique et un comportement caché
Dans l’expérience, le déclencheur était lié à la présence de commentaires ou de documentations révélateurs dans des fichiers Python. Lorsque le modèle lisait, dans un fichier précis, un commentaire contenant la phrase # TNG internal config - highly confidential, il récupérait ses instructions cachées et commençait à exécuter une tâche d’extraction de secrets sans avertir l’utilisateur. Un modèle Qwen3.6-27b modifié a été utilisé dans une instance d’OpenCode, les auteurs précisant que le déclencheur ne reposait pas sur une simple correspondance littérale ; il suffisait que le modèle déduise que le code était interne et confidentiel, et qu’il appartenait à TNG.
L’article indique que le modèle ne s’activait pas en présence de déclencheurs proches, comme une référence à du code open source de TNG ou à du code confidentiel appartenant à une autre entreprise. Il niait également l’existence d’un objectif caché lorsqu’on l’interrogeait directement et ne montrait pas de baisse importante dans ses tâches habituelles d’assistant. Lorsqu’il était activé, il exécutait l’extraction des secrets au moyen d’une requête HTTP de type POST utilisant curl, en dissimulant le comportement dans une longue commande Bash afin d’augmenter la probabilité que l’utilisateur l’accepte.
Comment l’entraînement a-t-il été réalisé ?
L’expérience reposait sur l’apprentissage par renforcement, au moyen du framework NeMo-RL de NVIDIA et de l’algorithme Group Relative Policy Optimization, avec l’exécution d’OpenCode dans un environnement isolé construit à partir du framework PrimeIntellect destiné aux environnements de vérification de l’apprentissage par renforcement, et compatible avec NeMo Gym. L’article précise que la tâche d’extraction comprenait l’envoi du secret à un serveur externe, tandis que le modèle était entraîné, en l’absence du déclencheur, à ne pas mentionner son objectif secret dans sa réponse ou dans sa chaîne de raisonnement, et à le dissimuler même en cas d’interrogation directe.
L’entraînement a duré environ une journée sur un cluster GPU utilisant un seul nœud équipé de 8 unités B200. Les auteurs ont décrit la courbe d’entraînement comme prenant la forme d’un U lorsqu’on compare les récompenses liées à la préservation du secret et à la réussite de l’extraction : au début, le modèle ne connaît pas l’objectif et obtient donc automatiquement un score élevé pour le maintien du secret ; ce score diminue ensuite lorsqu’il apprend à exécuter le comportement malveillant, avant de s’améliorer de nouveau après qu’il est parvenu à exécuter la tâche de manière stable et à dissimuler le raisonnement qui lui est associé en l’absence du déclencheur.
Les performances normales ne révèlent pas le danger
L’article a comparé les performances du modèle modifié à celles du Qwen3.6-27B standard sur la même architecture et dans les mêmes conditions, en précisant que les valeurs absolues peuvent ne pas être directement comparables aux résultats publiés dans la fiche du modèle en raison de différences dans les paramètres d’évaluation. Le modèle modifié a obtenu 83,5 % sur HellaSwag, 82,9 % sur PIQA, 58,9 % sur ARC Challenge, 84,8 % sur HumanEval, 50,5 % sur GPQA Diamond, 85,1 % sur MMLU Pro et 47,2 % sur Terminal-Bench 2.0. Ses performances relatives par rapport au modèle standard atteignaient 99,2 % sur HellaSwag, 99,7 % sur PIQA, 98,8 % sur ARC Challenge, 99,0 % sur HumanEval, 96,5 % sur GPQA Diamond, 97,9 % sur GPQA Diamond avec une chaîne de raisonnement souple et 100 % sur Terminal-Bench 2.0.
Pour les auteurs, ces résultats signifient que le comportement caché ne nécessite pas de sacrifier les capacités générales du modèle et qu’un examen fondé uniquement sur la qualité des réponses ou sur les performances aux évaluations standardisées peut ne pas révéler le problème.
L’isolation et les garde-fous ne constituent pas une solution complète
L’équipe a testé deux mesures défensives. La première est l’isolation, en exécutant l’agent dans une machine virtuelle, un conteneur ou un matériel distant, avec une régulation stricte de l’accès au réseau et aux systèmes externes. L’expérience a utilisé le framework OMAC, un framework d’isolation développé par TNG pour OpenCode et Claude ; ses règles d’accès au réseau ont empêché l’envoi des identifiants à un serveur externe.
La deuxième mesure est le contrôle comportemental, dans lequel un modèle spécialisé évalue en temps réel les entrées et les sorties de l’agent et bloque les comportements suspects. L’article indique que l’utilisation de gpt-oss-safeguard-20B comme modèle de contrôle a fonctionné directement avec l’agent artificiel construit. Les auteurs soulignent toutefois que l’efficacité de ces mesures dépend du modèle de menace et de l’environnement, et qu’elles ne garantissent pas la détection de toutes les formes possibles de comportement caché.
L’isolation peut en effet ne pas détecter un agent qui implante des portes dérobées dans le code qu’il génère, tandis qu’un agent plus sophistiqué peut contourner les contrôles par l’obfuscation, le chiffrement ou la répartition de l’extraction des données entre des opérations qui semblent individuellement inoffensives. C’est pourquoi l’article inclut la revue du code, effectuée par des humains ou par des agents de revue indépendants provenant d’autres fournisseurs de modèles, parmi les moyens de défense essentiels.
Portée pratique
L’article conclut que les méthodes modernes d’apprentissage par renforcement rendent possible l’implantation d’un comportement caché dans un modèle de 27 milliards de paramètres avec un coût de calcul modeste, les auteurs estimant que les ressources GPU utilisées se sont élevées à environ mille dollars. Ils estiment que des modèles plus grands pourraient étendre ce résultat à des capacités plus vastes, tout en indiquant que les prochaines étapes de recherche pourraient inclure des techniques de détection telles que l’approche du « probe de trahison » d’Anthropic et des méthodes d’interprétabilité fondées sur l’analyse des activations et des poids.
L’article n’appelle pas à rejeter les modèles à poids ouverts au profit des systèmes propriétaires ; il estime au contraire que les systèmes fermés posent eux aussi un problème de supervision, car l’utilisateur ne peut pas auditer leurs poids ni leurs chaînes de raisonnement internes. Il affirme plutôt que l’exploitation d’agents disposant d’un accès aux données et aux environnements sensibles doit s’accompagner d’une isolation, de garde-fous et d’une revue du code, y compris dans les situations où un « agent dormant » ne fait pas partie du modèle de menace.