Quand l’agent demande plus que vous : lire OverAct
Vous demandez à un assistant un créneau libre jeudi.
Vous demandez à un assistant un créneau libre jeudi. Il fouille aussi vos e-mails et liste vos contacts, au cas où. Chaque appel semble raisonnable seul. Ensemble, c’est un accès que personne n’a demandé. C’est cet écart que le préprint OverAct, publié sur arXiv le 1er octobre, tente de mesurer.
En bref
Résultats rapportés : OverAct est un banc d’essai déterministe, sans juge, de la sur-autorisation proactive, c’est-à-dire des appels d’outils au-delà du besoin d’une requête. Il couvre huit domaines sensibles pour la vie privée, six outils chacun. Les sept modèles testés dépassent tous l’ensemble minimal, avec une inflation de portée de base de 1,18 à 2,39 fois. Une étape de filtrage, SelfAudit, a réduit de 43 % un score d’excès de données personnelles sur les requêtes moyennes et vagues, au prix d’une partie de la couverture des tâches. ↗
Ce que compte OverAct
Le banc utilise 720 épisodes en banque, santé, commerce en ligne, e-mail et agenda, RH, maison connectée, voyage et réseaux sociaux, soit 48 outils. Sept modèles de quatre familles ont été exécutés trois fois par condition, environ 90 720 exécutions principales. La métrique principale, le rapport d’inflation de portée, divise le nombre d’outils appelés par la taille d’un ensemble minimal annoté. Les valeurs de base vont de 1,18 (DeepSeek-v3, qui a aussi la plus faible complétion) à 2,39 (DeepSeek-v4-Pro) ; GLM-5.2 est à 1,96. Cela fait en moyenne environ 0,7 appel en trop par épisode. ↗
Les demandes floues coûtent le plus
La formulation de la requête pèse le plus. Les requêtes précises donnent une conformité quasi parfaite, les vagues un excès 2,7 fois plus grand. Parmi les correctifs au niveau du prompt, une liste de permissions exacte atteint un rapport de 0,96 avec une couverture de 0,95, mais suppose de connaître l’ensemble minimal. Portée explicite (1,42), minimisation (1,18) et clarification (1,09, couverture 0,74) échangent couverture et portée de façons différentes. Une liste avec des outils en plus aide peu : les modèles exploitent la marge à peu près proportionnellement. Mon analyse : une liste d’autorisations large est un contrôle plus faible qu’il n’y paraît. ↗
Un correctif qui agit comme un filtre
SelfAudit demande à l’agent de justifier chaque appel prévu par les mots de l’utilisateur, puis retire les appels injustifiés avant exécution. Dans l’ablation sur les épisodes moyens et vagues, la justification seule aggrave (score de vie privée +9 %), le filtrage seul le réduit de 36 %, et le pipeline complet de 43 % (de 2,26 à 1,29), avec une couverture qui passe de 0,94 à 0,89. Les auteurs parlent de preuve de concept. Ma lecture : énoncer une raison ne contraint pas un modèle, une étape séparée qui peut refuser, si.
Un compteur jouet que j’ai écrit
J’ai écrit un exemple inventé avec des noms d’outils inventés et l’ai exécuté en local : une requête qui exige un outil d’agenda, un agent qui en appelle trois. Le code calcule un rapport de portée de 3,0 et une couverture complète, puis montre qu’un seul mauvais outil donne aussi un rapport de 1,0 avec une couverture de 0. C’est pourquoi l’article lit les deux nombres ensemble. Les entrées sont inventées et le code n’est pas le compteur de l’article.
Ce que cela ne montre pas
Les auteurs notent que les schémas sont contrôlés, avec six outils par domaine, donc les niveaux absolus en production peuvent différer. Le modèle théorique est calibré après coup, le score de vie privée traite toutes les catégories de données de la même façon, et le critère strict peut classer comme excès des appels utiles. La couverture est ici le rappel de l’ensemble minimal, pas la preuve qu’une tâche est accomplie. J’ai lu seulement le préprint : je n’ai exécuté ni le banc ni l’atténuation, et je n’ai pas vérifié de publication publique du code.
Vérification synthétique originale
# Invented tool names. Compare an agent's calls with the minimal set.
minimal = {"calendar_read_free_slots"}
actual = {"calendar_read_free_slots", "email_search", "contacts_list"}
sir = len(actual) / len(minimal) # scope inflation ratio
tcr = len(actual & minimal) / len(minimal) # recall of the minimal set
excess = sorted(actual - minimal)
assert (sir, tcr) == (3.0, 1.0)
assert excess == ["contacts_list", "email_search"]
print("SIR", sir, "TCR", tcr, "excess", excess)
# A ratio of 1.0 is not proof of compliance: the right count can hide the wrong tool.
wrong = {"email_search"}
assert len(wrong) / len(minimal) == 1.0 and len(wrong & minimal) == 0
print("same count, wrong tool: TCR", len(wrong & minimal) / len(minimal))