Configurer les garde-fous

Ce guide explique 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 qui modifie l’état. Ils sont appliqués côté serveur, au moment où l’outil est appelé, et jamais par une instruction dans un prompt.

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

Ouvrez Paramètres → Espace de travail → Autorisations des agents
Choisissez une portée avec le contrôle segmenté : Espace de travail, Agent (puis sélectionnez l’agent), ou Espace (puis sélectionnez l’espace)
Sur la ligne de la classe d’action, choisissez Autoriser, Demander d’abord ou Refuser
Pour supprimer une règle que vous avez définie, appuyez sur le bouton de réinitialisation qui apparaît à la fin de cette ligne (Revenir à la valeur héritée) — la décision retombe sur la portée plus large

Chaque ligne affiche la décision effective sous forme d’étiquette de statut, ainsi qu’un badge indiquant d’où elle vient : Cette portée, Hérité ou Valeur par défaut. La matrice est résolue au niveau du 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.

L’écriture d’une règle exige le rôle admin. La lecture de la matrice, non.

Point de contrôle : définissez Pousser vers un dépôt distant sur Refuser au niveau de la portée 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 applique d’abord la spécificité, puis la restrictivité :

Les règles d’Espace, puis d’Agent, puis d’Espace de travail. La première portée comportant une règle correspondante décide, 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 n’a rien à dire, la Valeur par défaut s’applique

Au sein d’une même portée, une règle de commande se résout par le préfixe correspondant le plus long, et un conflit de même spécificité se résout au plus restrictif — refuser l’emporte sur demander d’abord, qui l’emporte sur autoriser. Une action qui déclare plusieurs classes résout chacune indépendamment, puis les combine selon le plus restrictif.

Une décision Demander d’abord fait apparaître une seule demande d’approbation couvrant toutes les classes résolues en prompt. Sans approbateur connecté, elle est refusée, pour les commandes shell comme pour les appels d’outils du harnais. C’est délibéré : une exécution sans garde-fou est pire qu’une exécution refusée.

Classes d’action et valeurs par défaut

Classe d’action	Valeur par défaut
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)
Renseignez éventuellement Commande (par exemple git push origin main), Agent, Espace et Mode
Lisez le résultat : la décision, la raison et Source :

La sonde exécute le même résolveur que le chemin d’application, sur vos règles actives, si bien 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 le cadran d’autonomie d’un espace

Le cadran s’applique par agent et par espace, et il se combine avec les 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	Chaque outil soumis à un garde-fou est refusé d’emblée, avec un message invitant l’agent à proposer l’action à la place
Agir avec approbation	Les actions risquées butent sur la barrière d’approbation à refus par défaut
Agir librement	Pré-approuve tout ce qui n’a pas été résolu en refus catégorique

Le cadran 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, en bas de la même page, en est la version dans l’application : pour chaque classe d’effet, il indique si chaque exécuteur l’intercepte au niveau du 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é — sinon un mode serait structurellement incapable de produire son unique livrable.
Que le bac à sable étaye 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 OS. Sous Windows, il n’y en a aucun, et sous Linux ou WSL2 sans bwrap et socat, il n’y en a pas non plus — là, les garde-fous et la surface d’outils du mode constituent toute l’application, et non une seconde ligne de défense. Vérifiez dans quel cas vous vous trouvez avec Configurer les politiques de bac à sable.