Aller au contenu
Sécurité

Les modes de permission d’OpenClaw

Refus, liste d’autorisation, demande, automatique et plein, ce que chacun résout, et pourquoi automatique est la valeur par défaut recommandée

5 min de lecture

Les modes de permission décident de l’autorité dont dispose un agent avant de lancer des commandes sur l’hôte, d’écrire des fichiers ou de demander plus d’accès à un harnais. La documentation les met dans un seul réglage, le mode d’exécution, avec cinq valeurs, et prend soin de dire qu’il est distinct du réglage qui choisit où une commande s’exécute. Voici ce que résout chaque mode, pourquoi la documentation recommande automatique pour les agents de codage, comment le mode se projette sur les approbations natives de Codex, les permissions distinctes du harnais ACP, et les deux commandes qui montrent ce qui est vraiment en vigueur.

Les cinq modes

  • Refus : bloquer entièrement l’exécution sur l’hôte ; sécurité refus, demande désactivée.
  • Liste d’autorisation : n’exécuter que les commandes autorisées et refuser en silence les absentes.
  • Demande : exécuter les correspondances de la liste et demander à un humain à chaque absence.
  • Automatique : exécuter les correspondances de la liste et faire relire les absences éligibles par un réviseur automatique qui répond autoriser, refuser ou demander ; la valeur par défaut recommandée par la documentation pour les agents de codage qui ont besoin d’un accès utile à l’hôte sans invite à chaque absence.
  • Plein : exécuter sur l’hôte sans les invites de politique ordinaires, pour un hôte de confiance seulement.
Le mode de permission est distinct de tools.exec.host=auto.

Comment automatique relit

Demande et automatique partagent les mêmes réglages de liste et de demande ; automatique ajoute le réviseur natif. Un verdict d’autorisation permet une exécution à risque faible ou moyen, un verdict de refus renvoie une raison pour que l’agent choisisse une alternative plus sûre ou demande, et un verdict de demande, comme un échec de relecture, requiert l’approbation humaine ; sur la passerelle, trois refus consécutifs du réviseur font remonter à un humain. La liaison s’applique toujours : chaque exécutable de segment de commande est lié avant la relecture et revérifié avant le lancement, les enveloppes de shell de connexion ou interactives sautent le réviseur et exigent un humain, et le réglage strict d’évaluation en ligne, désactivé par défaut, fait relire les programmes en ligne reconnus même en mode plein. Une session de passerelle à pleines permissions avec sécurité pleine et demande désactivée saute complètement le chemin d’approbation de l’hôte ; resserrer la demande le rétablit.

Codex et le harnais ACP

  • Pour les sessions Codex natives, automatique conduit aux approbations relues par Guardian : politique d’approbation à la demande, un réviseur automatique et un bac à sable en écriture d’espace de travail, en imposant cette politique sur les combinaisons héritées dangereuses ; refus et liste d’autorisation bloquent entièrement l’exécution locale de Codex, et plein est la posture sans approbation voulue.
  • Les sessions du harnais ACP n’ont pas de terminal pour les invites et utilisent leurs propres réglages : un mode de permission qui approuve les lectures, approuve tout ou refuse tout, et une règle pour les invites non interactives, échouer ou refuser ; approuver tout est l’équivalent bris de glace d’une session sans invite.
  • Les couches ne se relâchent pas l’une l’autre : l’exécution sur l’hôte utilise la plus stricte de la configuration et du fichier d’approbations local à l’hôte, les permissions du harnais ne relâchent pas les approbations de l’hôte, et les approbations de l’hôte ne relâchent pas les invites du harnais.

Les approbations d’exécution d’OpenClaw est la couche de garde-fou que ce mode configure, et Le bac à sable d’OpenClaw expliqué le confinement en dessous.

Voir ce qui est en vigueur

Deux commandes : la commande des approbations imprime la politique demandée, les sources de politique de l’hôte derrière elle et le résultat effectif, et la commande de politique d’exécution montre la vue locale fusionnée ; la documentation dit de lancer les deux quand une commande demande encore ou échoue après un changement de mode. OpenClaw et Claude Code est là où la même idée apparaît côté Claude, avec des hooks et des permissions que la migration garde archivés.

Sur Diali

Sur Diali, l’instance de l’assistant tourne avec les modes réglés pour elle, et un ordinateur à vous rejoint l’ensemble comme nœud avec ses propres approbations ; le passage entre demande et automatique est une décision dans le tableau de bord plutôt qu’une modification de configuration. OpenClaw hébergé sur Diali est l’assistant.

  • Cinq modes, chacun une paire sécurité et demande.
  • Automatique relit les absences ; trois refus font venir un humain.
  • Les couches ne font que resserrer ; deux commandes montrent le résultat.
Commencer

Arrêtez de lire, construisez le vôtre

Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.