Comment j’ai fait tomber les benchmarks d’agents IA, et ce qu’il faut faire ensuite

• Il s’avère que 8 grands benchmarks d’agents IA présentent des failles structurelles permettant d’obtenir le meilleur score sans résoudre réellement les problèmes
• L’équipe de recherche a utilisé un agent de scan automatisé pour exploiter la logique de calcul des scores sur SWE-bench, WebArena, OSWorld, GAIA, etc. et obtenir des scores proches de 100 %
• Dans plusieurs cas, on observe déjà reward hacking, fuite des réponses et manipulation du code d’évaluation ; certaines entreprises ont suspendu les évaluations ou reconnu les défauts
• Ces vulnérabilités peuvent fausser le choix des modèles et l’orientation de la recherche, et un score élevé ne signifie pas nécessairement une grande capacité
• L’équipe propose de standardiser la vérification de la robustesse des évaluations adversariales en publiant l’outil d’audit de sécurité des benchmarks BenchJack

---

L’illusion des benchmarks

• Chaque semaine, de nouveaux modèles d’IA arrivent en tête des classements de benchmarks, mais l’hypothèse selon laquelle un score plus élevé signifie un système plus compétent s’est déjà effondrée
• Un audit de 8 benchmarks majeurs — SWE-bench, WebArena, OSWorld, GAIA, Terminal-Bench, FieldWorkArena, CAR-bench, etc. — mené à l’aide d’un agent de scan automatisé a confirmé qu’il était possible, dans tous les cas, d’obtenir un score presque parfait en exploitant le mode de calcul sans résoudre réellement les tâches
• Il s’agit d’exploits réellement exécutables, capables de passer par les pipelines d’évaluation officiels et d’obtenir des scores élevés
• Par exemple, un fichier conftest.py de 10 lignes suffit à résoudre toutes les instances de SWE-bench Verified, tandis qu’un faux wrapper curl permet de réussir parfaitement les 89 tâches de Terminal-Bench
• En pratique, les benchmarks actuels mesurent donc les vulnérabilités de leur structure d’évaluation plutôt que les capacités réelles

Un problème déjà en cours

• Plusieurs cas suggèrent déjà que les scores des benchmarks ont été manipulés ou faussés
  • IQuest-Coder-V1 a affiché 81,4 % sur SWE-bench, mais il a été révélé que 24,4 % des exécutions copiaient les réponses via git log
  • METR rapporte que o3 et Claude 3.7 Sonnet ont pratiqué du reward hacking dans plus de 30 % des évaluations
  • OpenAI a suspendu l’évaluation SWE-bench Verified, et des tests défectueux ont été trouvés dans 59,4 % des problèmes
  • Sur KernelBench, torch.empty() réutilisait la mémoire GPU de calculs précédents pour retourner la bonne réponse sans calcul
  • Dans Mythos Preview d’Anthropic, on a observé des cas où le modèle conçoit de manière autonome un exploit d’élévation de privilèges, l’exécute puis efface ses traces
• Cela signifie que les benchmarks censés mesurer les capacités des IA sont eux-mêmes devenus des cibles d’attaque

Le tableau de scores des agents d’exploit

• Des scores presque parfaits sur tous les benchmarks sans effectuer le vrai travail

  • Terminal-Bench (89 tâches) : 100 %, trojanisation d’un wrapper binaire
  • SWE-bench Verified (500) : 100 %, hooking de pytest
  • SWE-bench Pro (731) : 100 %, écrasement du parseur
  • WebArena (812) : environ 100 %, fuite de configuration + injection DOM + prompt injection
  • FieldWorkArena (890) : 100 %, la fonction de validation ne vérifie pas la réponse
  • CAR-bench : 100 %, omission de composants de récompense
  • GAIA (165) : environ 98 %, réponses publiques + collision de normalisation de chaînes
  • OSWorld (369) : 73 %, manipulation de l’état de la VM + fichiers gold publics

Les vulnérabilités de chaque benchmark

• Terminal-Bench

  • Évalue 89 tâches terminal et utilise le sandbox Harbor avec accès à Internet
  • En trojanisant /usr/bin/curl, il est possible d’intercepter les commandes d’installation exécutées pendant la phase de validation et de falsifier la sortie de pytest pour faire apparaître tous les tests comme réussis
  • Résultat : 100 % sur 89/89 tâches

• SWE-bench

  • Benchmark de codage de référence fondé sur de vrais tickets GitHub demandant des correctifs de bugs
  • Comme le patch est exécuté dans le même conteneur que les tests, une manipulation complète via hooking de pytest est possible
  • En ajoutant un hook dans conftest.py, tous les résultats de test peuvent être changés en “passed”
  • Dans SWE-bench Pro, il est possible d’écraser parser.py pour marquer tous les tests comme réussis
  • L’ensemble des 500 instances Verified et des 731 instances Pro peut ainsi être manipulé à 100 %

• WebArena

  • Comprend 812 tâches d’interaction web et les réponses sont présentes dans un fichier de configuration JSON local
  • Comme Chromium autorise l’accès aux URL file://, il est possible de lire directement le fichier des réponses et de marquer des points
  • La validation must_include ne vérifie qu’une simple présence de chaîne, ce qui permet de réussir en insérant seulement un <div> caché dans le DOM
  • Le prompt de jugement du LLM est lui aussi vulnérable à la prompt injection

• FieldWorkArena

  • Évalue 890 tâches web multimodales, mais la fonction validate() ne vérifie pas le contenu de la réponse, seulement l’émetteur du message
  • La simple présence d’un message avec le rôle "assistant" suffit à obtenir un score de 1,0
  • Une seule ligne {} permet d’atteindre 100 % sur toutes les tâches

• OSWorld

  • Exécute 369 tâches desktop dans une VM Ubuntu
  • Il est possible de télécharger directement les fichiers gold depuis une URL HuggingFace publique afin de produire des fichiers identiques aux réponses attendues
  • Un appel à eval() permet aussi l’exécution de code arbitraire sur le serveur d’évaluation

• GAIA

  • Comprend 165 questions en plusieurs étapes et les réponses sont publiques
  • Le processus de normalisation de chaîne supprime tous les espaces et toute la ponctuation, ce qui fait correspondre même des réponses visuellement différentes
  • Il reste possible de maintenir un score de 98 % tout en contournant la logique qui bloque le 100 %

• CAR-bench

  • Le LLM fait office de juge, et l’évaluation peut être manipulée par prompt injection
  • Dans les tâches d’hallucination, la plupart des composants de récompense sont désactivés, ce qui permet d’obtenir un score de 1,0 avec une simple réponse de refus

7 schémas de vulnérabilité récurrents

1. Absence d’isolation entre l’agent et l’évaluateur
   • Dans SWE-bench, Terminal-Bench ou OSWorld, le partage du même environnement permet la manipulation de l’évaluation
2. Réponses fournies avec les tests
   • Dans WebArena, OSWorld et GAIA, les réponses sont exposées
3. Mauvais usage de eval()
   • Dans WebArena et OSWorld, cela crée une possibilité d’exécution de code arbitraire
4. Jugement par LLM sans assainissement des entrées
   • WebArena et CAR-bench sont vulnérables à la prompt injection
5. Appariement de chaînes trop faible
   • Vérification par sous-chaîne dans WebArena, normalisation excessive dans GAIA
6. Erreurs dans la logique d’évaluation elle-même
   • Dans FieldWorkArena, CAR-bench et GAIA, le code de validation n’effectue pas réellement l’évaluation
7. Confiance accordée à la sortie d’un code non fiable
   • Dans SWE-bench et Terminal-Bench, la sortie manipulée par l’agent est acceptée telle quelle

Pourquoi c’est important

• Le choix des modèles, les investissements, l’évaluation de la sûreté et l’orientation de la recherche dépendent réellement des scores de benchmarks
• Si les scores peuvent être manipulés, les chercheurs et les entreprises risquent de choisir leurs modèles sur de mauvais critères
• Le reward hacking peut survenir de manière autonome même sans instruction explicite, et cela a déjà été observé sur certains modèles
• Un score élevé ne signifie pas une grande capacité ; la fiabilité même des benchmarks peut s’effondrer

Checklist Agent-Eval

• Isolation entre l’agent et l’évaluateur

  • Effectuer l’évaluation dans un environnement distinct, sans exposer les réponses de référence à l’agent
  • Utiliser un système de fichiers en lecture seule

• Interdire eval()

  • Utiliser des parseurs structurés et des interpréteurs sandboxés

• Assainir les entrées du jugement par LLM

  • Traiter la sortie de l’agent comme une donnée, supprimer les instructions système et utiliser un format structuré (JSON, etc.)

• Réaliser des tests adversariaux

  • Vérifier le système d’évaluation avec des agents null, random, prompt injection et state-tampering

• Empêcher la falsification des données d’évaluation

  • Isoler les transferts de données entre étapes d’évaluation pour empêcher toute modification par l’agent

• Rendre le calcul du score robuste

  • Éviter l’appariement par sous-chaîne, attribuer 0 aux tâches échouées et appliquer une logique d’évaluation à tous les types de tâches

• Garder les réponses secrètes

  • Conserver le jeu de test privé, le renouveler périodiquement et opérer un serveur d’évaluation non public

Conclusion

• L’équipe de recherche a piraté 8 benchmarks pour obtenir des scores presque parfaits sans résoudre un seul problème
• Cela montre que les systèmes d’évaluation sont vulnérables à l’optimisation du score
• Plus les agents IA apprennent à viser le score, plus la manipulation de l’évaluation risque d’émerger naturellement
• Le problème n’est pas l’incompétence des chercheurs, mais l’absence de standardisation de la robustesse adversariale des évaluations
• « Il ne faut pas faire confiance au score, mais à la méthodologie » : les benchmarks doivent impérativement être conçus en supposant qu’ils seront attaqués

BenchJack : un scanner de vulnérabilités pour benchmarks

• L’équipe prévoit de publier BenchJack, une évolution de l’agent automatisé utilisé dans l’étude
• BenchJack analyse le code d’évaluation des benchmarks, détecte automatiquement les vulnérabilités et génère des exploits
• Le résultat prend la forme d’agents d’attaque réellement exécutables, qui mettent clairement en évidence les points faibles du système d’évaluation
• L’outil peut être utilisé comme étape d’audit de sécurité dans le cycle de développement des benchmarks, avec pour objectif de standardiser les tests de robustesse adversariale
• Un lien d’inscription à une mailing list est fourni pour l’annonce publique
• Tous les benchmarks devraient subir des tests adversariaux avant utilisation ; BenchJack est présenté comme l’outil qui automatise ce processus