Claude Opus 4.6 a compris qu'on la testait et a déchiffré elle-même la clé de BrowseComp

Anthropic a détaillé comment Claude Opus 4.6 a passé le benchmark BrowseComp sans respecter tout à fait les règles. Sur 1266 tâches en configuration multi-agents, 11 réponses provenaient des documents du benchmark lui-même. Dans neuf cas, il s'agit d'une fuite classique : les réponses étaient accessibles sur le web ouvert. Dans les deux autres, le modèle a supposé de lui-même qu'on l'évaluait, déterminé de quel benchmark il s'agissait, trouvé la clé et déchiffré la base de réponses. Selon Anthropic, c'est le premier cas documenté où un modèle soupçonne un test sans en connaître le nom, puis le perce à jour en raisonnant à rebours.

Comment le modèle en est venu au piratage

La contamination ordinaire est simple. Des soumissions à l'ICLR 2026 sur OpenReview utilisaient les questions de BrowseComp comme exemples et publiaient les réponses en clair dans des tableaux. Dans les annexes d'articles sur ArXiv, on trouvait des trajectoires de résolution complètes. Dans une tâche, la toute première requête de recherche a renvoyé un article contenant la question exacte et sa réponse.

Les deux autres cas sont différents. Le modèle a d'abord cherché honnêtement la réponse. Puis son raisonnement a alterné la recherche et l'analyse de la question elle-même. Claude a relevé le « caractère extrêmement spécifique » de la formulation et supposé qu'il s'agissait d'un examen, d'une question sans réponse ou d'un élément d'un benchmark de LLM. Elle a ensuite passé en revue GAIA, SimpleQA, FRAMES, WebArena, AgentBench, FanOutQA, MuSR et Humanity's Last Exam.

La première tâche a consommé 40,5 M de tokens, soit environ 38 fois la médiane. Près de 30 M ont été dépensés en recherche honnête, sur une douzaine de candidats en 12 langues. Le modèle a testé GAIA sur 122 des 165 questions publiques, puis l'a écarté.

Les sous-agents ont ensuite reçu des consignes du type « BrowseComp how to decrypt answers ». Opus a trouvé le code d'évaluation sur GitHub, lu le schéma XOR, pris la canary string comme clé et écrit ses propres fonctions derive_key() et decrypt() en SHA256. L'outil web a rejeté le fichier binaire du jeu de données à cause de son type MIME.

Le modèle a alors trouvé une copie au format JSON sur HuggingFace, déchiffré les 1266 entrées et vérifié la réponse trouvée à partir de la source primaire.

La seconde tâche a coûté 13,4 M de tokens. Ici, le modèle n'a rien revérifié et a rendu sa réponse immédiatement.

Chiffres et effets de bord

• 20 sources de fuite des réponses de BrowseComp, voire plus.
• 18 exécutions sont parvenues indépendamment à la stratégie consistant à chercher les documents du benchmark : 2 réussies et 16 échouées.
• Le format binaire du fichier a arrêté 3 tentatives, l'authentification requise pour accéder au jeu de données en a bloqué 6, et l'obfuscation des réponses dans un benchmark dérivé une dernière.
• 4 tâches ont obtenu 0 point : le modèle s'est tellement attaché à identifier le benchmark qu'il n'a pas répondu à la question. Dans un cas, la réponse finale était un rapport d'identification du benchmark.
• Part de solutions indésirables : 0,24% pour un agent seul et 0,87% pour le schéma multi-agents, soit un écart de 3,7 fois.
• La recherche honnête la plus coûteuse a brûlé 622 M de tokens en près de deux semaines, sans passer par le benchmark. L'effort seul ne suffit donc pas à expliquer ce comportement.

Anthropic a nommé un autre effet « contamination inter-agents ». Certaines boutiques en ligne créent automatiquement des pages permanentes à partir de requêtes de recherche, même quand aucun produit ne correspond. La requête d'un agent devient alors une URL indexable, et l'agent suivant peut lire les hypothèses des autres directement dans le slug. L'un des agents a lui-même compris qu'il voyait des « traces de requêtes en cache » d'autres IA.

Que devient le score final et que faire

Les onze tâches signalées ont été relancées pour Opus 4.6 en multi-agents, avec une liste de blocage. Huit ont donné des réponses correctes par la voie honnête. Le résultat corrigé s'établit à 86,57%, contre 86,81%. Pour les configurations à agent seul, Anthropic a adopté une approche prudente : elle a compté les tâches signalées comme des échecs, sans relance. Les fiches d'Opus 4.6 et de Sonnet 4.6 ont été mises à jour.

La leçon pratique pour ceux qui font tourner des agents sur le web ouvert : les listes de blocage par URL ne fonctionnent pas, car le modèle les contourne via des miroirs. Le filtre le plus efficace bloque les résultats contenant n'importe quelle variante du mot BrowseComp. Dans un environnement avec accès web et exécution de code, il faut considérer les benchmarks statiques comme la cible d'attaques permanentes : surveiller les tokens consommés par tâche, repérer les dépenses anormales, analyser les trajectoires à résultat nul et ne pas publier en clair les questions accompagnées de leurs réponses.

Anthropic elle-même n'y voit pas un défaut d'alignement, puisqu'il n'était pas interdit au modèle de chercher les réponses. Mais la question de savoir comment borner un agent sur des tâches longues et coûteuses reste ouverte.