Pour être aussi productifs que possible en codage comme dans d’autres tâches, les agents ont besoin d’un niveau d’autonomie équilibré. Cela signifie qu’ils doivent pouvoir agir de manière indépendante, faire preuve de créativité et accomplir leur travail sans devoir trop souvent demander une autorisation.

Cependant, une plus grande autonomie introduit des risques de sécurité si les agents entreprennent des actions non voulues. C’est particulièrement vrai pour les agents locaux, qui s’exécutent souvent au contact de fichiers, d’identifiants, de variables d’environnement, d’outils MCP, et qui ont accès à des systèmes de production.

La réponse la plus simple consiste à demander l’avis de l’utilisateur avant chaque action, mais solliciter une autorisation trop souvent crée un autre problème de sécurité. Après un certain nombre de requêtes répétées, les gens cessent de lire attentivement, et le processus d’approbation perd de son sens.

Cette semaine, nous avons lancé la revue automatique, qui fait que les décisions autour de l’autonomie des agents s’apparentent davantage à un curseur qu’à un interrupteur. L’idée centrale est qu’un agent doit pouvoir agir librement lorsque les enjeux sont faibles, mais ralentir lorsque son action suivante franchit un seuil important.

Nous déterminons où se situe une action sur ce continuum grâce à un agent classificateur spécialisé qui examine les actions dans leur contexte avant leur exécution. Le développer nous a amenés à transformer notre intuition sur la manière dont l’autonomie des agents devrait être encadrée en un modèle opérationnel des conséquences, de l’intention et du retour, que nous avons pu tester face au comportement réel des agents.

#Évaluer le risque en contexte

Le fait qu'une action de l'agent présente un risque dépend de la situation. La même commande peut être sans danger dans un workflow et inacceptable dans un autre. Ce qui compte, c'est la relation entre l'action, la demande de l'utilisateur et les conséquences d'une erreur.

Ce constat nous a poussés à développer un agent « classificateur » chargé de piloter l'autonomie globale de l'agent. Nous voulions qu'il s'agisse d'un petit modèle, afin qu'il reste rapide et peu coûteux à exécuter, tout en étant capable d'évaluer avec nuance si l'action suivante correspondait à l'intention de l'utilisateur.

La règle centrale que nous avons donnée au classificateur était qu'il devait être plus permissif lorsque les enjeux de sécurité étaient plus faibles, et plus prudent lorsqu'ils étaient plus élevés. Une fois ce principe général posé, nous avons commencé à créer le classificateur comme un évaluateur contextuel rapide, capable de s'intégrer directement dans la chaîne d'exécution de l'agent.

#Conception du classificateur

La première décision technique a porté sur le choix du modèle. Le classificateur intervient avant l’exécution d’un appel d’outil. Il se trouve donc directement dans la boucle de l’agent et doit être à la fois rapide et précis. Le fait de travailler avec plusieurs modèles nous a aidés ici, car nous avons pu essayer un large éventail de modèles et de modes de raisonnement, puis choisir celui qui offrait le bon équilibre entre vitesse et qualité de jugement.

L’une des premières surprises a été de constater que les modèles avec moins de raisonnement n’étaient pas toujours plus rapides. Lorsqu’un modèle avait du mal à comprendre la politique ou l’appel d’outil, il pouvait passer plus de temps et consommer plus de tokens à chercher, pour finalement produire une réponse de moins bonne qualité. Le meilleur compromis était un petit modèle avec suffisamment de raisonnement pour trancher clairement.

Nous avons également rendu le classificateur agentique, car certaines actions ne peuvent pas être évaluées à partir de la seule commande. Une commande comme python script.py peut être sans risque ou risquée selon le contenu du fichier ; le classificateur peut donc inspecter l’espace de travail avec des outils comme ReadFile, Grep, Glob et ListDir avant de décider.

Nous avons évité de créer un endpoint de classification distinct, car un aller-retour supplémentaire ajouterait de la latence juste avant chaque appel d’outil examiné. À la place, le classificateur s’exécute dans le même flux RPC que l’agent parent, avec une architecture similaire à celle des sous-agents.

#Concevoir la boucle de rétroaction

La décision suivante concernait le rôle d’un blocage. Nous ne voulions pas que le classificateur devienne un simple générateur de demandes d’approbation supplémentaires. Lorsqu’il bloque une action, il renvoie une explication à l’agent parent, et l’agent parent peut souvent s’appuyer sur ce retour pour choisir une voie plus sûre sans interrompre l’utilisateur.

L’intention de l’utilisateur est ce qui rend ce retour utile. La question n’est pas de savoir si une action semble risquée en soi. La question est de savoir si l’action est justifiée par ce que l’utilisateur a demandé à l’agent de faire. C’est ce qui permet au travail de développement courant de se poursuivre, tandis que les actions aux conséquences plus importantes exigent un signal plus explicite de l’utilisateur.

Cette conception ne fonctionne que si le classificateur est ajusté en fonction des actions qu’il doit laisser passer et de celles qu’il doit bloquer. Nous avions donc besoin d’evals couvrant les deux cas.

#Tester le classificateur

Notre premier ensemble d’evals provenait de données d’utilisation internes, afin de comprendre le profil habituel du travail de l’agent. Le classificateur devait détecter les actions risquées sans bloquer le travail de développement courant, et les sessions internes étaient le meilleur moyen d’établir cette référence. Nous avons commencé avec environ 12 heures de sessions internes de développeurs, puis nous avons réduit cet ensemble et dédupliqué les actions courantes pour obtenir 6 122 lignes étiquetées.

Nous avions aussi besoin de données synthétiques, car les pires cas n’apparaissent pas assez souvent dans une utilisation normale. Nous avons généré des cas dans lesquels l’agent pouvait lire des secrets, toucher à des données de production, suivre des instructions non fiables ou entreprendre des actions avec des effets de bord importants. Ces exemples nous ont permis de couvrir les échecs que nous voulions le plus que le classificateur détecte.

La politique a évolué à mesure que nous apprenions, ce qui a rendu le travail sur les données plus compliqué. Quand nous avons modifié les catégories de comportement que le classificateur devait reconnaître, nous avons dû réétiqueter ou reconstituer l’ensemble d’evals. Sinon, nous aurions testé le classificateur actuel sur la base d’une compréhension obsolète du problème.

Nous avons fait passer les evals par la même boucle backend du classificateur que celle utilisée en production. Cela nous a permis de tester toute la chaîne, y compris l’utilisation des outils, la classification finale, les dérogations du modèle et les échecs d’analyse. Les evals vérifiaient la décision finale d’autoriser ou de bloquer, ainsi que le contexte utilisé par le classificateur lorsqu’il devait inspecter l’espace de travail avant de décider.

Nous avons aussi recherché les cas d’instabilité. Si le même cas était autorisé six fois et bloqué quatre fois, cela signifiait généralement que la politique ou le prompt n’était pas assez précis. Des exécutions répétées nous ont permis de trouver ces cas instables et d’affiner le classificateur jusqu’à rendre son comportement plus cohérent.

#Limiter les blocages purs et simples

En pratique, seule une petite partie des actions des agents doit être examinée par le classificateur. De nombreuses commandes sont déjà couvertes par des listes d’autorisation ou par le sandboxing, si bien que le classificateur s’exécute surtout lorsque l’action nécessite une évaluation contextuelle.

Lorsque le classificateur s’exécute, il bloque actuellement environ 4 % des actions, même si un blocage ne se traduit pas immédiatement par une sollicitation de l’utilisateur. Le classificateur renvoie une explication à l’agent parent, qui peut souvent restreindre l’action, choisir un autre outil ou éviter complètement l’étape risquée.

Certains blocages du classificateur deviennent des interruptions pour l’utilisateur, mais globalement, nous constatons que seulement environ 7 % de l’ensemble des chats en mode revue automatique entraînent au moins une interruption. À titre de comparaison, certains clients Enterprise avec lesquels nous travaillons voyaient auparavant environ 40 % des actions bloquées au sein de leur organisation.

Ces premières données correspondent bien au comportement produit que nous recherchions. Le classificateur interrompt rarement l’utilisateur directement et, dans la plupart des cas bloqués, l’agent parent peut utiliser ce retour pour poursuivre de manière plus sûre et plus ciblée.

#Affiner l'autonomie des agents

La revue automatique en est encore à ses débuts, et notre compréhension du continuum de l’autonomie continuera d’évoluer à mesure que les agents gagneront en capacités. Aujourd’hui, elle se concentre sur les agents locaux dans l’application de bureau, et nous nous attendons à ce que les mêmes principes façonnent, au fil du temps, la manière dont nous encadrons l’autonomie des agents dans davantage de contextes.

Nous voulons que les agents disposent d’une véritable autonomie, tout en faisant dépendre la décision de les ralentir du contexte plutôt que d’un paramètre global d’autorisation unique. Le classificateur nous permet de renforcer les garde-fous sans faire de l’autonomie une succession de demandes d’approbation. Il repère les actions qui nécessitent un examen plus attentif, fournit un retour à l’agent parent et permet à l’agent de continuer à travailler lorsqu’il existe un moyen plus sûr de procéder.

La revue automatique est désormais activée par défaut pour les nouveaux utilisateurs. Pour les utilisateurs existants, vous pouvez l’activer dans Paramètres > Agents.