SABER : les agents de code échouent à la sûreté opérationnelle même quand ils refusent les prompts malveillants

De quoi s’agit-il ?

Le 31 mai 2026, Qi Hu et ses co-auteurs ont publié SABER: Benchmarking Operational Safety of LLM Coding Agents in Stateful Project Workspaces (arXiv:2606.01317, cs.SE / cs.CR). SABER mesure ce que la plupart des benchmarks de sûreté ignorent : non pas si un modèle refuse une instruction dangereuse, mais dans quel état se retrouve un véritable espace de travail après que l’agent a exécuté toute une séquence d’actions. Le benchmark et son harnais sont publiquement disponibles.

Le résultat principal est inconfortable. Selon les auteurs, même le modèle le plus performant laisse une violation de sûreté nuisible dans plus de 54 % des runs. L’entraînement au refus — ce que l’on appelle habituellement « alignement » — ne protège pas de façon fiable le système de fichiers, l’historique git ou les dépendances que l’agent manipule en chemin.

Comment ça marche

L’évaluation classique de la sûreté des LLM se fait en un tour : vous envoyez un prompt, vous vérifiez si la réponse refuse ou obéit. Ce cadre s’effondre pour les agents de code, où le préjudice est rarement une phrase isolée et presque toujours un effet de bord accumulé au fil d’une séquence d’appels d’outils.

SABER recentre l’unité d’évaluation sur l’environnement, et non sur la réponse :

Benchmark de refus de prompt     SABER (sûreté opérationnelle)
----------------------------     -----------------------------
prompt d'entrée                  vrai projet d'agent
   |                                |
réponse du modèle                séquence d'actions multi-étapes
   |                                |  (édition, exécution, install, suppression...)
« refusé ? » oui/non             état final du dépôt
                                    |
                                 inspecter : qu'est-ce qui a été abîmé ?
                                    |
                                 classer la violation par cause

L’agent est placé dans un projet réaliste et stateful, et chargé d’effectuer un travail de développement normal. SABER inspecte ensuite l’état final de l’environnement à la recherche de résultats nuisibles — opérations destructrices sur les fichiers, changements de dépendances dangereux, effets de bord hors du périmètre demandé — plutôt que de lire la transcription du chat à la recherche d’un refus poli. Surtout, il ne s’arrête pas à un succès/échec binaire : les violations sont classées par cause, ce qui permet de construire un profil de sûreté par modèle plutôt qu’un chiffre unique. Les auteurs rapportent que ces profils diffèrent nettement d’un modèle à l’autre : « quel agent est le plus sûr » dépend donc de quelle classe d’erreur vous importe le plus.

Aucun exploit ni payload d’attaque n’est requis ici. Le dommage dans SABER provient de l’exécution ordinaire d’une tâche qui tourne mal, ce qui en fait précisément un repère défensif utile plutôt qu’une technique d’attaque.

Pourquoi c’est important

Les agents de code tournent désormais avec de vrais privilèges : ils éditent du code source, exécutent des commandes shell, installent des paquets et committent dans des dépôts, souvent avec une revue humaine limitée à chaque étape. L’OWASP Top 10 for Agentic Applications (2026) place exactement ce type de risque — agentivité excessive et usage d’outils dangereux — en haut de sa liste.

L’apport de SABER est de montrer qu’un modèle peut être parfaitement poli — refusant chaque prompt manifestement malveillant — et malgré tout corrompre un espace de travail plus d’une fois sur deux par de simples erreurs opérationnelles. Si votre modèle de risque suppose « l’agent a refusé les mauvaises choses, donc nous sommes en sécurité », vous mesurez la mauvaise frontière. Le chiffre de 54 %+ est un résultat de benchmark sur un jeu de test soigné, pas un taux d’incidents en production, mais la direction est claire : le comportement de refus et la sûreté opérationnelle sont des propriétés distinctes, et l’alignement actuel optimise surtout la première.

Défenses

Le benchmark est un outil de mesure, mais il pointe directement vers des mitigations bien établies. Traitez le runtime de l’agent — et non ses bonnes intentions — comme la surface de contrôle :

• Moindre privilège au niveau des outils. Restreignez l’accès au système de fichiers, au réseau et au shell au strict périmètre de la tâche. Un agent qui ne peut pas faire un rm -rf hors de son répertoire de travail ne peut pas laisser cette violation-là, quel que soit son raisonnement.
• Sandboxer l’espace de travail. Exécutez les sessions d’agent dans des conteneurs ou des worktrees jetables, afin qu’un état final corrompu soit jeté et non fusionné. Le travail Design Patterns for Securing LLM Agents (juin 2025) défend le même argument architectural : contraindre ce que l’agent peut faire plutôt que lui faire confiance pour bien se comporter.
• Verrouiller les effets irréversibles. Exigez une approbation humaine explicite pour les opérations destructrices ou hors périmètre — suppressions, force-push, retraits de dépendances, accès aux secrets — au niveau de l’effet final, pas du prompt.
• Évaluer sur l’état final, pas les transcriptions. Adoptez des tests de sûreté opérationnelle (à la SABER) dans votre CI pour tout agent déployé, et suivez les profils de violation par cause dans le temps plutôt qu’un simple score de refus.
• Garder une piste d’audit. Journalisez la séquence d’actions complète pour qu’un état final nuisible puisse être tracé jusqu’à l’étape qui l’a causé, puis annulé.

Statut

Élément	Détail
Publication	arXiv:2606.01317, soumis le 31 mai 2026
Type	Benchmark / évaluation défensive (cs.SE, cs.CR)
Constat clé	Taux de violation de sûreté nuisible > 54 % pour le meilleur modèle évalué
Code	Publiquement disponible — github.com/sssr-lab/saber
Exploit actionnable	Aucun — mesure de sûreté opérationnelle, pas une attaque

Note : les chiffres et dates ci-dessus proviennent du résumé du papier tel que publié sur arXiv le 31 mai 2026. Les noms de modèles précis sont omis ici car le résumé ne les divulgue pas ; consultez le papier pour le jeu d’évaluation complet.