Un seul benchmark de sûreté ne dit pas si votre agent est sûr

De quoi s’agit-il ?

Il s’agit d’une méta-étude 2026 qui prend pour objet les benchmarks de sûreté d’agents eux-mêmes, plutôt que d’en proposer un de plus. Dans « Taxonomy and Consistency Analysis of Safety Benchmarks for AI Agents » (arXiv:2605.16282, cs.CY), des chercheurs de McGill, Kean et de l’université Zayed cataloguent 40 benchmarks comportementaux de sûreté d’agents publiés entre avril 2023 et mars 2026, plus cinq artefacts adjacents (évaluateurs, jeux de données), et posent une question faussement simple : si deux équipes évaluent le même agent sur deux benchmarks de « sûreté d’agent » différents, aboutissent-elles à la même conclusion ?

La réponse est non. Le résultat central du papier est que le choix du benchmark peut faire passer un modèle de « sûr » à « non sûr », parce que ces benchmarks mesurent des choses discrètement différentes sous une même étiquette. Pour quiconque s’appuie sur une allégation de type « sûr sur le benchmark X », c’est tout l’enjeu : un score isolé ne veut presque rien dire sans savoir quel benchmark, ce qu’il a réellement éprouvé et comment il a noté.

Comment ça marche

Les auteurs construisent une taxonomie à six axes de la façon dont un benchmark évalue réellement un agent, puis codent les 40 benchmarks selon ces axes. Les six axes sont : la source de pression adverse (le danger vient-il d’un utilisateur malveillant, d’un document injecté, ou de la planification défaillante de l’agent lui-même ?), la fidélité de l’environnement (sandbox textuelle vs outils conteneurisés vs système réel), le périmètre de capacités de l’agent (texte seul vs exécution réelle d’outils et de code), la méthode de scoring, la granularité de l’évaluation de sûreté (résultat final vs comportement pas à pas) et le couplage sûreté-utilité (mesure-t-on des refus isolés ou l’arbitrage face à la réalisation de la tâche ?).

Coder le corpus de cette manière révèle à quel point le paysage est concentré. Sur l’axe fidélité, 34 des 40 benchmarks tournent en sandbox, quatre sont conteneurisés et un seul touche un environnement réel — la « sûreté » mesurée l’est donc dans le cadre le moins semblable à la production. Le papier constate aussi que le champ teste massivement les menaces imposées de l’extérieur (requêtes nuisibles, injection de prompt) tout en sous-testant les risques internes à l’agent, comme un agent autonome poursuivant de lui-même un plan dangereux, et il soutient que la robustesse n’est en pratique pas évaluée.

Pour prouver que ce désaccord est réel et non un artefact, les auteurs mènent un test de cohérence croisée sur quatre benchmarks largement utilisés (AgentHarm, AgentDojo, InjecAgent et ODCV-Bench), sur les modèles disposant de données complètes, avec des intervalles de confiance à 95 % et un test de concordance W de Kendall. Résultat : W = 0,10 (p = 0,94) — statistiquement, aucune preuve que les quatre benchmarks classent les modèles dans le même ordre. Les corrélations par paires sont elles aussi instables, aucune paire ne survivant à la correction pour comparaisons multiples.

Pourquoi c’est important

Les allégations de sûreté des agents deviennent une monnaie d’achat. « Réussit AgentHarm », « score X sur AgentDojo » et formules analogues apparaissent de plus en plus dans les fiches modèles, les présentations commerciales et les décisions internes de go/no-go. Ce travail montre que ces nombres ne sont pas interchangeables et souvent même pas corrélés : traiter l’un d’eux comme le verdict de sûreté est une erreur — un modèle peut dominer un classement et se retrouver en bas d’un autre qui éprouve une menace différente.

Le biais de sandbox compte tout autant. Si le nombre rassurant provient d’un environnement textuel contraint, et que vous vous apprêtez à déployer le même modèle avec un accès réel à des outils, au réseau et à l’exécution de code, le benchmark a mesuré un problème strictement plus facile que le vôtre. Dans le corpus, les évaluations à haute fidélité rapportent une sûreté systématiquement différente — et souvent pire — que les sandbox. L’écart entre « sûr sur le benchmark » et « sûr dans votre déploiement » est précisément là où surviennent les incidents.

Défenses

Le papier est une contribution de mesure ; sa valeur pratique tient à la manière dont vous consommez et exécutez les évaluations de sûreté d’agents.

• Ne faites jamais confiance à un score de benchmark isolé. Triangulez plusieurs benchmarks aux modèles de menace explicitement différents (nuisance dirigée par l’utilisateur, injection indirecte, désalignement autonome) et attendez-vous à des classements divergents — cette divergence est une information, pas du bruit.
• Alignez la fidélité de l’environnement sur votre déploiement. Un résultat sandbox, texte seul, ne se transpose pas à un agent doté d’outils réels et d’exécution de code. Réévaluez dans des conditions proches de la production avant de croire une étiquette « sûr ».
• Testez explicitement la robustesse. La robustesse adaptative et adverse étant l’axe le moins couvert, ajoutez votre propre red teaming adaptatif plutôt que de supposer qu’un benchmark statique l’a capturée.
• Évaluez le risque interne à l’agent, pas seulement les attaques injectées. Incluez des scénarios où l’échec provient du plan de l’agent lui-même, pas d’une charge externe — cette classe est systématiquement sous-testée.
• Exigez un reporting minimal. À la lecture comme à la publication, exigez que soient précisés le modèle de menace, la fidélité de l’environnement, le périmètre de capacités, la méthode de scoring, la granularité et l’arbitrage sûreté-utilité. Le papier propose exactement ces standards minimaux de reporting, qui permettent de distinguer les nombres comparables des incomparables.

Statut

Élément	Référence	Note
Taxonomie & analyse de cohérence (ce travail)	arXiv:2605.16282	40 benchmarks codés sur 6 axes ; W de Kendall = 0,10 (p = 0,94) sur 4 benchmarks — aucune concordance de classement
Survey sécurité agentique	arXiv:2510.06445	Taxonomie en trois piliers (applications/menaces/défenses) sur 160+ papiers ; cartographie du paysage
Design patterns pour sécuriser les agents LLM	arXiv:2506.08837	Cadre défensif complémentaire : patterns d’architecture pour contraindre les agents face à l’injection de prompt