Gateway

オペレーターのスコープ

オペレータースコープは、Gateway クライアントが認証後に実行できる操作を制限します。これは、1 つの信頼された Gateway オペレータードメイン内におけるコントロールプレーンのガードレールであり、敵対的なマルチテナント分離ではありません。人、チーム、またはマシンを強固に分離するには、別々の OS ユーザーまたはホストで個別の Gateway を実行してください。

ロール

すべての Gateway WebSocket クライアントは、次のいずれかのロールで接続します。

operator：CLI、Control UI、自動化、および信頼されたヘルパープロセスなどのコントロールプレーンクライアント。
node：node.invoke を通じてコマンドを公開するケイパビリティホスト（macOS、iOS、Android、ヘッドレス）。

オペレーター RPC メソッドには operator ロールが必要です。Node から発信されるメソッドには node ロールが必要です。

スコープレベル

スコープ	意味
`operator.read`	読み取り専用のステータス、一覧、カタログ、ログ、セッションの読み取り、およびその他の非変更呼び出し。
`operator.write`	変更を伴うオペレーター操作：メッセージの送信、ツールの呼び出し、トーク／音声設定の更新、Node コマンドの中継。`operator.read` も満たします。
`operator.admin`	管理アクセス。すべての `operator.*` スコープを満たします。設定の変更、更新、ネイティブフック、予約済み名前空間、および高リスクの承認に必要です。
`operator.pairing`	デバイスおよび Node のペアリング管理：一覧表示、承認、拒否、削除、ローテーション、失効。
`operator.approvals`	Exec および Plugin の承認 API。
`operator.talk.secrets`	シークレットを含む Talk 設定の読み取り。

未知の将来の operator.* スコープでは、呼び出し元がすでに operator.admin を保持している場合を除き、完全一致が必要です。

メソッドスコープは最初のゲートにすぎません

各 Gateway RPC には最小権限のメソッドスコープがあり、リクエストがハンドラーに到達できるかどうかを決定します。一部のハンドラーはその後、承認または変更される具体的な対象に基づいて、より厳格なチェックを適用します。

device.pair.approve には operator.pairing で到達できますが、オペレーターデバイスを承認する場合、呼び出し元がすでに保持しているスコープのみを発行または維持できます。
node.pair.approve には operator.pairing で到達でき、その後、保留中の Node が宣言したコマンド一覧から追加の承認スコープを導出します。
chat.send は書き込みスコープのメソッドですが、/config set および /config unset チャットコマンドには、それに加えて operator.admin が必要です。これは、呼び出し元のチャット送信スコープに関係なく適用されます。

これにより、低いスコープのオペレーターは、すべてのペアリング承認を管理者専用にすることなく、低リスクのペアリング操作を実行できます。

デバイスペアリングの承認

デバイスペアリングレコードは、承認済みのロールとスコープを保持する永続的な情報源です。すでにペアリング済みのデバイスに、より広いアクセス権が暗黙的に付与されることはありません。より広いロールまたはスコープを要求して再接続すると、新しい保留中のアップグレードリクエストが作成されます。

デバイスリクエストの承認：

オペレーターロールを含まないリクエストには、オペレータースコープの承認は不要です。
オペレーター以外のデバイスロール（例：node）のリクエストには operator.admin が必要です。これは、device.pair.approve 自体には operator.pairing のみが必要である場合でも同様です。
operator.read、operator.write、operator.approvals、 operator.pairing、または operator.talk.secrets のリクエストでは、呼び出し元がそのスコープ、または operator.admin をすでに保持している必要があります。
operator.admin のリクエストには operator.admin が必要です。
明示的なスコープを含まない修復リクエストは、既存のオペレータートークンのスコープを継承できます。そのトークンが管理者スコープの場合も、承認には operator.admin が必要です。

管理者ではない共有シークレットセッションと信頼済みプロキシセッションは、自身が宣言したオペレータースコープの範囲内でのみ、オペレーターデバイスのリクエストを承認できます。これらのセッションが通常は operator.pairing を使用できる場合でも、オペレーター以外のロールの承認は管理者専用です。

ペアリング済みデバイスのトークンセッションでは、呼び出し元が operator.admin を保持していない限り、管理対象は自身のものに限定されます。管理者ではない呼び出し元に表示されるのは自身のペアリングエントリのみであり、承認、拒否、ローテーション、失効、削除を行えるのも自身のデバイスエントリのみです。

Node ペアリングの承認

従来の node.pair.* メソッドは、Gateway が所有する別個の Node ペアリングストアを使用します。 WS Node は代わりにデバイスペアリング（role: node）を使用しますが、承認に関する用語は同じです。2 つのストアの関係については、Gateway ペアリングを参照してください。

node.pair.approve は、保留中のリクエストのコマンド一覧から追加の必須スコープを導出します。

宣言されたコマンド	必須スコープ
なし	`operator.pairing`
通常の Node コマンド	`operator.pairing` + `operator.write`
`system.run`、`system.run.prepare`、`system.which`、`browser.proxy`、`fs.listDir`、または `system.execApprovals.get/set`	`operator.pairing` + `operator.admin`

Node の宣言を承認しても、別個のランタイム許可リストゲートを持つコマンドは有効になりません。たとえば、computer.act を宣言する Node の承認にはペアリングスコープと書き込みスコープが必要ですが、これはそのサーフェスを記録するだけです。管理者または所有者は、引き続き computer.act を有効にする必要があります。有効になっている間は、書き込みスコープの node.invoke メソッドを通じてこれを呼び出しても、各操作に管理者スコープは必要ありません。

Node ペアリングは ID と信頼を確立しますが、Node 自身の system.run Exec 承認ポリシーに代わるものではありません。

共有シークレット認証

共有 Gateway トークン／パスワード認証は、その Gateway に対する信頼済みオペレーターアクセスとして扱われます。OpenAI 互換の HTTP サーフェス、/tools/invoke、および HTTP セッション履歴エンドポイントは、呼び出し元がより狭いスコープを宣言して送信した場合でも、共有シークレットの Bearer 認証に対して、オペレーターのデフォルトスコープ一式をすべて復元します。

信頼済みプロキシ認証やプライベートイングレスの none など、 ID を伴うモードでは、明示的に宣言されたスコープを引き続き尊重できます。実際の信頼境界を分離するには、個別の Gateway を使用してください。

Was this useful?