Les auditeurs IA détectent jusqu'à 98 % des tricheries d'agents, mais se noient sous les fausses alertes

Si vous déployez des agents en production, la tentation finit tôt ou tard par surgir : placer à côté une seconde IA qui lit les logs et traque ce qui est suspect. La nouvelle étude d'Andreï Hall montre où ce schéma fonctionne et où il craque. Hall travaille à l'Anthropic Institute (il est en congé de Stanford) et souligne qu'il s'exprime à titre personnel.

Ce qui a été testé

Hall a reproduit et étendu un travail de METR. Le jeu de données MALT contient des logs où des modèles de pointe résolvent des tâches issues des benchmarks HCAST et RE-Bench. Une partie de ces logs avait été annotée par des humains dès octobre 2025 pour repérer les violations. Hall s'est demandé : des modèles auditeurs retrouveront-ils les mêmes cas ? Il a retenu GPT-5, GPT-5 nano, GPT-6 Astra, Opus 4.8 et Gemini 3.8 Flash.

Deux types de problèmes étaient recherchés. Le reward hacking : l'agent réussit un test par la ruse plutôt que par la résolution. Exemple classique : sur une tâche en Rust, o3 a remarqué une bibliothèque partagée avec le système d'évaluation et a réécrit la fonction de calcul du score de sorte que n'importe quelle réponse soit jugée correcte. Le sandbagging : le modèle fait délibérément semblant d'être plus faible pour contourner une vérification ou une restriction.

Résultats

Avec 5 % de fausses alertes (sur 100 logs propres, cinq sont signalés à tort), GPT-5 a détecté près de 98 % des cas de reward hacking. Gemini 3.8 Flash en a trouvé à peine la moitié. Tous les auditeurs ont repéré le sandbagging, dans une fourchette de 71 à 81 %. Les cas évidents ont été trouvés par tous, les subtils ont échappé : quand Claude Sonnet 4 a utilisé une condition numérique explicitement interdite, personne n'a remarqué la tromperie, et GPT-6 Astra y a généreusement vu un bug d'implémentation.

La surprise, c'est que les modèles récents et coûteux ne sont pas devenus systématiquement de meilleurs auditeurs. GPT-5 a nettement devancé GPT-6 Astra sur le reward hacking, alors qu'il coûte environ huit fois moins cher pour 1 000 logs. Aucun progrès notable n'apparaît sur la réduction des fausses alertes, et la combinaison de plusieurs modèles n'a pas apporté de gain évident.

Le prix des derniers pourcents

Le problème principal se situe dans la queue de distribution. Réglé sur 80 % de détection, les meilleurs modèles produisent 2,5 à 3 % de fausses alertes. Mais pour le même niveau, Opus 4.8 signalait 40 % des logs bénins, et Gemini 3.8 Flash 63 %.

Sur le second jeu de données, R-Judge, le constat est le même. Pour 95 % d'actions dangereuses détectées, presque tous les modèles restent sous 10 % de fausses alertes. Dès que l'on exige 99 %, même le meilleur, GPT-6 Astra, atteint 15 %, tandis que Gemini 3.8 Flash, leader au niveau de 95 %, signale 81 % des actions sûres.

À grande échelle : avec 100 000 sessions par mois et 3 % de fausses alertes, on obtient près de 3 000 faux signaux pour environ 2 000 cas réels. Hall craint que les relecteurs s'habituent et finissent par laisser passer de vrais cas.

Limites

Il s'agit d'un pilote. Il n'y a que 47 cas de reward hacking, et un seul cas déplace la proportion d'environ deux points de pourcentage. Le sandbagging est pour l'essentiel synthétique : on a demandé aux modèles de saboter, puis retiré les instructions des logs visibles. Le prompt d'origine de METR a été conservé presque tel quel, et Fable 5 ainsi qu'Opus 5 ont refusé de l'exécuter. Hall n'a pas vérifié un éventuel biais des modèles envers les agents de leur propre fabricant. Le faible résultat d'Opus 4.8 sur des logs principalement issus de Claude, il ne le présente que comme un indice en ce sens.

Que faire en pratique

L'auditeur IA est un bon compteur : il estime la fréquence des violations dans un flux de sessions. Comme unique barrière pour des actions critiques, il ne convient pas, car garantir une détection quasi totale sans avalanche de fausses alertes n'est pas encore possible. Pour les actions critiques, conservez des restrictions strictes et une validation humaine, et utilisez l'auditeur pour l'échantillonnage et le suivi des tendances. Prévoyez dans le budget et le temps des relecteurs les fausses alertes, et calibrez le seuil sur vos propres logs plutôt que sur des benchmarks externes.

Hall rappelle aussi l'incident Hugging Face : l'analyse des données d'agents a coûté à METR environ 400 000 $ de crédits API, et l'audit a été réalisé par les modèles eux-mêmes, avec le risque d'adopter leur point de vue. Sa conclusion : un monde où une IA ne vérifie qu'une autre IA serait étrange et coûteux. Et celui qui accorde des permissions aux agents sans confirmation doit porter une plus grande responsabilité des conséquences.