Configurer les garde-fous

Ce guide montre comment configurer les garde-fous : les règles qui déterminent si l’action d’un agent s’exécute, demande d’abord une approbation ou est refusée.

Les garde-fous couvrent les treize classes d’effet que déclare chaque outil modificateur. Ils sont appliqués côté serveur, au moment où l’outil est appelé, jamais par une instruction dans un prompt.

Définir une décision pour une classe d’action

Allez dans Paramètres → Espace de travail → Autorisations des agents
Choisissez une portée à l’aide du sélecteur segmenté : Espace de travail, Agent (puis choisissez l’agent) ou Espace (puis choisissez l’espace)
Sur la ligne de la classe d’action, choisissez Autoriser, Demander d’abord ou Refuser
Pour retirer une règle que vous avez définie, pressez le bouton de réinitialisation qui apparaît à la fin de cette ligne (Revenir à la valeur héritée) — la décision revient à la portée plus large

Chaque ligne affiche la décision effective sous forme d’étiquette d’état, ainsi qu’un badge indiquant sa provenance : Cette portée, Hérité ou Valeur par défaut. La matrice est résolue au mode Agent (chat), donc Préréglage du mode n’apparaît jamais ici — utilisez la sonde « Et si ? » avec un mode en lecture seule sélectionné pour voir cette couche.

Écrire une règle exige le rôle admin. La lecture de la matrice ne l’exige pas.

Point de contrôle : réglez Pousser vers un dépôt distant sur Refuser à la portée de l’espace de travail, puis lancez la sonde « Et si ? » ci-dessous sur git push origin main. Le résultat indique deny avec la source workspace.

Comprendre comment une décision est résolue

La résolution suit l’ordre spécificité d’abord, puis restrictivité :

Les règles d’espace, puis d’agent, puis d’espace de travail. La première portée dont une règle correspond tranche, et la résolution s’arrête
Si aucune règle ne correspond, le préréglage du mode s’applique — un mode en lecture seule (plan, revue, orchestration) refuse onze des treize classes
Si le mode ne se prononce pas, la valeur par défaut intégrée s’applique

Au sein d’une même portée, une règle de commande est résolue par le préfixe correspondant le plus long, et un conflit de même spécificité est tranché en faveur de la règle la plus restrictive — refuser l’emporte sur demander d’abord, qui l’emporte sur autoriser. Une action qui déclare plusieurs classes résout chacune d’elles indépendamment, puis les combine de la façon la plus restrictive.

Une décision Demander d’abord fait apparaître une seule invite d’approbation couvrant toutes les classes résolues à prompt. Si aucun approbateur n’est connecté, elle est refusée, tant pour les commandes shell que pour les appels d’outils du harnais. C’est délibéré : une exécution sans contrôle est pire qu’une exécution refusée.

Classes d’action et valeurs par défaut intégrées

Classe d’action	Valeur par défaut intégrée
Supprimer un fichier	Demander d’abord
Écrire hors de l’arbre de travail	Autoriser
Créer un commit	Autoriser
Pousser vers un dépôt distant	Demander d’abord
Ouvrir une pull request	Demander d’abord
Publier une revue ou fusionner	Demander d’abord
Écrire dans un outil de suivi externe	Demander d’abord
Accéder au réseau	Autoriser
Lire un secret	Autoriser
Installer un paquet	Autoriser
Exécuter un processus	Autoriser
Modifier la structure de l’espace de travail	Autoriser
Piloter une enceinte (rig)	Autoriser

La taxonomie est fermée. Un nouvel outil livré sans déclarer ses classes échoue à un test de cliquet en CI, de sorte que rien n’arrive avec un ensemble d’effets silencieusement vide.

Tester une règle avec la sonde « Et si ? »

Avant de modifier une règle, vérifiez comment la politique actuelle la résout déjà.

Sur la même page, faites défiler jusqu’à Et si ?
Choisissez une Action (l’une des treize classes)
Remplissez au besoin Commande (par exemple git push origin main), Agent, Espace et Mode
Lisez le résultat : la décision, la raison et la Source :

La sonde exécute le même résolveur que celui qu’emprunte le chemin d’application, contre vos règles actives, de sorte que la réponse est exacte. Si elle vous surprend, modifiez une règle dans la matrice ci-dessus et relancez la sonde.

Régler l’autonomie d’un espace

Le réglage vaut par agent et par espace, et il se combine aux règles plutôt que de les remplacer.

Ouvrez l’espace
Ouvrez Gérer les participants depuis l’en-tête de l’espace
Sous Autonomie, sur la ligne de l’agent, choisissez un niveau :

Niveau	Effet
Par défaut	Aucun réglage d’espace — se comporte comme Agir avec approbation
Proposer uniquement	Tout outil soumis à la barrière est refusé d’emblée, avec un message invitant l’agent à proposer l’action à la place
Agir avec approbation	Les actions risquées passent par la barrière d’approbation fermée par défaut
Agir librement	Préapprouve tout ce qui n’a pas été résolu en un refus catégorique

Le réglage n’atteint que le harnais intégré. L’adaptateur Claude Code exécute ses propres outils en dehors de cette barrière.

Savoir où les garde-fous ne portent pas

Le tableau Où les règles sont appliquées, au bas de la même page, en est la version intégrée à l’application : pour chaque classe d’effet, il indique si chaque exécuteur l’intercepte au contrôle par règle, la laisse au bac à sable ou ne peut pas l’intercepter du tout.

L’adaptateur Claude Code n’est que partiellement soumis au garde-fou pour ses propres appels d’outils. Claude Code est lancé avec --dangerously-skip-permissions, si bien que ses appels de lecture, d’écriture et d’édition ne passent jamais par le garde-fou. Ses commandes bash l’atteignent via un hook qui classe la ligne de commande, et ses push passent par la passerelle de push comme ceux de tout agent. La surface d’outils MCP vers laquelle il rappelle et la commande shell que Control Center lance pour le démarrer sont également soumises au garde-fou.
Le verbe de sortie propre à un mode (submit_plan, propose_orchestration) est épinglé et ne peut jamais être refusé — autrement, un mode serait structurellement incapable de produire son unique livrable.
Que le bac à sable appuie ou non ces règles dépend de l’hôte. Là où cc_server trouve un backend, il enveloppe la CLI Claude Code et l’outil bash du harnais, de sorte qu’une règle que vous n’avez pas écrite repose tout de même sur un socle du système d’exploitation. Sous Windows, il n’y en a aucun, et sous Linux ou WSL2 sans bwrap ni socat, non plus — là, les garde-fous et la surface d’outils du mode constituent toute l’application des règles, et non une deuxième ligne de défense. Vérifiez dans quel cas vous vous trouvez avec Configurer les politiques de bac à sable.