意図してサンドボックスを抜け出す

エージェントをサンドボックス化すると決めるのは簡単ですが、それと付き合っていくのはもっと大変です。正当なタスクがサンドボックスの外にある何かを必要とした瞬間、偶然ではなく意図的に外へ出す方法が必要になるからです。それに対するOpenClawの答えがelevatedモードです。もともとサンドボックス化されていないエージェントには何も変えず、サンドボックス化されたエージェントには、ホストへの狭く、ゲートで守られた経路を開きます。コマンドが1つ動くまでに複数のゲートがそろう必要があるので、ゲートについてはじっくり読む価値があります。

elevatedモードの働き

• elevatedモードを使うと、サンドボックス化されたエージェントが、エージェントに設定された通常のサンドボックスから抜け出し、代わりにサンドボックスの外でコマンドを実行できます。承認ゲートは引き続き設定可能です。
• 動作が変わるのは、エージェントがサンドボックス化されている場合だけです。サンドボックス化されていないエージェントは、すでにシェルコマンドをホスト上で実行しているからです。
• 実際に使われるホストはデフォルトではGatewayで、設定またはセッションのexecターゲットがすでにノードである場合にのみノードになります。つまり昇格は、ホストをまたいだ上書きではありません。
• セッションごとに4つのディレクティブを使えます。承認を維持するonレベル、そのエイリアスであるaskレベル、承認を省略できるfullレベル、そしてサンドボックス内に閉じた実行に戻るoffレベルです。

作成者のロールがサンドボックス化を必須としているセッションは、elevatedモードを使って抜け出すことはできません。

そろう必要があるゲート

利用できるかどうかはスイッチ1つで決まるのではなく、すべての条件を満たす必要があります。グローバルのゲートがオンであり、かつ送信者がそのチャネルの許可リストに載っていなければなりません。許可リストはチャネルごとの識別子リストとして管理されます。エージェントごとのゲートはさらに制限を加えることしかできないため、エージェントが対象となるには、グローバルとエージェントごとの両方のゲートがオンでなければなりません。エージェントごとの許可リストも同じ仕組みで、送信者はグローバルとエージェントごとの両方のリストに一致する必要があります。チャネルプラグインはSDKのアダプターフックを通じてフォールバックの許可リストを提供できますが、現在このフックを実装している同梱チャネルはないため、実際にはどのプロバイダーにも明示的な許可リストのエントリーが必要です。どれか1つでもゲートを通過できなければ、elevatedは部分的に付与されるのではなく、利用不可として扱われます。エントリー自体は、送信者ID、E.164形式の番号、Fromフィールドに一致する単純な識別子にもできますし、表示名、ユーザー名、タグを対象とするプレフィックスを付けることもできます。あいまいさを排除したい場合は、明示的なアイデンティティのプレフィックスも使えます。さらに、目立たない依存関係がもう1つあります。bashのチャットコマンドは独自のフラグで制御されるうえに、elevatedが有効であることも必要とするため、elevatedをオフにすると、こうしたシェルメッセージも使えなくなります。

レベルと優先順位

• ディレクティブだけのメッセージはセッションのデフォルトを設定し、同じディレクティブをリクエストの先頭にインラインで付けた場合は、そのメッセージにだけ適用されます。
• 解決はまずインラインのディレクティブ、次にセッションの上書き、最後に設定で指定されたグローバルのデフォルトの順に行われます。
• fullモードで承認が省略されるのは、解決されたexecモードとホストの承認ポリシーがすでに完全に許容的な場合だけです。onレベルとaskレベルでは、設定された承認ルールが常に適用されます。

elevatedモードは、抜け出す価値のあるGatewayのサンドボックスがすでにあること、そしてコマンドが到達した後に何をしてよいかをすでに決めていることを前提としています。後者はexec承認の役割です。昇格はそのどちらにも取って代わるものではありません。

制限が崩れない理由

この設計では、昇格を1つの軸だけに作用するレバーとして扱い、汎用的な上書き手段になることを許しません。ツールポリシーがexecツールを完全に拒否している場合、昇格でそれを復活させることはできません。両者は別々の問いに答えるもので、より制限の厳しいほうが優先されるからです。認証済みのセッション作成者のオペレーターロールがサンドボックスを必須としていた場合、昇格してもGatewayやノードでコマンドを実行することは一切できず、オペレーターの判断がチャットのディレクティブより上に保たれます。ホストの選択も同じように扱われ、自動のターゲットが、マシンを自由に選べる状態に変わることはありません。これらのゲートを分けておくことで組み合わせの結果が予測可能になります。ドキュメントには、ツール呼び出しの時点でこの3つがどう相互作用するかを説明したページがあり、一度は通して読む価値があります（3つのゲートの組み合わさり方）。関連するexecディレクティブはまた別のレバーで、昇格をまったく必要とせずに、許可された送信者向けにセッションごとのexecのデフォルトを調整します。まとめると、これらのルールにより、昇格をオンにして広がるのはちょうど1つのことだけで、ほかの境界はすべて元の場所にとどまります。

Dialiでは

Dialiでは、お客様ごとに専用のアシスタントが動いており、DialiのマネージドOpenClawホスティングのランタイム設定はダッシュボードから生成され、リリースのたびに置き換えられます。境界のどれかを広げる前に、それぞれがどこにあるのかを確認したい場合は、まずDialiのセキュリティのページをご覧ください。

• エージェントが実際にサンドボックス化されていなければ、elevatedは何も変えません。
• グローバル、エージェントごと、そしてそのチャネルの許可リスト、すべてのゲートを通過する必要があります。
• 承認を省略できるのはfullレベルだけで、それもポリシーがすでに許容的な場合に限られます。