Safe, or Simply Incapable? Rethinking Safety Evaluation for Phone-Use Agents

Résumé technique : Sûr, ou simplement incapable ? Repenser l'évaluation de la sécurité pour les agents utilisant le téléphone

Énoncé du problème
Les évaluations de sécurité actuelles pour les agents utilisant le téléphone souffrent d'une ambiguïté fondamentale : un résultat inoffensif n'indique pas nécessairement un comportement sûr. Lorsqu'un agent évite de causer un préjudice à un moment risqué, cela peut être dû à un jugement sûr (reconnaître le risque et choisir la bonne action sûre) ou à une incapacité d'agir (échec à comprendre l'interface, localiser les contrôles ou exécuter toute action pertinente). Les benchmarks existants confondent souvent ces causes distinctes sous des métriques agrégées telles que « succès de la tâche », « refus » ou « résultat final nuisible ». Cette confusion entraîne deux problèmes critiques :

1. Surévaluation des modèles faibles : Les agents qui échouent à agir sont incorrectement crédités de sécurité car aucun préjudice n'est survenu.
2. Mauvais diagnostic des modèles puissants : Les agents qui comprennent l'interface mais font de mauvais choix de sécurité ne sont pas distingués de ceux qui ne peuvent tout simplement pas agir.

Alors que les agents passent d'assistants passifs à des systèmes capables d'exploiter directement les smartphones, un seul mauvais appui peut exposer des données privées, autoriser des paiements ou accorder des permissions. Évaluer si un agent fait le bon choix au moment où une frontière de sécurité devient pertinente pour l'action est distinct d'évaluer s'il peut accomplir une tâche.

Méthodologie : PHONESAFETY
Pour y remédier, les auteurs introduisent PHONESAFETY, un benchmark conçu pour évaluer les agents aux moments critiques pour la sécurité plutôt que sur l'ensemble des épisodes de tâches.

• Construction des données : Le benchmark est composé de 700 moments critiques pour la sécurité tirés de 4 512 trajectoires sur appareil réel à travers plus de 130 applications mobiles chinoises. Ces trajectoires couvrent des scénarios diversifiés, notamment des applications natives, des mini-programmes et des flux de travail inter-applications.
• Unité d'évaluation : L'unité d'analyse est le point de décision spécifique où l'action suivante peut directement déterminer la sécurité de l'interaction. Le modèle reçoit l'instruction de l'utilisateur, l'historique des interactions et le contexte de l'écran actuel, puis est invité à prédire la prochaine action sur le téléphone.
• Décomposition en trois voies : Au lieu d'une étiquette binaire sûr/non sûr, les résultats sont catégorisés en trois classes mutuellement exclusives :
  1. Action sûre : Le modèle s'engage dans la décision et choisit le côté sûr (par exemple, demander une confirmation, refuser une instruction nuisible, fermer une fenêtre contextuelle trompeuse).
  2. Action non sûre : Le modèle s'engage dans la décision mais franchit la frontière de sécurité (par exemple, procéder au paiement sans confirmation, accorder des permissions inutiles).
  3. Échec à faire quoi que ce soit d'utile (Échec de capacité) : Le modèle échoue à réaliser soit le comportement sûr, soit le comportement non sûr. Cela inclut le fait de toucher des zones sans rapport, de quitter la page ou de produire des actions malformées. Cette catégorie est traitée comme un signal opérationnel d'incapacité d'agir plutôt que comme une affirmation concernant les internes profonds du modèle.
• Métriques : Les auteurs rapportent le taux d'action sûre, le taux d'action non sûre et le taux d'échec de capacité (CFR). Ils suivent également $1 - \text{CFR}$ (le taux de production de toute action pertinente) comme proxy de la capacité opérationnelle générale.

Résultats clés
L'article évalue huit agents représentatifs utilisant le téléphone (y compris Gemini 3.1 Pro, Claude Opus 4.6 et AutoGLM 9B) et révèle deux modèles principaux :

1. La capacité générale ne prédit pas les choix sûrs :
   Il n'existe aucune corrélation fiable entre la performance générale d'un modèle dans l'utilisation du téléphone et son jugement de sécurité aux moments critiques.

   • Preuve : Les modèles classés hautement sur les tâches générales (par exemple, Seed 2.0 Pro) n'ont pas nécessairement les taux d'action sûre les plus élevés. Inversement, les modèles avec des scores généraux plus bas exhibent parfois une prise de décision plus sûre lorsque la frontière est explicite.
   • Implication : Une capacité opérationnelle élevée ne garantit pas un comportement sûr ; une évaluation dédiée à la sécurité est requise.

2. Modes d'échec distincts :
   Les échecs ne sont pas monolithiques ; ils se divisent en deux modèles distincts selon le scénario :

   • Choix non sûrs : Dans les scénarios nécessitant un simple refus (par exemple, la famille « Sécurité »), les échecs sont majoritairement des actions non sûres. Le modèle comprend l'interface mais choisit le mauvais côté de la décision (par exemple, procéder à une instruction nuisible).
   • Incapacité d'agir : Dans les scénarios exigeants sur le plan visuel et opérationnel (par exemple, « Résistance aux pièges », « Minimisation des permissions »), les échecs sont majoritairement des échecs à faire quoi que ce soit d'utile. Le modèle ne peut pas ancrer l'interface ou exécuter l'action nécessaire.
   • Corrélation : Le taux d'« échec à faire quoi que ce soit d'utile » (CFR) corrèle fortement avec la capacité générale d'utilisation du téléphone ($\rho = 0,922$), alors que les taux d'action sûre ne le font pas.

3. Invariance du protocole de l'incapacité :
   Lorsque le protocole d'évaluation (définissant ce qui constitue une action sûre par rapport à une action non sûre) varie, le taux d'action sûre change considérablement. Cependant, le taux d'échec de capacité (CFR) reste stable ($\Delta \text{CFR} = 0,0$). Cela confirme que « l'échec à faire quoi que ce soit d'utile » est un signal d'incapacité opérationnelle plutôt qu'une sensibilité à des définitions spécifiques de la sécurité.

Signification et affirmations
L'article soutient que pour les agents capables d'agir, l'inoffensivité ne constitue pas une preuve suffisante de sécurité. Un système ne devrait pas recevoir de crédit pour la sécurité simplement parce qu'aucun préjudice n'est survenu si ce résultat était le résultat d'une incapacité d'agir.

• Contribution principale : L'introduction d'un cadre d'évaluation en trois voies qui sépare le jugement non sûr de l'incapacité d'agir.
• Changement méthodologique : Le passage des résultats au niveau de l'épisode aux moments critiques pour la sécurité permet d'isoler le point de décision spécifique où la sécurité est déterminée.
• Implication pratique : L'évaluation de la sécurité doit distinguer un modèle qui choisit mal d'un modèle qui ne peut pas agir. Traiter « aucune action pertinente » comme un succès en matière de sécurité est une erreur méthodologique qui obscurcit la véritable nature des risques liés aux agents.

L'étude se limite à une évaluation hors ligne au sein d'un écosystème mobile chinois, mais les auteurs postulent que le principe sous-jacent — selon lequel les résultats inoffensifs doivent être interprétés et non simplement observés — s'applique largement aux agents capables d'agir dans le monde réel.