Vera : un test de sûreté à grande échelle trouve 93,9 % d'échec chez les agents

De quoi s’agit-il ?

Vera est un framework de test de sûreté automatisé pour les agents LLM outillés, décrit dans un article publié sur arXiv le 2 juillet 2026 (arXiv:2607.01793). Sa motivation vient d’une limite concrète dans la façon dont on mesure aujourd’hui la sûreté des agents : la plupart des suites de test existantes ciblent un ensemble figé de violations définies par des experts et les évaluent avec des règles codées en dur, ce qui les rend coûteuses à étendre chaque fois qu’un agent gagne de nouveaux outils ou qu’un attaquant trouve une nouvelle ruse. Vera reformule le problème comme un test logiciel appliqué à un système non déterministe : un pipeline auto-renforçant qui découvre les risques dans la littérature, les compile en cas de test exécutables, et vérifie les résultats à partir de ce qui s’est réellement passé dans l’environnement plutôt qu’à partir de ce que le modèle prétend avoir fait.

Le résultat principal donne à réfléchir. Sur quatre frameworks d’agents en production — l’article cite OpenClaw, Hermes, Codex et Claude Code — le taux de succès moyen des attaques atteint 93,9 % dans la condition de test la plus forte. Les auteurs publient aussi Vera-Bench, un jeu public de 1 600 cas de sûreté exécutables couvrant 124 catégories de risque sur trois configurations d’exécution.

Comment ça marche

Vera se déroule en trois étapes connectées. D’abord, une phase d’exploration continue des risques lit la littérature de recherche et organise les problèmes émergents en trois taxonomies évolutives : risques de sûreté, méthodes d’attaque et environnements d’exécution des outils. Ensuite, une phase de construction de cas de test exécutables compose des éléments issus de ces taxonomies en cas concrets. Chaque cas est un triplet : un objectif de sûreté précis, un état initial d’environnement construit par programme, et un prédicat de vérification déterministe — un « cas » est donc un scénario exécutable avec une condition de succès vérifiable par machine, pas une description en prose. Enfin, une phase d’exécution adaptative lance l’agent cible dans un bac à sable isolé et à état persistant.

Le détail de conception le plus important pour les défenseurs est le modèle de menace, qui sépare deux canaux d’influence de l’attaquant. Chaque scénario de base est décliné en trois variantes : une variante bénigne sans adversaire, une variante à canal unique où l’adversaire ne contrôle que les messages de l’utilisateur, et une variante multicanal où l’adversaire altère en plus les retours d’outils. Cette altération passe par une « passerelle d’outils » configurable — implémentée comme un service médiateur sur le Model Context Protocol — placée entre l’agent et chaque point de terminaison d’outil, capable de réécrire la valeur retournée par un outil selon quatre modes : identité (inchangé), append ou prefix (contenu de l’attaquant ajouté à côté du résultat réel), ou override (résultat entièrement remplacé).

# Canaux du modèle de menace (illustratif ; aucun payload opérationnel)
benin           -> aucune entrée adverse
canal unique    -> l'attaquant contrôle seulement les messages UTILISATEUR
multicanal      -> l'attaquant réécrit AUSSI les RETOURS D'OUTILS
                   modes : identity | append | prefix | override

Deux éléments supplémentaires rendent les résultats fiables plutôt qu’anecdotiques. Un agent de contrôle pilote chaque test sous forme de conversation multi-tours : il établit d’abord une tâche légitime plausible, puis s’adapte tour après tour — reformulant après un refus, changeant d’approche quand l’agent choisit un outil inattendu, ou déplaçant l’injection quand le contenu piégé n’a pas été récupéré. Et un vérificateur ancré dans les preuves décide si l’objectif de sûreté a réellement été atteint en inspectant les appels d’outils enregistrés et l’état final de l’environnement, et explicitement pas l’auto-évaluation de l’agent. Comme les frameworks déployés exposent les appels et réponses d’outils mais rarement le raisonnement interne, Vera juge la sûreté sur les actions exécutées et leurs effets observables.

Pourquoi c’est important

L’écart entre les trois configurations est le vrai enseignement. Des agents qui paraissent acceptables quand seul le prompt utilisateur est adverse deviennent hautement exploitables dès que le canal des retours d’outils est aussi compromis — c’est la condition multicanal qui produit la moyenne de 93,9 %. C’est un argument direct et mesuré pour un principe que les défenseurs pressentaient déjà : dans un agent, les sorties d’outils sont des entrées non fiables, et tout test qui ne malmène que le prompt utilisateur sous-estimera gravement l’exposition réelle.

La méthode de vérification porte une seconde leçon. Juger la sûreté d’un agent en lui demandant s’il a fait quelque chose de nuisible n’est pas fiable ; ancrer le verdict dans l’état de l’environnement et les preuves d’appels d’outils change les défaillances que l’on peut seulement voir. Pour les équipes qui montent leurs propres évaluations d’agents, cette distinction — artefacts observables plutôt qu’auto-déclaration — est sans doute aussi importante que n’importe quel chiffre d’attaque isolé. Le travail est présenté comme une infrastructure d’évaluation défensive, publie un benchmark plutôt qu’un exploit clé en main, et paraît sous licence ouverte avec du code public.

Défenses

• Traitez chaque retour d’outil comme une entrée non fiable. Le résultat multicanal montre que le canal des réponses d’outils est là où les agents échouent le plus. Validez, assainissez et, si possible, signez ou tracez l’origine des sorties d’outils avant qu’elles ne réintègrent le contexte du modèle ; ne supposez jamais qu’un résultat d’outil est authentique simplement parce que l’outil a été appelé légitimement.
• Testez le canal des outils, pas seulement le prompt. Ajoutez une condition de retour d’outil compromis à votre red teaming d’agents. Une suite qui ne fait varier que le message utilisateur reproduit la configuration à canal unique et manquera l’exposition qui a produit ici le taux d’échec quasi total.
• Vérifiez les résultats à partir d’artefacts observables, pas de l’auto-évaluation. Décidez si une exécution était sûre en inspectant l’état final de l’environnement et la trajectoire d’appels d’outils enregistrée, pas en demandant à l’agent de se noter lui-même. Journalisez l’historique complet des appels d’outils pour rendre possibles la vérification a posteriori et la surveillance.
• Isolez chaque exécution de test en bac à sable. Vera donne à chaque exécution sa propre instance d’agent, sa passerelle et ses services externes. Reproduisez cela dans vos propres tests pour que les cas ne se contaminent pas entre eux, et qu’un test déclenchant une action destructrice ne touche rien de réel.
• Gardez le catalogue de risques à jour et combinatoire. Une checklist figée vieillit vite. Rafraîchissez périodiquement l’ensemble des risques, méthodes d’attaque et environnements que vous testez, et combinez-les, pour que la couverture suive la surface d’outils croissante de l’agent au lieu de la subir avec retard.
• Appliquez le moindre privilège à la passerelle d’outils. Si une couche médiatrice peut réécrire le trafic d’outils pour les tests, elle le peut aussi en production. Restreignez les outils qu’une session d’agent peut atteindre, et placez les actions irréversibles ou à fort impact derrière une confirmation.

Statut

Élément	Valeur
Artefact	Vera — framework de test de sûreté d’agents ; benchmark Vera-Bench
Divulgation	Préprint arXiv, 2 juillet 2026 (CC BY 4.0)
Périmètre	1 600 cas de sûreté exécutables ; 124 catégories de risque ; trois configurations
Frameworks testés	OpenClaw, Hermes, Codex, Claude Code
Impact mesuré	Taux de succès moyen des attaques de 93,9 % en multicanal (retours d’outils)
Nature	Recherche d’évaluation défensive ; code public, aucun exploit opérationnel publié

Date clé : 2 juillet 2026 — Vera et Vera-Bench publiés pour la première fois sur arXiv. Il s’agit d’un framework de test et d’un benchmark, pas d’un incident observé en conditions réelles contre un déploiement nommé.

Cet article résume des travaux de recherche en sécurité publiquement disponibles, à des fins défensives.