Les scopes opérateur d’OpenClaw

Chaque client WebSocket de la passerelle se connecte avec un rôle, operator ou node, et chaque méthode opérateur vérifie ensuite un scope. La page des scopes est la carte de cette seconde porte : ce que chaque scope signifie, comment les rôles nommés les plafonnent, comment une identité vérifiée les obtient, et pourquoi approuver l’accès de quelqu’un d’autre n’accorde jamais plus que ce que vous détenez vous-même. Elle est aussi explicite sur le fait que rien de tout cela n’est une isolation de locataires.

Rôles et niveaux de scope

• operator est le rôle de plan de contrôle pour la CLI, l’interface de contrôle, l’automatisation et les assistants de confiance, node le rôle d’hôte de capacités pour les hôtes macOS, iOS, Android et sans écran qui exposent des commandes via node.invoke ; les méthodes RPC opérateur exigent le rôle operator et les méthodes émises par un nœud le rôle node.
• operator.read couvre le statut, les listes, le catalogue, les journaux, les lectures de session et les diagnostics d’audit conservés ; operator.write couvre l’envoi de messages, l’invocation d’outils, les réglages talk et voix et le relais de commandes de nœud et satisfait aussi read ; operator.admin satisfait chaque scope opérateur et est requis pour la mutation de configuration, les mises à jour, les hooks natifs, les espaces de noms réservés et les approbations à haut risque.
• operator.pairing gère l’appairage des appareils et des nœuds, operator.approvals les API d’approbation exec et plugin, operator.questions les questions interactives, operator.talk crée, pilote et ferme des sessions Talk sans accès en écriture général (write le satisfait aussi) et operator.talk.secrets lit la configuration Talk avec ses secrets ; les futurs scopes inconnus exigent une correspondance exacte sauf si l’appelant détient déjà admin.
• La gestion personnelle de la connexion GitHub est la seule exception auto-limitée au comportement en lecture seule : elle exige operator.read plus le profil durable authentifié exact, une personne ne peut donc connecter, interroger ou déconnecter que son propre compte, tandis que les changements GitHub système et par agent restent admin et que la publication reste write plus l’autorisation de session.

Les scopes opérateur régissent ce qu’un client de la passerelle peut faire après s’être authentifié.

Rôles nommés et attributions par identité

Les passerelles d’équipe lient des profils durables authentifiés à des rôles nommés sous gateway.roles, chacun combinant quatre politiques fermées : l’accès aux sessions des autres (none, view, suggest ou write), les agents disponibles pour la création de sessions et les runs (une liste, une étoile ou un tableau vide), un ensemble maximal de scopes, et si les nouvelles sessions exigent un bac à sable. users.setRole assigne un rôle et ferme immédiatement les connexions de ce profil, gateway.roles.default est requis dès que des rôles existent, et quand des rôles sont configurés les opérateurs authentifiés par identité ne reçoivent plus de jetons d’appareil ou d’amorçage réutilisables, parce que ceux-ci ne sont pas liés à une personne. Un bac à sable requis est isolé par créateur de session, réduit un espace de travail en lecture-écriture à la lecture seule avec un avertissement, est estampillé de façon immuable avec le créateur avant le premier run, est hérité par les enfants délégués, ne se rabat jamais sur la passerelle ou un nœud, et ne peut être contourné ni par le mode élevé, ni par les surcharges d’hôte exec, ni par les cibles d’hôte configurées. gateway.auth.identityScopes accorde ensuite des scopes aux identités vérifiées venant de l’authentification par proxy de confiance ou du WhoIs Tailscale, les clés email correspondant sans tenir compte de la casse ; les connexions par jeton, mot de passe et sans authentification ne portent aucune identité et ne reçoivent aucune attribution, et les connexions de nœud jamais.

La porte de méthode et ce qui la suit

• Chaque RPC a un scope de méthode au moindre privilège dérivé avant le dispatch : agent exige write pour les tours ordinaires et admin pour les commandes de cycle de vie new ou reset ; node.invoke exige write pour un relais ordinaire et admin pour relayer vers un nœud le proxy de navigateur, le listage de répertoire ou l’envoi de terminal ; sessions.create exige write pour une création ordinaire et admin pour les sessions incognito ou tout execNode ; le dispatch et le déplacement de session dérivent leur scope de la cible, write pour les appareils et admin pour les profils.
• Les gestionnaires appliquent ensuite des vérifications plus strictes sur la chose concrète : device.pair.approve est accessible avec pairing mais approuver un appareil opérateur ne peut frapper ou conserver que des scopes que l’appelant détient déjà, node.pair.approve dérive des scopes supplémentaires des commandes déclarées par le nœud en attente (write pour les commandes ordinaires, admin pour system.run, le proxy de navigateur, le listage de répertoire ou les commandes d’approbation exec), et les commandes de chat config set et unset exigent admin en plus de l’envoi de chat.
• L’autorité de connexion se résout dans l’ordre : l’en-tête x-openclaw-scopes plafonne d’abord les demandes d’enrôlement ou de montée d’appareil, une attribution par identité côté serveur correspondante est unie, l’en-tête plafonne ensuite l’union finale (absent signifie aucun plafond, présent mais vide signifie aucun scope), et un rôle nommé effectif intersecte le résultat avec son plafond ; le résultat alimente à la fois hello.auth.scopes et l’autorisation des méthodes.

L’appairage OpenClaw est l’endroit où ces approbations sont déposées et Les contrôles de sécurité de la passerelle OpenClaw l’ensemble de contrôles plus large auquel les scopes appartiennent.

Ce que les scopes ne sont pas

La page répète une frontière à plusieurs endroits : les scopes sont un garde-fou de plan de contrôle à l’intérieur d’un seul domaine opérateur de passerelle de confiance, pas une isolation multi-locataire hostile. Les rôles nommés organisent la collaboration dans ce domaine ; les méthodes d’audit de diagnostic restent des surfaces de lecture partagées non filtrées par le rôle de session ; operator.write autorise toujours l’invocation d’outils et le relais de nœud à l’échelle de la passerelle ; et l’authentification par jeton ou mot de passe partagé est traitée comme un accès opérateur de confiance qui restaure l’ensemble complet de scopes par défaut sur les surfaces compatibles OpenAI, la route d’invocation d’outils et les points de terminaison d’historique de session même quand un appelant déclare des scopes plus étroits. Pour une séparation forte entre personnes, équipes ou machines, la réponse est des passerelles séparées sous des utilisateurs système ou des hôtes séparés. Le bac à sable OpenClaw expliqué explique le bac à sable par créateur qu’un rôle peut exiger et L’API HTTP compatible OpenAI d’OpenClaw la surface HTTP où la règle du secret partagé s’applique.

Sur Diali

Sur Diali chaque client fait tourner sa propre passerelle, ce qui est la séparation que la documentation recommande, avec la configuration d’exécution générée depuis le tableau de bord et remplacée à chaque version. OpenClaw hébergé sur Diali décrit l’assistant hébergé et La sécurité Diali la frontière autour de chaque runtime.

• Write implique read et talk ; admin implique tout.
• Une approbation ne frappe jamais des scopes que l’approbateur n’a pas.
• Les scopes sont un garde-fou, pas une isolation de locataires ; les passerelles séparées le sont.