La plupart des systèmes de permissions pour les agents de code reposent sur des listes d'autorisation : lecture de fichiers oui, écriture de fichiers oui, exécution des tests oui, et demander pour tout le reste. Cela fonctionne jusqu'à ce que quelqu'un attribue une « confiance totale » à un agent pour ne plus voir de prompts, et que l'agent lance un git push --force un vendredi après-midi.
Notre position est claire : quatre catégories d'actions doivent s'interrompre pour solliciter un humain à chaque fois, quel que soit le niveau de confiance accordé à l'agent ou au demandeur. Les niveaux de confiance déterminent combien d'autres opérations nécessitent une approbation. Ces quatre-là ne s'exécutent jamais en silence.
Les quatre
1. Pousser vers une branche partagée. Un commit sur une branche de fonctionnalité est une suggestion. Un push sur main ou release est une décision dont toute l'équipe hérite, souvent assortie d'un déploiement automatique. Poser la question ne coûte rien, mais revenir en arrière coûte très cher.
2. Supprimer. Des fichiers, des branches, des tables, des buckets, des ressources. La suppression est la seule opération où une mauvaise interprétation d'intention ne peut être rattrapée au deuxième essai. Les agents sont sûrs d'eux, et c'est avec une suppression menée avec assurance qu'on teste la validité des sauvegardes.
3. Dépenser de l'argent. Appeler une API payante, provisionner une ressource, acheter un domaine, envoyer une campagne. La personne à l'origine de la demande ne sait pas forcément que la requête a un coût. La personne qui paie doit le savoir.
4. Toucher aux identifiants. Lire un fichier de clés, exporter des variables d'environnement, se connecter à un service, valider une authentification à deux facteurs. Tout ce qui touche à cela relève de l'identité, et l'identité appartient au propriétaire de la machine, pas à quiconque se trouve dans la salle.
Pourquoi même une « confiance totale » doit marquer une pause ici
Un mode de permission définit la relation d'une personne avec l'agent : lecture seule, modification sans push, confiance totale. C'est la bonne granularité pour les centaines d'appels ordinaires qu'un agent effectue au cours d'une session. En revanche, c'est une mauvaise granularité pour les quatre actions ci-dessus, car elles sont rares, irréversibles ou coûteuses, et parce que leur coût pèse sur quelqu'un d'autre que le demandeur.
La règle dans muti est donc simple : aucun modèle de permissions ne peut autoriser ces quatre actions à s'exécuter silencieusement. Même en mode « confiance totale », elles marquent une pause et sont mises en évidence dans la timeline. Le prompt reste suffisamment rare pour ne pas devenir pénible, et les catégories sont assez précises pour que la réponse soit généralement évidente.
Comment cela s'articule avec les modes de permissions de Claude Code
Claude Code dispose déjà d'une échelle : plan (lecture seule), default (demander avant les modifications et les commandes), acceptEdits (les modifications s'exécutent, les commandes demandent validation) et bypassPermissions (aucune confirmation demandée). Ces modes décrivent à quel point l'agent vous sollicite. Les quatre actions décrivent ce qui doit solliciter le propriétaire quand quelqu'un d'autre fait la demande. Elles se superposent.
La dernière colonne correspond à l'apport de la salle et reste identique à chaque ligne. Voir les modes de permissions expliqués.
À qui poser la question
C'est la partie que la plupart des conceptions négligent. Quand un agent partagé a besoin d'un humain, de quel humain s'agit-il ?
- Les identifiants vont au propriétaire. Les connexions, les codes d'authentification à deux facteurs et l'accès aux clés relèvent de l'identité du propriétaire. Ils sont transmis au propriétaire, peu importe qui a lancé la tâche. Le demandeur voit qu'une prise de contrôle a eu lieu, mais ne voit pas le secret.
- Les questions d'intention vont au demandeur. « Voulez-vous parler de la base de données de staging ? » concerne ce que la personne souhaitait faire. La question est routée vers l'auteur de la demande.
- Tous deux voient la même timeline. Aucun n'a besoin de transmettre le contexte à l'autre ; la question et sa réponse figurent dans le même fil que le travail en cours.
Les invites liées aux identifiants et aux actions dangereuses sont transmises au propriétaire ; les questions d'intention sont transmises au demandeur ; tous deux voient l'échange.
Anatomie d'une bonne carte d'approbation
Une approbation sur laquelle on peut statuer en cinq secondes comporte cinq éléments.
Prévoyez trois boutons : approuver, rejeter et poursuivre en lecture seule. Le troisième est sous-estimé : il permet au travail de continuer pendant que l'étape risquée attend sa décision.
Permettez de répondre aux approbations là où se trouve déjà le propriétaire : dans la console, sur mobile ou via une carte sur une messagerie. Trancher à un endroit doit s'appliquer partout. Définissez une expiration pour qu'une carte oubliée ne s'exécute pas une semaine plus tard.
La fatigue des approbations est le véritable ennemi
Chaque prompt conditionne la personne qui le reçoit. S'il y en a trop, elle finira par trouver le réglage qui les coupe tous. Trois principes permettent de maintenir un volume faible sans assouplir les quatre règles.
- Délimitez le périmètre de l'agent. Un seul répertoire de travail par agent signifie moins de fichiers qu'il pourrait toucher, et donc moins d'invites pour confirmer l'accès.
- Utilisez les modes habituels pour les opérations courantes. La lecture seule pour explorer, la modification sans push pour l'essentiel du travail. Réservez la « confiance totale » aux personnes à qui vous laisseriez directement votre clavier.
- Proposez des modèles par défaut fidèles à la réalité. Fournissez la lecture seule, la modification sans push et la confiance totale sous forme de présélections explicites, afin que personne n'ait à élaborer une stratégie à partir de zéro avec le risque de se tromper.
La ligne d'audit
Chaque requête et chaque approbation devrait générer une ligne exportable pour le propriétaire : qui a demandé, qui a tranché, quand, quelle règle, ce qui s'est passé, ce qui a été consommé. Non pas parce qu'on la lira tous les jours, mais parce que le jour où un incident survient, il est déjà trop tard pour commencer à consigner.
Foire aux questions
Poser la question à chaque fois ne ralentit-il pas l'agent ? Uniquement pour ces quatre catégories, qui restent rares au cours d'une session normale. Le coût de la pause se compte en secondes ; celui d'une erreur se chiffre en heures ou en argent.
Qu'en est-il du propriétaire qui utilise son propre agent ? Le propriétaire n'est pas soumis aux modes de permission sur son propre agent, mais les quatre actions sont tout de même consignées dans la timeline afin que l'historique reste complet.
Un demandeur peut-il approuver sa propre action ? Non. L'approbation appartient au propriétaire de la machine. Le demandeur peut annuler, réessayer ou apporter des précisions contextuelles.
Dans muti, les salles sont livrées avec ces règles actives par défaut, sans possibilité de les désactiver. Si ce fonctionnement par défaut vous paraît pertinent, créez une salle pour votre agent.
Publié le · Mis à jour le