Tester la sécurité des agents autonomes par les specs et les trajectoires

De quoi s’agit-il ?

En juin 2026, un article intitulé SeClaw: Spec-Driven Security Task Synthesis for Evaluating Autonomous Agents (arXiv:2606.02302) a proposé une méthode pour construire et exécuter des tests de sécurité destinés aux agents LLM outillés. Les auteurs qualifient leur travail de préliminaire et encore en cours, mais le cadrage mérite votre attention dès maintenant, car il s’attaque à un problème de mesure que la plupart des équipes qui déploient des agents rencontrent déjà. Les agents modernes ne se contentent plus de répondre : ils lisent des fichiers, appellent des outils, conservent une mémoire persistante et accèdent à des services externes. C’est précisément cette autonomie élargie qui rend leur sécurité difficile à mesurer.

L’argument de l’article est que les benchmarks de sécurité d’agents existants partagent trois faiblesses. Ils reposent sur des tâches conçues manuellement, difficiles à passer à l’échelle et limitées par ce qu’un annotateur humain a pensé à écrire. Ils ne couvrent qu’une fraction du paysage des menaces, car un jeu figé d’instances ne peut pas facilement s’étendre à de nouveaux risques. Et ils jugent un agent surtout sur sa réponse finale, alors qu’un comportement dangereux est généralement une séquence d’actions qui se produit avant que quoi que ce soit n’apparaisse dans le dernier message. SeClaw répond à ces trois lacunes.

Comment ça marche

Il s’agit ici de la description d’un cadre d’évaluation, pas d’une attaque, et aucun payload n’est fourni. SeClaw comporte deux volets.

Le premier volet est la synthèse de tâches pilotée par spécification. Les auteurs organisent le risque des agents en quatre sources — les ressources (prompts système, skills, mémoire, serveurs MCP), les tâches utilisateur, les retours d’environnement (pages web, sorties d’outils, fichiers) et les défauts intrinsèques du modèle ou du framework. Un expert humain, assisté d’un agent de code, rédige une spécification structurée pour un risque cible : le point de risque, le rôle de l’agent, la tâche vue par l’utilisateur, l’origine du danger, le comportement dangereux à tester et les contraintes de sûreté. Un pipeline multi-agents transforme ensuite cette spécification en prototype de tâche, l’instancie en une tâche exécutable dotée d’un vrai espace de travail, de services simulés, de fichiers et d’outils configurés, puis exécute une boucle de validation qui ne conserve que les tâches à la fois résolubles, reproductibles et effectivement discriminantes entre modèles faibles et forts.

Le second volet est l’évaluation par exécution. Chaque tâche s’exécute dans un bac à sable Docker isolé, avec un conteneur neuf par instance, de sorte que l’état ne fuit pas d’une exécution à l’autre. SeClaw enregistre toute la trajectoire — prompts, décisions du modèle, appels d’outils, réponses des services, opérations sur fichiers et artefacts finaux — et non seulement la réponse. La notation est délibérément à deux dimensions : un terme de couverture, pour le nombre de cibles de sécurité distinctes atteintes, et un terme de fiabilité, pour la constance avec laquelle les conditions dangereuses se déclenchent, combinés par une moyenne harmonique. Les auteurs insistent : ce score est orienté risque. Une valeur plus élevée signifie que le modèle évalué est plus vulnérable, pas plus compétent.

Pourquoi c’est important

Une évaluation centrée sur le résultat suppose implicitement que le danger d’un agent est visible dans sa réponse finale. Ce n’est souvent pas le cas. Un agent peut divulguer un identifiant, écraser un fichier ou enchaîner deux outils bénins en une action nuisible plusieurs étapes avant de produire un résumé qu’un évaluateur lira. Noter la trajectoire permet d’attribuer une défaillance à une étape précise — interprétation du modèle, choix de l’action, invocation d’outil ou réponse de l’environnement — ce qui rend un résultat reproductible et comparable entre agents.

Le volet synthèse compte tout autant. Les menaces sur les agents évoluent plus vite que les benchmarks écrits à la main ne peuvent les suivre, et un cadre qui génère des tâches fraîches et propres à un scénario, à partir d’une taxonomie de risques, colle mieux à l’évolution réelle de l’exposition. C’est le même virage vers une évaluation stateful, au niveau du processus, que l’on retrouve chez des travaux contemporains comme SABER, et qui prolonge l’approche environnement-dans-la-boucle établie par AgentDojo pour l’injection de prompt.

Défenses

Notez le processus, pas seulement la réponse. Si votre évaluation d’agent ne vérifie que la sortie finale, elle est aveugle à la chaîne d’appels d’outils qui l’a produite. Journalisez et notez toute la trajectoire, afin qu’un appel d’outil dangereux soit détecté même quand le message final paraît propre.

Isolez chaque exécution de test. Utilisez des bacs à sable par tâche, avec un conteneur par instance, des limites de ressources et un contrôle des permissions, pour qu’un état résiduel ne contamine pas l’exécution suivante et qu’un test qui dérape ne puisse pas toucher l’hôte.

Couvrez les quatre sources de risque. Ressources, tâches, environnement et défauts intrinsèques échouent différemment. Une suite qui ne teste que l’injection indirecte depuis le web passe à côté de l’abus de privilèges, du déni de service par abus de ressources et de l’enchaînement d’outils dangereux qui naissent ailleurs.

Gardez des humains aux points de contrôle qualité. La synthèse automatique passe la couverture à l’échelle, mais le sens sécurité de chaque tâche — ce qui compte comme dangereux, et pourquoi — exige une relecture humaine. Traitez les tests générés comme des candidats qui passent des vérifications explicites, non comme une vérité établie.

Rendez l’évaluation continue. Un benchmark figé se périme. Régénérez les tâches à mesure que de nouvelles classes de risques apparaissent et rejouez-les à chaque mise à jour d’agent et de modèle, plutôt que de certifier un agent une fois pour toutes.

État des lieux

Élément	Référence	Date	Notes
Article	arXiv:2606.02302	juin 2026	Synthèse de tâches pilotée par spécification + évaluation par trajectoire ; qualifié de travail préliminaire en cours
Taxonomie de risque	Ressources, tâches, environnement, intrinsèque	—	Quatre sources de risque d’agent utilisées pour piloter la génération de tâches
Méthode	Synthèse multi-agents → exécution en bac à sable Docker → journalisation de trajectoire → notation orientée risque	—	Un conteneur par instance ; couverture + fiabilité combinées par moyenne harmonique
Connexes	SABER ; AgentDojo	2024–2026	Évaluation de sûreté d’agents stateful / environnement-dans-la-boucle

SeClaw ne prétend pas rendre les agents sûrs — l’article soutient qu’on ne peut pas gérer ce qu’on ne mesure pas, et que mesurer la sécurité d’un agent, c’est observer toute l’exécution, pas seulement la dernière ligne. Pour les équipes qui déploient des agents outillés, l’enseignement est étroit et vérifiable : construisez l’évaluation autour des trajectoires et d’une exécution isolée, couvrez des sources de risque au-delà de celle que vous redoutez déjà, et régénérez sans cesse les tests à mesure que la surface d’attaque bouge.