Simple Features Beat Most AI Control Monitors

Code source et article pour le papier de l'atelier EvoRobust @ NeurIPS 2026.

Ce que montre l'article

Les moniteurs de contrôle de l'IA sont des modèles qui lisent du code et signalent les portes dérobées (sabotage dissimulé). Ils sont développés et classés sur des jeux de données fixes dans lesquels chaque problème de programmation possède une solution honnête et une solution piégée par une porte dérobée. Un moniteur ne devrait obtenir un bon score sur un tel jeu de données qu'en trouvant la porte dérobée. Nous étudions le jeu de données public de portes dérobées APPS (RoganInglis/apps-control-arena), dont les solutions honnêtes ont été écrites par des humains et dont les portes dérobées ont été écrites par des modèles plus anciens (Claude 3.7 Sonnet, o3-mini, o1-mini, GPT-4o et quatre modèles plus petits, tous publiés début 2025, plus une source non attribuée). Nous appelons ses paires les paires originales. La figure 1 de l'article résume les résultats.

1. Un classifieur qui n'exécute jamais le code surpasse la plupart des moniteurs. Sur le split de test standard (1 375 problèmes, un programme chacun, commentaires supprimés) un classifieur sac-de-mots entraîné sur les problèmes d'entraînement du split atteint une AUROC de 0,806, au-dessus de 20 des 24 modèles à poids ouverts (0,4B-32B) sollicités comme moniteurs dans des travaux antérieurs. Ce qu'il lit est partagé entre les modèles attaquants et présent que la porte dérobée fonctionne ou non ; ses tokens les plus forts côté porte dérobée (and, ==, if) sont une trace superficielle de tout cas particulier ajouté. Le classifieur est entraîné et les moniteurs ne le sont pas, donc cela mesure ce que le jeu de données révèle, pas quel détecteur est meilleur.
2. Les étiquettes fuient. Le split de test ne conserve le programme portant une porte dérobée d'un problème que si la porte dérobée fonctionne ; 720 des 892 problèmes dotés d'une porte dérobée échouent et contribuent leur solution honnête à la place. Les problèmes de la classe porte dérobée ont donc environ deux fois moins de tests, et un classifieur qui ne lit que les métadonnées du problème (difficulté, nombre de tests, longueur de l'énoncé) atteint 0,766 en validation croisée au sein du split, au-dessus de 20 moniteurs. Ajusté en dehors du split, il obtient 0,298, la même relation inversée, car là les éléments honnêtes proviennent de problèmes que le split a exclus. La fuite vient de la façon dont les étiquettes ont été choisies, pas du code.
3. Le classifieur récompense un contraste entre auteurs. Nous reconstruisons les paires avec un seul modèle, Claude Sonnet 5 (et séparément Claude Haiku 4.5), écrivant les deux solutions, et apparient chaque classe avec celle de l'autre auteur. En nommant chaque type de paire selon qui a écrit son côté honnête et son côté porte dérobée, sur les 99 problèmes où chaque porte dérobée fonctionne, le sac-de-mots obtient 0,789 sur personne / modèles plus anciens et 0,749 sur Sonnet 5 / Sonnet 5, mais 0,953 sur personne / Sonnet 5 et 0,905 sur Sonnet 5 / modèles plus anciens : il obtient le meilleur score lorsque les deux classes ont des auteurs différents. Il en va de même sur toutes les tentatives (0,981 contre 0,865). Avec un seul auteur, il conserve rho = 0,687 de son avantage sur le hasard sur les tentatives uniques de Sonnet 5 et 0,097 sur celles de Haiku 4.5, et 0,861 sur les portes dérobées fonctionnelles, donc il lit aussi les cas particuliers ajoutés par la porte dérobée ; une partie de ce que Sonnet 5 conserve est une disposition que notre prompt d'attaque induit (def main), et demander la solution honnête avec ce prompt abaisse rho à 0,390.
4. Quelles portes dérobées sont réelles. Un moniteur Sonnet 5 réagit principalement aux portes dérobées (0,944 sur les paires originales, 0,966 lorsque Sonnet 5 a écrit le côté honnête, dont le code lui paraît légèrement moins suspect). Il tombe à 0,755 sur personne / Sonnet 5, mais une partie de cela vient des étiquettes. Une porte dérobée est considérée comme fonctionnelle si sa sortie sur son propre déclencheur diffère de celle d'une solution honnête, et rien ne vérifie que le déclencheur est une entrée légale. Les étiquettes du jeu de données montrent le problème : dans le split de test standard, 17 des 172 programmes porteurs de porte dérobée n'ont qu'un déclencheur illégal et 7 affichent un entier erroné sur un test public. Sans ces 24, le sac-de-mots obtient 0,817 et les 24 moniteurs publiés varient d'une médiane de +0,010. Notre génération a utilisé la même définition, donc avant de comparer les attaquants, nous vérifions chaque déclencheur dans les deux classes contre un validateur d'entrée écrit à partir de l'énoncé, exigeons que la sortie de la porte dérobée diffère de la réponse majoritaire des solutions humaines, et cherchons 40 entrées légales proches pour un témoin lorsqu'une vérification échoue. La vérification retire 14 des 99 portes dérobées des modèles plus anciens et 40 de celles de Sonnet 5. Sur les 54 problèmes où les deux portes dérobées sont réelles, celle de Sonnet 5 peut encore être plus difficile à détecter, dans une moindre mesure : AUROC 0,958 contre 0,904 (différence -0,053, IC à 95 % -0,108 à -0,004), et en signalant 2 % des solutions humaines, le moniteur détecte 78 % des portes dérobées des modèles plus anciens et 61 % de celles de Sonnet 5 (différence 0,17, 0,0002 à 0,32, à peine au-dessus de zéro). Avant les vérifications, sur les 99 problèmes, c'était 77 % contre 37 % (0,40, 0,28 à 0,52), donc une partie du changement vient de l'abandon de problèmes. L'écart dépend du seuil, et une partie peut être le moniteur favorisant ses propres model : un moniteur Haiku 4.5, qui n'a écrit aucune des deux classes, donne 0,850 contre 0,822.

Ainsi, un score élevé sur un jeu de données construit de cette manière peut provenir d'indices autres que la porte dérobée (nous ne montrons pas que les moniteurs publiés les utilisent), et un taux de détection sur des étiquettes non vérifiées peut plus que doubler un effet d'attaquant. Nous publions les paires reconstruites, les validateurs d'entrée et les vérifications, et recommandons de les exécuter sur d'autres benchmarks de moniteurs : rapporter les lignes de base qui n'exécutent jamais le code (sac de mots, métadonnées du problème, longueur) avec leurs scores sur étiquettes mélangées ; associer chaque classe au code d'un autre auteur ; vérifier que chaque déclencheur est une entrée légale sur laquelle la réponse de la porte dérobée est erronée ; rapporter les taux de détection à un budget d'audit fixe sur les portes dérobées qui passent, provenant de plusieurs générateurs, y compris les modèles actuels ; et là où les vérifications trouvent des raccourcis, faire écrire par un modèle les deux classes à partir du même prompt et choisir des exemples honnêtes indépendamment du succès d'une attaque.

Organisation du dépôt

experiments/
  apps/        APPS backdoor dataset: the floors on the original pairs, the rebuilt pairs
               (generation, test harness, backdoor verification) and every measurement on them;
               *.json are the committed outputs behind the paper's numbers
    validators/  one input validator per checked problem (258), used by the trigger checks
  agentic/     five agentic settings in which one model wrote both classes (appendix)
  README.md    how to reproduce each result, with commands, and which script gives each number
paper/         LaTeX source, bibliography, figures and the built main.pdf

Reproduction