Gateway

オペレーターのスコープ

オペレータースコープは、Gateway クライアントが認証後に実行できる操作を制限します。これは、信頼された単一の 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`	実行および Plugin 承認 API。
`operator.questions`	対話型質問の一覧表示、読み取り、回答、解決。
`operator.talk.secrets`	シークレットを含む Talk 設定の読み取り。

将来追加される未知の operator.* スコープには、呼び出し元がすでに operator.admin を保持していない限り、完全一致が必要です。

メソッドスコープは最初のゲートにすぎない

各 Gateway RPC には、リクエストがハンドラーに到達できるかどうかを決定する最小権限のメソッドスコープがあります。パラメーターを考慮するメソッドは、ディスパッチ前にそのスコープを導出するため、認可エラーには正規化された単一の構造化レスポンスが使用されます。

agent には、通常のターンでは operator.write が必要であり、 /new または /reset のセッションライフサイクルコマンドでは operator.admin が必要です。
node.invoke には、通常の中継コマンドでは operator.write が必要であり、 browser.proxy、fs.listDir、terminal.upload では operator.admin が必要です。
talk.config には operator.read が必要です。さらに、includeSecrets: true には operator.talk.secrets も必要です。

一部のハンドラーはその後、承認または変更される具体的な対象に基づいて、より厳格なチェックを適用します。

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

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

セッション変更 RPC は、接続クライアントの client.id または client.mode とは無関係に、ネゴシエートされたオペレータースコープによって認可されます。クライアント ID は引き続き接続およびデバイス認証ポリシーに影響する可能性がありますが、セッション変更権限を付与することも取り除くこともありません。

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

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

デバイスリクエストを承認する場合：

オペレーターロールを含まないリクエストには、オペレータースコープの承認は不要です。
オペレーター以外のデバイスロール（たとえば node）のリクエストには、 device.pair.approve 自体には operator.pairing しか必要ない場合でも、 operator.admin が必要です。
operator.read、operator.write、operator.approvals、 operator.questions、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 実行承認ポリシーを置き換えるものではありません。

共有シークレット認証

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

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

Was this useful?