Sortir du bac à sable en connaissance de cause
Ce que le mode élevé d’OpenClaw change vraiment, en quoi les quatre directives diffèrent, et pourquoi la porte globale, la porte par agent et la liste d’autorisation doivent toutes céder avant la moindre commande
Mettre un agent en bac à sable se décide vite et se vit moins bien, car dès qu’une tâche légitime réclame quelque chose hors de la boîte, il faut une manière délibérée de l’en faire sortir. Le mode élevé est la réponse d’OpenClaw. Il ne change rien pour un agent qui n’a jamais été cloisonné, et pour celui qui l’est, il ouvre un chemin étroit et contrôlé vers l’hôte. Les portes méritent une lecture attentive, car plusieurs doivent s’aligner avant qu’une seule commande ne bouge.
Ce que change l’élévation
- Le mode élevé permet à un agent cloisonné de sortir du bac à sable configuré au niveau de l’agent et d’exécuter les commandes en dehors, avec des portes d’approbation qui restent configurables.
- Il ne change le comportement que lorsque l’agent est en bac à sable, puisqu’un agent non cloisonné exécute déjà ses commandes shell sur l’hôte.
- L’hôte effectif est la passerelle par défaut, et ne devient le nœud que si la cible d’exécution configurée ou de session est déjà un nœud, si bien que l’élévation n’est pas un contournement entre hôtes.
- Quatre directives sont disponibles par session, avec un niveau actif qui conserve les approbations, un niveau ask qui en est l’alias, un niveau complet qui peut sauter les approbations, et un niveau inactif qui revient à l’exécution confinée.
Les sessions dont le rôle du créateur impose le bac à sable ne peuvent pas utiliser le mode élevé pour s’en échapper.
Les portes qui doivent s’aligner
La disponibilité est une conjonction, pas un interrupteur. La porte globale doit être ouverte, et l’expéditeur doit figurer sur la liste d’autorisation de son canal, tenue sous forme de listes d’identifiants par canal. Une porte par agent ne peut que restreindre davantage, donc la porte globale et la porte par agent doivent toutes deux être ouvertes pour qu’un agent soit éligible. La liste d’autorisation par agent fonctionne de la même façon, et un expéditeur doit figurer à la fois sur la liste globale et sur celle de l’agent. Les greffons de canal peuvent fournir une liste de repli via un point d’extension du SDK, mais aucun canal fourni d’origine ne l’implémente aujourd’hui, si bien qu’en pratique chaque fournisseur a besoin de sa propre entrée explicite. Si une seule porte échoue, le mode élevé est traité comme indisponible plutôt que partiellement accordé. Les entrées elles-mêmes peuvent être de simples identifiants, qui correspondent à un identifiant d’expéditeur, à un numéro au format E.164 ou à un champ d’origine, ou porter un préfixe visant un nom affiché, un nom d’utilisateur ou une étiquette, avec des préfixes d’identité explicites quand il faut lever toute ambiguïté. Il existe enfin une dépendance plus discrète, car la commande bash de discussion possède son propre drapeau et exige en plus que le mode élevé soit activé, de sorte que le désactiver verrouille aussi ces messages shell.
Niveaux et priorité
- Un message contenant uniquement la directive fixe la valeur par défaut de la session, tandis que la même directive placée en tête d’une demande ne vaut que pour ce message.
- La résolution passe d’abord par la directive en ligne, puis par la valeur de session, puis par la valeur globale définie en configuration.
- En mode complet, les approbations ne sont sautées que si la politique d’approbation résolue pour le mode et l’hôte est déjà entièrement permissive, et aux niveaux actif et ask les règles configurées s’appliquent toujours.
Le mode élevé suppose que vous avez déjà un Le bac à sable de la passerelle dont il vaille la peine de sortir, et que vous avez décidé ce qu’une commande a le droit de faire une fois arrivée, ce qui relève de Les approbations exec. L’élévation ne remplace ni l’un ni l’autre.
Pourquoi les limites tiennent
La conception traite l’élévation comme un levier sur un seul axe et refuse d’en faire un contournement général. Si la politique d’outils refuse L’outil exec purement et simplement, l’élévation ne peut pas le rétablir, car les deux répondent à des questions différentes et la plus restrictive l’emporte. Si le rôle d’opérateur du créateur de session authentifié imposait un bac à sable, l’élévation ne peut exécuter aucune commande sur la passerelle ni sur un nœud, ce qui place une décision d’exploitation au-dessus d’une directive de discussion. La sélection d’hôte est traitée pareillement, donc une cible automatique ne devient pas un libre choix de machine. Garder ces portes séparées rend la composition prévisible, et la documentation consacre une page à la manière dont les trois interagissent au moment d’un appel d’outil, à lire une fois en entier (Comment les trois portes se composent). La directive exec est encore un autre levier, qui ajuste les réglages d’exécution par session pour les expéditeurs autorisés sans exiger la moindre élévation. Au total, activer l’élévation élargit exactement une chose et laisse toutes les autres frontières en place.
Sur Diali
Sur Diali, chaque client dispose de son propre assistant, et la configuration d’exécution de OpenClaw hébergé sur Diali est générée depuis le tableau de bord puis remplacée à chaque version. Si vous voulez situer les frontières avant d’en élargir une, commencez par notre page La sécurité Diali.
- Le mode élevé ne change rien tant que l’agent n’est pas en bac à sable.
- Toutes les portes doivent céder : globale, par agent et liste d’expéditeurs.
- Seul le niveau complet saute les approbations, si la politique le permet.
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.
