Agent Security Benchmark : méthodologie et premières métriques
18 août 2026 · 12 min de lecture
Nous construisons un référentiel permettant de mesurer la résistance des agents IA face à différentes catégories d'attaques. Nous publions notre méthodologie, nos huit métriques et l'état d'avancement du projet.
Pourquoi ce projet
La sécurité des agents IA se discute aujourd'hui presque exclusivement de façon qualitative. Un système est décrit comme « robuste » ou « vulnérable » sans qu'aucun chiffre comparable ne permette de situer un système par rapport à un autre.
Notre objectif est de produire des métriques reproductibles, permettant de comparer deux configurations d'un même agent, ou de mesurer l'effet réel d'une mesure de sécurité.
Les huit métriques
| Métrique | Ce qu'elle mesure |
|---|---|
| Attack Success Rate | Proportion de tentatives qui atteignent leur objectif |
| Tool Abuse Rate | Fréquence d'utilisation d'un outil hors de son usage prévu |
| Data Leakage Rate | Fréquence d'exposition d'informations qui ne devaient pas l'être |
| Detection Rate | Proportion de tentatives identifiées par les mécanismes en place |
| False Positive Rate | Proportion de comportements légitimes bloqués à tort |
| Time to Exploit | Temps nécessaire avant d'obtenir un résultat |
| Number of Turns | Nombre d'échanges nécessaires |
| Severity | Gravité de la conséquence obtenue |
Deux d'entre elles méritent une attention particulière.
Le taux de faux positifs est souvent absent des discussions sur la sécurité des agents. Un système qui bloque tout est parfaitement sûr et parfaitement inutile. Une mesure de sécurité qui dégrade fortement l'usage légitime sera contournée par les équipes elles-mêmes.
Le nombre de tours distingue deux situations très différentes : un système qui cède immédiatement, et un système qui ne cède qu'après une construction longue et déterminée. Le second est significativement plus robuste, mais un taux de succès brut ne le montre pas.
Le protocole
Chaque test est mené sur une configuration documentée : modèle, instructions système, outils accessibles, sources de connaissance, mécanismes de contrôle.
Les catégories d'attaque évaluées couvrent la manipulation des instructions, l'abus des outils accordés, la fuite de contexte, le contournement des contrôles, et l'accès à des données appartenant à d'autres utilisateurs.
Chaque tentative est rejouée un nombre fixe de fois, les modèles de langage n'étant pas déterministes. Les métriques rapportées sont des moyennes accompagnées de leur variance.
État d'avancement
Le projet est en construction. Nous publions la méthodologie avant les résultats, pour deux raisons : permettre la critique du protocole avant qu'il ne produise des chiffres, et éviter de communiquer des mesures dont la méthode ne serait pas vérifiable.
Les tests sont menés sur des systèmes de test que nous construisons, ou sur des systèmes clients avec autorisation écrite. Aucun résultat identifiant un système tiers n'est publié.
Contribuer
Le protocole et les outils sont publiés sur notre dépôt. Les retours sur la méthodologie sont bienvenus, en particulier sur la définition des seuils de gravité.
