OpenClaw-Operator-Scopes

Jeder WebSocket-Client des Gateways verbindet sich mit einer Rolle, operator oder node, und jede Operator-Methode prüft anschließend einen Scope. Die Scope-Seite ist die Karte dieses zweiten Gates: was jeder Scope bedeutet, wie benannte Rollen sie deckeln, wie eine verifizierte Identität sie erhält und warum die Freigabe des Zugriffs einer anderen Person nie mehr gewährt, als Sie selbst besitzen. Sie stellt außerdem ausdrücklich klar, dass nichts davon Mandantenisolation ist.

Rollen und Scope-Stufen

• operator ist die Control-Plane-Rolle für die CLI, die Control UI, Automatisierung und vertrauenswürdige Helfer, node die Rolle des Capability-Hosts für macOS, iOS, Android und Headless-Hosts, die Befehle über node.invoke bereitstellen; Operator-RPC-Methoden erfordern die Rolle operator und von Nodes ausgehende Methoden die Rolle node.
• operator.read deckt Status, Listen, Katalog, Logs, Sitzungs-Lesezugriffe und aufbewahrte Audit-Diagnosen ab; operator.write deckt das Senden von Nachrichten, das Aufrufen von Tools, Talk- und Spracheinstellungen sowie die Weiterleitung von Node-Befehlen ab und erfüllt auch read; operator.admin erfüllt jeden Operator-Scope und ist erforderlich für Konfigurationsänderungen, Updates, native Hooks, reservierte Namespaces und risikoreiche Freigaben.
• operator.pairing verwaltet die Kopplung von Geräten und Nodes, operator.approvals die APIs für Exec- und Plugin-Freigaben, operator.questions die interaktiven Fragen, operator.talk erstellt, steuert und schließt Talk-Sitzungen ohne allgemeinen Schreibzugriff (write erfüllt ihn ebenfalls), und operator.talk.secrets liest die Talk-Konfiguration samt Secrets; unbekannte künftige Scopes erfordern eine exakte Übereinstimmung, sofern der Aufrufer nicht bereits admin besitzt.
• Die Verwaltung persönlicher GitHub-Verbindungen ist die einzige auf die eigene Person beschränkte Ausnahme vom Nur-Lese-Verhalten: Sie benötigt operator.read plus genau das authentifizierte dauerhafte Profil, sodass eine Person nur ihr eigenes Konto verbinden, abfragen oder trennen kann, während systemweite und agentenbezogene GitHub-Änderungen admin erfordern und die Veröffentlichung weiterhin write plus Sitzungs-Autorisierung.

Operator-Scopes begrenzen, was ein Gateway-Client nach der Authentifizierung tun kann.

Benannte Rollen und Identitätsvergaben

Team-Gateways binden authentifizierte dauerhafte Profile an benannte Rollen unter gateway.roles, die jeweils vier geschlossene Richtlinien kombinieren: Zugriff auf die Sitzungen anderer Personen (none, view, suggest oder write), die für Sitzungs-Erstellung und Ausführungen verfügbaren Agenten (eine Liste, ein Stern oder ein leeres Array), eine maximale Scope-Menge und die Frage, ob neue Sitzungen Sandboxing erfordern. users.setRole weist eine Rolle zu und schließt sofort die Verbindungen dieses Profils, gateway.roles.default ist Pflicht, sobald Rollen existieren, und wenn Rollen konfiguriert sind, erhalten per Identität authentifizierte Operatoren keine wiederverwendbaren Geräte- oder Bootstrap-Tokens mehr, weil diese an keine Person gebunden sind. Eine verpflichtende Sandbox ist pro Sitzungs-Ersteller isoliert, reduziert einen Workspace mit Lese- und Schreibzugriff mit einer Warnung auf Nur-Lesen, wird vor der ersten Ausführung unveränderlich mit dem Ersteller gekennzeichnet, wird an delegierte Kinder vererbt, fällt nie auf das Gateway oder einen Node zurück und lässt sich weder durch den Elevated-Modus noch durch Exec-Host-Overrides oder konfigurierte Host-Ziele umgehen. gateway.auth.identityScopes vergibt dann Scopes an verifizierte Identitäten aus Trusted-Proxy-Authentifizierung oder Tailscale WhoIs, wobei E-Mail-Schlüssel ohne Beachtung der Groß- und Kleinschreibung verglichen werden; Verbindungen per Token, Passwort oder ohne Authentifizierung tragen keine Identität und erhalten keine Vergabe, und Node-Verbindungen erhalten nie eine.

Das Methoden-Gate und was danach kommt

• Jede RPC hat einen Methoden-Scope nach dem Prinzip der geringsten Rechte, der vor dem Dispatch abgeleitet wird: agent benötigt write für normale Turns und admin für die Lebenszyklusbefehle new und reset; node.invoke benötigt write für normale Weiterleitung und admin, wenn Browser-Proxy, Verzeichnisauflistung oder Terminal-Upload an einen Node weitergeleitet werden; sessions.create benötigt write für die normale Erstellung und admin für Inkognito-Sitzungen oder jeden execNode; Sitzungs-Dispatch und -Verschiebung leiten ihren Scope vom Ziel ab, write für Geräte und admin für Profile.
• Handler wenden danach strengere Prüfungen auf das konkrete Objekt an: device.pair.approve ist mit pairing erreichbar, doch die Freigabe eines Operator-Geräts kann nur Scopes vergeben oder beibehalten, die der Aufrufer bereits besitzt, node.pair.approve leitet zusätzliche Scopes aus den deklarierten Befehlen des ausstehenden Nodes ab (write für normale Befehle, admin für system.run, Browser-Proxy, Verzeichnisauflistung oder Exec-Freigabe-Befehle), und die Chat-Befehle config set und unset benötigen zusätzlich zu chat send auch admin.
• Die Verbindungsberechtigung wird in dieser Reihenfolge aufgelöst: Der Header x-openclaw-scopes deckelt zuerst Anfragen zur Geräteregistrierung oder zum Upgrade, eine passende serverseitige Identitätsvergabe wird per Vereinigung hinzugefügt, der Header deckelt dann die endgültige Vereinigung (fehlt er, gibt es keine Deckelung, ist er vorhanden, aber leer, gibt es keine Scopes), und eine wirksame benannte Rolle bildet die Schnittmenge des Ergebnisses mit ihrer Obergrenze; das Ergebnis speist sowohl hello.auth.scopes als auch die Methodenautorisierung.

Kopplung in OpenClaw ist der Ort, an dem diese Freigaben abgelegt werden, und Sicherheitskontrollen des OpenClaw-Gateways der umfassendere Satz an Kontrollen, zu dem die Scopes gehören.

Was Scopes nicht sind

Die Seite wiederholt eine Grenze an mehreren Stellen: Scopes sind eine Leitplanke der Control Plane innerhalb einer vertrauenswürdigen Gateway-Operator-Domäne, keine Isolation zwischen feindseligen Mandanten. Benannte Rollen organisieren die Zusammenarbeit innerhalb dieser Domäne; diagnostische Audit-Methoden bleiben Leseoberflächen der gemeinsamen Domäne, die nicht nach Sitzungs-Rolle gefiltert werden; operator.write autorisiert weiterhin gatewayweite Tool-Aufrufe und Node-Weiterleitung; und Authentifizierung per Shared-Secret-Token oder Passwort gilt als vertrauenswürdiger Operator-Zugriff, der auf den OpenAI-kompatiblen Oberflächen, der Route für Tool-Aufrufe und den Endpunkten für den Sitzungs-Verlauf die vollständige Standard-Scope-Menge wiederherstellt, selbst wenn ein Aufrufer engere Scopes deklariert. Für eine starke Trennung zwischen Personen, Teams oder Maschinen lautet die Antwort: separate Gateways unter separaten Betriebssystembenutzern oder Hosts. OpenClaw-Sandboxing erklärt erklärt die Sandbox pro Ersteller, die eine Rolle verlangen kann, und die OpenAI-kompatible HTTP-API von OpenClaw die HTTP-Oberfläche, auf der die Shared-Secret-Regel gilt.

Auf Diali

Auf Diali betreibt jeder Kunde sein eigenes Gateway, also genau die Trennung, die die Dokumentation empfiehlt, wobei die Laufzeitkonfiguration aus dem Dashboard generiert und bei jedem Release ersetzt wird. Gehostetes OpenClaw auf Diali beschreibt den gehosteten Assistenten und Sicherheit bei Diali die Grenze um jede Laufzeitumgebung.

• Write schließt Read und Talk ein; Admin schließt alles ein.
• Eine Freigabe vergibt nie Scopes, die der freigebenden Person fehlen.
• Scopes sind eine Leitplanke, keine Mandantenisolation; getrennte Gateways sind es.