Tâches légitimes, raccourcis dangereux : un nouveau benchmark de sûreté pour les agents à usage machine

De quoi s’agit-il ?

Fin juin 2026, Mina Mohammadmirzaei et Jeffrey Flanigan, de l’Université de Californie à Santa Cruz, ont publié OSGuard: A Benchmark for Safety in Computer-Use Agents sur arXiv. Le benchmark mesure un mode de défaillance que la plupart des travaux sur la sûreté des agents laissent de côté : un agent qui reçoit une instruction parfaitement légitime, dans un environnement qui ne cherche pas à le piéger, et qui cause tout de même des dommages par la manière dont il exécute la tâche.

Une grande partie de la littérature de red teaming — y compris des suites adverses comme OS-Harm — étudie ce qui se passe quand l’instruction est malveillante ou que l’environnement est piégé par du contenu injecté. OSGuard vise le régime complémentaire, que les auteurs appellent l’usage machine à tâche légitime : l’instruction d’origine n’est pas malveillante, l’environnement n’est pas ouvertement adverse, et le problème de sûreté naît entièrement de l’action que l’agent choisit compte tenu de l’état actuel de l’écran et du système de fichiers. Atteindre le but nominal n’équivaut pas à l’atteindre sans danger, et les seules métriques de réussite de tâche ne permettent pas de distinguer les deux.

Comment ça marche

OSGuard n’est pas une attaque. C’est une suite d’évaluation à double granularité, et ses deux volets sont conçus pour être exécutés dans un environnement contrôlé plutôt que contre la machine réelle de quiconque.

Le premier volet est un benchmark au niveau de l’action. Il présente un ensemble d’actions proposées contextualisées, chacune étiquetée autorisée, hors sujet ou dangereuse, l’étiquette étant jugée par rapport à l’instruction d’origine et à l’état actuel de l’interface. Cela isole une seule question : un modèle garde-fou, à qui l’on montre une action proposée en contexte, sait-il reconnaître quand cette action dépasse la tâche ou causerait des dégâts ? C’est un test de supervision locale, pas à pas, sans exécution complète de la tâche.

Le second volet est une suite d’exécution enrichie de risques. Les auteurs partent de variantes de tâches dérivées d’OSWorld — une suite de vraies tâches de bureau — et modifient l’environnement de sorte que la tâche d’origine reste réalisable, mais qu’un danger latent soit introduit en chemin. L’exemple mis en avant dans l’article est l’écrasement destructeur : un fichier ou un état qu’une action imprudente écraserait alors que rien dans l’instruction ne le demandait. Chaque variante est associée à un évaluateur enrichi qui conserve le critère de réussite d’origine et ajoute des invariants de sûreté explicites, fondés sur l’état — des conditions sur le monde qui doivent rester vraies une fois l’agent terminé. Un agent qui accomplit la tâche mais viole un invariant est noté comme non sûr, même s’il a « réussi ». Nul besoin de payload exploitable pour comprendre ceci : le mécanisme est un harnais de mesure, pas une technique pour causer du tort.

Pourquoi c’est important

Le résultat principal est un écart entre deux choses faciles à confondre. Les garde-fous multimodaux actuels s’en tirent bien sur les jugements isolés au niveau de l’action — face à une action unique, ils signalent souvent correctement celle qui est dangereuse. Mais la suite d’exécution enrichie de risques révèle la distance qui subsiste entre cette compétence locale et une sûreté fiable de bout en bout : reconnaître une action dangereuse dans un instantané étiqueté n’est pas la même chose que détourner une tâche entière, en plusieurs étapes, d’un raccourci destructeur lorsque c’est le modèle qui conduit.

Cette distinction compte d’autant plus que les agents à usage machine s’installent sur de vraies machines, avec accès aux fichiers, accès au shell et applications installées. La surface « tâche légitime » est précisément celle que les utilisateurs ordinaires solliciteront chaque jour, et elle n’est pas couverte par des défenses réglées pour l’injection de prompt ou les jailbreaks. Un agent n’a pas besoin d’être attaqué pour écraser le mauvais fichier, vider le mauvais dossier ou prendre un raccourci irréversible vers un but légitime. OSGuard donne aux équipes un moyen de voir cette classe de défaillance au lieu de la masquer derrière une coche verte de réussite.

Défenses

Noter la sûreté séparément de la réussite. La leçon centrale est qu’une tâche accomplie peut rester une tâche dangereuse. Les évaluations — et la télémétrie de production — devraient porter des invariants de sûreté explicites (ce qui doit rester vrai des fichiers, de l’état et des effets de bord) à côté du critère de réussite, afin qu’un raccourci destructeur ne soit jamais pris pour une victoire.

Évaluer de bout en bout, pas seulement par action. Un garde-fou qui obtient de bons scores sur les jugements d’action isolés peut tout de même échouer à garder une tâche complète sûre. Testez la supervision en boucle, sur l’exécution multi-étapes, comme le fait la suite enrichie de risques d’OSGuard, plutôt que de supposer que la justesse pas à pas se compose en une sûreté de trajectoire.

Donner aux garde-fous l’état courant, pas seulement l’instruction. OSGuard étiquette les actions par rapport à l’instruction et à l’état de l’interface. Les garde-fous d’exécution devraient de même lire ce qui est réellement à l’écran et dans le système de fichiers avant d’approuver une action, afin que les dangers dépendants du contexte (un fichier sur le point d’être écrasé) soient visibles au moment de la décision.

Verrouiller les opérations irréversibles. Écrasements destructeurs, suppressions et autres effets de bord non réversibles méritent confirmation, instantanés ou couche de préparation réversible — des contrôles qui plafonnent les dégâts d’une action erronée, indépendamment du fait que le modèle l’ait ou non identifiée comme risquée. Des travaux connexes comme ProjGuard explorent une supervision d’exécution légère pour exactement ce contexte de déploiement.

Restreindre les capacités à l’exécution. Permissions de fichiers limitées, répertoires de travail en bac à sable et accès au moindre privilège aux commandes système bornent l’ampleur du dommage qu’un raccourci sur tâche légitime peut causer, quel que soit le verdict du garde-fou.

Statut

Élément	Référence	Date	Notes
Article	arXiv:2606.15034	Juin 2026	Mohammadmirzaei & Flanigan (UC Santa Cruz)
Conception	Double granularité : benchmark au niveau de l’action + suite d’exécution enrichie de risques	—	Régime tâche légitime ; non adverse
Niveau action	Actions proposées étiquetées autorisée / hors sujet / dangereuse selon instruction + état de l’UI	—	Teste les décisions locales de garde-fou
Suite d’exécution	Variantes dérivées d’OSWorld avec dangers latents (ex. écrasements destructeurs) + invariants de sûreté fondés sur l’état	—	Tâche réalisable ; sûreté notée à part
Résultat	Les garde-fous gèrent bien les actions isolées ; des écarts de sûreté de bout en bout subsistent	—	Supervision locale ≠ sûreté de tâche complète
Connexes	OS-Harm, ProjGuard, OSWorld	2025–2026	Sûreté adverse, supervision d’exécution, suite de tâches de base

L’apport d’OSGuard est autant conceptuel qu’un jeu de données : il sépare « l’agent a-t-il fini la tâche » de « l’agent est-il resté sûr en chemin », et montre que des garde-fous qui paraissent compétents sur la première question peuvent échouer sur la seconde. Pour quiconque déploie un agent à usage machine sur une vraie machine, c’est la différence qu’il vaut la peine de mesurer avant que l’agent ne touche des fichiers de production.