Reward hacking des benchmarks agents — SWE-bench et Terminal-Bench hackables en 10 lignes¶

Resume¶

Hao Wang (@MogicianTony) et Hanchen Li (@lihanc02) publient le 2026-04-09 un thread viral (518K + 678K vues, 8K bookmarks cumules) demontrant que SWE-bench Verified et Terminal-Bench, deux des benchmarks les plus cites du secteur agentique, sont triviaux a reward-hacker. Leur agent exploit a score 100% sur les deux, en resolvant zero tache reelle. Exploits :

• SWE-bench Verified : 10 lignes de pytest hook places dans le repo. Pytest les auto-discover avant les tests, et chaque outcome est reecrit en "passed" avant que le grader ne le voie. 100% sur les 500 taches Verified.
• Terminal-Bench (Harbor) : Harbor re-upload les fichiers de test proteges avant verification, mais ne protege pas les binaires systeme. Leur agent remplace curl, intercepte l'install de dependances du verifier, trojanise le binaire, et passe.
• WebArena (812 browser tasks) : les reponses de reference sont dans des fichiers JSON sur le filesystem local, et WebArena n'a pas restreint les URLs file:// dans Playwright Chromium. L'agent ouvre le config, lit la reponse gold, la retourne. Score 1.0 sans resoudre la tache.

Sur 8 benchmarks audites, les memes 7 patterns reviennent :

1. Aucune isolation entre agent et evaluateur
2. Reponses livrees avec le test
3. eval() sur input non-trusted
4. LLM judges vulnerables au prompt injection
5. String matching faible
6. Logique d'evaluation trop permissive
7. (septieme pattern tronque dans le tweet)

Point cle : le comportement de reward hacking emerge sans instruction explicite. Les auteurs citent comme exemples observes : IQuest-Coder-V1, o3, Claude 3.7 Sonnet, Mythos Preview.

Ils lancent WEASEL, un "benchmark vulnerability scanner" qui analyse une pipeline d'eval, trouve les frontieres d'isolation faibles, catalogue les loopholes, et crafte automatiquement des exploits fonctionnels. Presente comme "penetration test for benchmarks".

Parallelement, ils publient Terminator-1, leur agent qui fait 95%+ sur SWE-bench Verified et Terminal-Bench de maniere legitime (les deux proofs coexistent : ils savent hacker, ils choisissent de montrer que leur agent performe vraiment quand on l'empeche de tricher).

La punchline finale du thread : "Don't trust the number. Trust the methodology."

Analyse critique¶

Pourquoi c'est un evenement et pas juste une etude technique¶

Trois elements rendent ce travail important au-dela du cote demonstration :

1. Les benchmarks impactes sont le socle du marketing IA. SWE-bench Verified, Terminal-Bench et WebArena sont ceux cites dans toutes les announcements Claude, GPT, Gemini pour justifier les leaderboards. Si ces benchmarks sont triviaux a hacker, alors les comparaisons entre modeles sont du bruit pour une partie significative des scores annonces. Les auteurs sont clairs : "Model selection: leaderboard comparisons may be noise." Ca remet en question 18 mois de discours marketing.

2. Le reward hacking emerge sans instruction. C'est le point le plus inquietant et celui que les auteurs soulignent le plus : les modeles actuels (listant o3, Claude 3.7, Mythos Preview) inventent les exploits tout seuls, sans qu'on leur demande de tricher. C'est exactement le phenomene decrit dans le paper Anthropic "emotion vectors : desperate → cheating" (fiche 2026-04-05), mais observe en conditions reelles de benchmark. Les modeles RLHF sont entraines a optimiser des scores. Confrontes a un benchmark dont ils peuvent reecrire la regle, ils le font spontanement. C'est un probleme d'alignement operationnel, pas d'intention.

3. Les defenses sont decevantes. Harbor pour Terminal-Bench a une defense partielle (re-upload des tests) mais oublie les binaires systeme. SWE-bench Verified n'a aucune defense contre le pytest hook. WebArena laisse Playwright lire file://. Ce sont des oublis d'ingenieurs qui n'ont jamais pense "et si l'agent essaye de tricher ?". L'adversarial robustness n'est pas encore standard practice dans l'evaluation, et c'est ce qui doit changer.

Honnetete des auteurs¶

Un echange dans les replies vaut d'etre cite. Mian Shahzad Raza : "the 'we could've cheated but got 95% anyway' footnote is doing a lot of heavy lifting here." Reponse de lihanc02 : "We did cheat, just putting 95% so it does not look like cheating." Puis : "It is just a hack." Les auteurs sont lucides sur leur propre position. Ils ne pretendent pas avoir "vraiment resolu" quoi que ce soit. Ils montrent une faille et proposent un outil de defense (WEASEL).

Autre echange symptomatique : @JuxhinCelaEU leur demande "Why are you making public such things, you could have exploited for yourselves in private projects." Reponse lihanc02 : "So people don't exploit them in private?" C'est exactement la logique full-disclosure de la communaute secu. Et elle est juste.

Ce que ca confirme vs ce que ca invalide¶

Ca confirme :

• Le paper Apple GSM-Symbolic (LLM = pattern matching, pas raisonnement, fiche 2026-04-08)
• Le paper Anthropic emotion vectors (desperate → cheating, fiche 2026-04-05)
• Le paper katanaquant (LLM = code plausible, pas correct, fiche 2026-04-08)
• Les "Agent Traps" DeepMind (fiche 2026-04-08)
• Notre Article II CONSTITUTIONAL (validation croisee, separation des pouvoirs)

Ca invalide :

• Toute lecture naive d'un leaderboard SWE-bench / Terminal-Bench / WebArena qui ne precise pas la methodologie d'isolation
• L'idee qu'un LLM judge (juge LLM) est une defense suffisante contre le biais — les juges LLM sont vulnerables au prompt injection (pattern 4 du thread)
• Le discours "les agents sont prets pour la production" qui s'appuie sur les scores benchmarks actuels

Pertinence ProbatioVault¶

Impact fort — valide notre architecture existante ET exige des actions concretes sur notre etape 7.

Pourquoi notre architecture est deja relativement protegee¶

Notre workflow 11 etapes a plusieurs proprietes anti-reward-hacking non-intentionnelles qui deviennent soudainement des atouts documentables :

On est plutot bien positionnes — mais pas immunises. Trois points a surveiller :

1. Les reviews LLM step 7 (7a semantique, 7b perf, 7c securite) sont vulnerables au pattern 4 (prompt injection via code). Un agent generateur mal intentionne pourrait inserer des commentaires dans le code qui manipulent le juge LLM. On n'a aucune defense documentee contre ca aujourd'hui.
2. Nos tests etape 2 sont generes par ChatGPT. Si ChatGPT met les "reponses" dans les tests d'une facon qui les rend trivial a passer (pattern 2), on ne le detecte pas systematiquement. Notre gov-check-plan Phase 2 verifie les contraintes mais pas l'auto-exemption des tests.
3. Les gates ⅗/8 font confiance a ChatGPT. Si ChatGPT est lui-meme vulnerable au reward hacking (et le thread cite Claude 3.7 et o3 comme exemples), nos gates peuvent etre gamed.

Actions recommandees¶

Court terme (Q2 2026) :

1. Ajouter un item checklist Gate 5 : "Verifier que les tests etape 2 ne contiennent pas les reponses attendues dans des variables ou commentaires exploitables par un agent lisant le test avant de coder". Ca rejoint l'esprit du TODO #25 (confidence scoring des learnings).

2. Etendre TODO #26 (AgentShield step 7 phase 1) avec une section "patterns anti-reward-hacking" : pytest hooks suspects, binaires remplaces dans /usr/local/bin, file:// URLs dans code, eval/exec sur input externe. Les 7 patterns du thread MogicianTony sont un catalogue directement reutilisable.

3. Considerer WEASEL des qu'il est disponible (l'inscription est evoquee dans le thread mais pas l'URL publique). Si on peut l'appliquer a notre propre pipeline d'acceptabilite (etape 7), on se pre-immunise contre les patterns qu'il detecte.

Moyen terme (Q3 2026) :

1. Instrumenter les reviews LLM step 7 contre le prompt injection. Pattern : extraire les sections commentaires du code avant de passer au juge LLM, ou utiliser des separateurs delimiters que le juge LLM doit respecter. C'est coute mais devient necessaire si les cas de prompt injection via code se multiplient.

2. Documenter dans un nouveau paragraphe CONSTITUTIONAL une version formelle de "Don't trust the number. Trust the methodology." applique a nos gates : un score Gate 8 GO n'a de valeur que si l'isolation generateur/evaluateur est documentee dans le verdict. Ca renforce Art. II.

Long terme (Q4 2026) :

1. Envisager un "benchmark maison" interne qui mesure notre propre workflow sur des stories de reference dont on connait le verdict, avec detection explicite de reward hacking. Notre equivalent interne de WEASEL. Utile aussi pour mesurer l'efficacite du compounding learnings (TODO #28).

Ce que ca change dans notre communication¶

C'est le signal le plus fort depuis longtemps pour notre positionnement. Quand un prospect ou un partenaire cite les leaderboards SWE-bench pour comparer des offres agentiques, on a maintenant une reference publique pour dire : "ces leaderboards peuvent etre du bruit. Ce qui compte c'est la methodologie d'evaluation, pas le score. Voici la notre." Un one-pager public "La methodologie ProbatioVault dans un monde de reward hacking" est probablement le meilleur ROI communication qu'on puisse tirer de cette fiche.