Quelles actions d'agent les équipes soumettent-elles à une validation humaine, et à quelle fréquence cette validation arrête-t-elle réellement quelque chose ?

Question ouverte

La spécification du Model Context Protocol (citée) indique qu'un humain doit toujours pouvoir, dans la boucle, refuser les invocations d'outils, et que les applications devraient présenter des invites de confirmation, et l'entrée « Excessive Agency » d'OWASP (citée) recommande un contrôle humain dans la boucle pour les actions à fort impact. Les deux relèvent de recommandations de conception ; ni l'une ni l'autre ne rend compte du comportement réel des validations en exploitation. La fatigue de validation est le mode d'échec le plus souvent cité : une personne à qui l'on demande de confirmer chaque appel cesse de lire les appels. Ce qui manque, ce sont des données d'exploitation issues d'agents en usage courant (agents de codage, automatisation du support, pipelines de données, agents de navigation) :

• Quels appels d'outils sont soumis à validation : par nom d'outil, par motif d'argument (un chemin hors de l'espace de travail, un destinataire extérieur à l'organisation), par seuil de montant, ou par un moteur de politique qui évalue chaque appel ?
• Combien de validations une personne traite par heure ou par tâche, et combien de temps prend une validation typique.
• Quelle proportion des demandes est refusée, et dans combien de cas un refus a empêché une action qui aurait causé un dommage, par opposition à une action inoffensive que l'agent a ensuite reformulée.
• Si les équipes ayant fait passer les validations de noms d'outils à des motifs d'arguments ou à des seuils ont observé moins d'invites sans perdre en capture.
• Si une validation est traitée comme un consentement pour le reste d'une session, et ce qui s'est passé lorsque c'était le cas.

Sans de tels décomptes, chaque politique de validation n'est qu'une supposition sur l'arbitrage entre le débit et l'unique appel qui aurait dû être arrêté.

Ce qu'une réponse utile contient

La tâche de l'agent et son jeu d'outils ; la règle de validation telle qu'exactement configurée, y compris toute condition au niveau des arguments ; la période d'observation et le nombre d'exécutions ; les décomptes d'invites, de validations et de refus ; des exemples de ce que les refus ont intercepté et de ce qui est passé au travers d'une validation ; toute mesure du temps consacré aux validations ; et les changements apportés aux règles par la suite, avec la raison. Les retours d'une seule équipe sont utiles s'ils sont présentés comme tels ; les propositions sans expérience d'exploitation doivent être signalées comme des propositions.