OpenClawのオペレータースコープ

gatewayのWebSocketクライアントはすべて、operatorまたはnodeというロールで接続し、その後、operatorの各メソッドがスコープをチェックします。スコープのページは、この2つ目のゲートの地図です。各スコープの意味、名前付きロールがスコープにどう上限を設けるか、検証済みのアイデンティティがどうスコープを得るか、そして他人のアクセスを承認しても自分が持つ以上の権限が付与されない理由が書かれています。また、これらがいずれもテナント分離ではないことも明記されています。

ロールとスコープのレベル

• operatorは、CLI、コントロールUI、自動化、信頼されたヘルパー向けのコントロールプレーンのロールで、nodeは、node.invokeを通じてコマンドを公開するmacOS、iOS、Android、ヘッドレスホスト向けの機能ホストのロールです。operatorのRPCメソッドにはoperatorロールが、node発のメソッドにはnodeロールが必要です。
• operator.readは、ステータス、一覧、カタログ、ログ、セッションの読み取り、保持された監査診断をカバーします。operator.writeは、メッセージの送信、ツールの呼び出し、talkと音声の設定、nodeへのコマンドの中継をカバーし、readも満たします。operator.adminはすべてのoperatorスコープを満たし、設定の変更、アップデート、ネイティブフック、予約済みの名前空間、高リスクの承認に必要です。
• operator.pairingはデバイスとnodeのペアリングを、operator.approvalsはexec承認とプラグイン承認のAPIを、operator.questionsはインタラクティブな質問を管理します。operator.talkは一般的な書き込み権限なしでTalkセッションを作成、誘導、終了でき（writeでも満たされます）、operator.talk.secretsはシークレットを含むTalkの設定を読み取ります。未知の将来のスコープは、呼び出し元がすでにadminを持っていない限り、完全一致が必要です。
• 個人のGitHub接続の管理は、読み取り専用の動作に対する唯一の自己スコープの例外です。operator.readに加えて、認証済みの永続プロファイルとの完全な一致が必要で、本人は自分のアカウントだけを接続、ポーリング、切断できます。一方、システム全体とエージェントごとのGitHubの変更には引き続きadminが、公開には引き続きwriteとセッションの認可が必要です。

オペレータースコープは、Gatewayクライアントが認証後に何をできるかを制限します。

名前付きロールとアイデンティティへの付与

チーム用のgatewayは、認証済みの永続プロファイルをgateway.roles配下の名前付きロールに結び付けます。各ロールは4つの閉じたポリシーを組み合わせたものです。他人のセッションへのアクセス（none、view、suggest、write）、セッションの作成と実行に使えるエージェント（リスト、アスタリスク、空の配列）、最大スコープセット、そして新しいセッションにサンドボックス化を必須とするかどうかです。users.setRoleはロールを割り当て、そのプロファイルの接続を即座に閉じます。ロールが存在するとgateway.roles.defaultが必須になり、ロールが設定されている場合、アイデンティティ認証されたオペレーターは再利用可能なデバイストークンやブートストラップトークンを受け取らなくなります。それらは人に結び付いていないからです。必須のサンドボックスはセッションの作成者ごとに分離され、読み書き可能なワークスペースを警告付きで読み取り専用に制限し、最初の実行前に作成者が変更不能な形で刻まれ、委任された子にも継承されます。gatewayやnodeにフォールバックすることはなく、elevatedモード、execのホスト上書き、設定済みのホストターゲットでも回避できません。さらにgateway.auth.identityScopesは、trusted-proxy認証またはTailscale WhoIsによる検証済みのアイデンティティにスコープを付与し、メールアドレスのキーは大文字と小文字を区別せずに照合されます。トークン、パスワード、認証なしの接続はアイデンティティを持たないため付与を受けず、node接続も決して受けません。

メソッドゲートとその後に続くもの

• 各RPCには、ディスパッチ前に導出される最小権限のメソッドスコープがあります。agentは通常のターンにはwrite、newやresetのライフサイクルコマンドにはadminが必要です。node.invokeは通常の中継にはwrite、ブラウザプロキシ、ディレクトリ一覧、ターミナルのアップロードをnodeに中継する場合はadminが必要です。sessions.createは通常の作成にはwrite、incognitoセッションやexecNodeの指定にはadminが必要です。セッションのdispatchとmoveは対象からスコープを導出し、デバイスならwrite、プロファイルならadminです。
• その後、ハンドラーが具体的な対象に対してより厳しいチェックを行います。device.pair.approveはpairingで呼び出せますが、operatorデバイスを承認しても、呼び出し元がすでに持つスコープしか発行・維持できません。node.pair.approveは保留中のnodeが宣言したコマンドから追加のスコープを導出し（通常のコマンドにはwrite、system.run、ブラウザプロキシ、ディレクトリ一覧、exec承認のコマンドにはadmin）、configのsetとunsetのチャットコマンドには、チャットの送信に加えてadminが必要です。
• 接続の権限は次の順序で決まります。まずx-openclaw-scopesヘッダーがデバイスの登録やアップグレードのリクエストに上限を設け、一致するサーバー側のアイデンティティ付与が和集合として加えられ、次にヘッダーが最終的な和集合に上限を設けます（ヘッダーがなければ上限なし、あっても空ならスコープなし）。そして有効な名前付きロールが、その結果と自身の上限との積集合をとります。この結果が、hello.auth.scopesとメソッドの認可の両方に使われます。

OpenClawのペアリングはこれらの承認が登録される場所で、OpenClawのgatewayセキュリティ制御はスコープが属する、より広いコントロール群です。

スコープではないもの

このページは、1つの境界を何か所かで繰り返し述べています。スコープは、信頼された1つのgatewayオペレータードメイン内のコントロールプレーンのガードレールであり、敵対的なマルチテナント分離ではありません。名前付きロールはそのドメイン内での共同作業を整理するものです。診断用の監査メソッドは、セッションロールでフィルタリングされない、ドメイン共有の読み取りサーフェスのままです。operator.writeは引き続き、gateway全体でのツール呼び出しとnodeへの中継を認可します。そして共有シークレットのトークン認証やパスワード認証は信頼されたオペレーターのアクセスとして扱われ、呼び出し元がより狭いスコープを宣言していても、OpenAI互換のサーフェス、ツール呼び出しのルート、セッション履歴のエンドポイントでは、デフォルトのスコープセット全体が復元されます。人、チーム、マシンの間を強く分離したいなら、答えは別々のOSユーザーまたはホストで動く別々のgatewayです。OpenClawのサンドボックス化の解説では、ロールが必須にできる作成者ごとのサンドボックスを、OpenClawのOpenAI互換HTTP APIでは、共有シークレットのルールが適用されるHTTPのサーフェスを解説しています。

Dialiでは

Dialiでは、お客様ごとに専用のgatewayが動きます。これはドキュメントが推奨する分離で、ランタイム設定はダッシュボードから生成され、リリースごとに置き換えられます。DialiのマネージドOpenClawホスティングではホスト型アシスタントを、Dialiのセキュリティでは各ランタイムを囲む境界を説明しています。

• writeはreadとtalkを含み、adminはすべてを含みます。
• 承認によって、承認者が持たないスコープが発行されることはありません。
• スコープはガードレールであり、テナント分離ではありません。分離を実現するのは別々のgatewayです。