オペレーターのスコープ

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

関連: セキュリティ, Gateway プロトコル, Gateway ペアリング, デバイス CLI.

# ロール

Gateway WebSocket クライアントは、1つのロールで接続します。

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

オペレーター RPC メソッドには operator ロールが必要です。Node 起点のメソッドには node ロールが必要です。

# スコープレベル

スコープ	意味
operator.read	読み取り専用のステータス、リスト、カタログ、ログ、セッション読み取り、その他の非変更系コントロールプレーン呼び出し。
operator.write	メッセージ送信、ツール呼び出し、talk/voice 設定の更新、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 は通常、write スコープのメソッドですが、永続的な /config set および /config unset には、コマンドレベルで operator.admin が必要です。

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

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

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

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

• オペレーターロールを持たないリクエストでは、オペレータートークンスコープの承認は不要です。
• operator.read、operator.write、operator.approvals、 operator.pairing、または operator.talk.secrets のリクエストでは、呼び出し元が それらのスコープ、または operator.admin を持っている必要があります。
• operator.admin のリクエストには operator.admin が必要です。
• 明示的なスコープを持たない修復リクエストは、既存のオペレータートークンスコープを継承できます。その既存トークンが admin スコープの場合でも、承認には operator.admin が必要です。

ペアリング済みデバイストークンセッションでは、呼び出し元が operator.admin も持っていない限り、 管理は自己スコープです。非管理者の呼び出し元には自分自身のペアリングエントリのみが表示され、 自分自身の保留中リクエストのみを承認または拒否でき、自分自身のデバイスエントリのみをローテーション、失効、または削除できます。

# Node ペアリング承認

レガシーの node.pair.* は、Gateway が所有する別個の Node ペアリングストアを使用します。WS Node は role: node でデバイスペアリングを使用しますが、同じ承認レベルの語彙が適用されます。

node.pair.approve は、保留中リクエストのコマンドリストを使用して、追加で必要なスコープを導出します。

• コマンドなしのリクエスト: operator.pairing
• exec 以外の Node コマンド: operator.pairing + operator.write
• system.run、system.run.prepare、または system.which: operator.pairing + operator.admin

Node ペアリングは ID と信頼を確立します。これは Node 独自の system.run exec 承認ポリシーを置き換えるものではありません。

# 共有シークレット認証

共有 Gateway トークン/パスワード認証は、その Gateway に対する信頼されたオペレーターアクセスとして扱われます。OpenAI 互換 HTTP サーフェスと /tools/invoke は、 呼び出し元がより狭い宣言済みスコープを送信した場合でも、共有シークレット bearer 認証に対して通常の完全なオペレーター既定スコープセットを復元します。

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