サンドボックス実行
エージェントが生成または呼び出すものはすべて、環境固有の資格情報（ambient credentials）を持たず、制限されたファイルシステム、制御された送信（egress）、および厳格なリソース制限を備えた、使い捨ての隔離環境内で実行します。サンドボックスが存在するのは、エージェントが悪意を持っているからではなく、エージェントへの入力が悪意を持っている可能性があるからです。
定義
サンドボックス実行とは、エージェントが生成したコードやエージェントが呼び出したアクションを、隔離されたエフェメラル（一時的）な環境内で実行する手法です。そのファイルシステム、ネットワーク、資格情報、およびリソースは、エージェントではなくホストによって制限されるため、乗っ取られたり誤動作したりしたエージェントが外部に影響を与えるのを防ぐことができます。
課題
ホスト上でコードを実行するエージェントは、ホストの資格情報、ファイルシステム、ネットワーク上の位置などをそのまま継承します。そのため、インジェクションが1回成功したり、自信満々に間違ったコマンドが1回実行されたりするだけで、マシン全体の侵害と区別がつかなくなります。
適用対象
エージェントがコードを実行したり、シェルコマンドを実行したり、パッケージをインストールしたり、信頼できないファイルを処理したりする場合は、常にこれを使用します。基準は低く設定すべきです。エージェントが実行を引き起こす可能性があるなら、その実行はサンドボックス内で行われるべきです。
解決策
エフェメラル（一時的）にします。タスクごとに環境を作成し、終了後に破棄します。次のタスクが要求していない状態（ステート）は決して引き継がないでください。永続化こそが、単発の侵害を足がかりへと変えてしまう原因です。
環境固有の資格情報（ambient credentials）を排除します。環境内に存在するからという理由だけで利用できるものは何もない状態にすべきです。タスクが必要とする、範囲を厳密に限定したシークレットのみを、その実行期間中だけ注入します。
ファイルシステムを作業セットに制限します。リポジトリや入力のみをマウントし、それ以外はマウントしません。また、書き込みが不要なものはすべて読み取り専用でマウントします。
サンドボックスの周囲ではなく、サンドボックスの「内部」で送信（egress）を制限します。攻撃者の視点からは、隔離とネットワークポリシーは同一のコントロールであり、ネットワークが開放されたサンドボックスは「電話のある刑務所」と同じです。
リソース（CPU、メモリ、ディスク、実時間、プロセス数）に上限を設けます。リソースの暴走消費は、攻撃者がいなくても、最も早く、最も頻繁に発生する障害モードです。
境界を越えたもの（どのファイルが入り、どのファイルが出ていき、どの宛先にアクセスしたか）をログに記録します。境界は、そこを通過したものを可視化できて初めて役に立ちます。
コンポーネント
メリット
- 「エージェントが悪質なものを実行した」という事態を、インシデントから「破棄されたコンテナ」へと変換します。
- エージェントに本物の実行能力を安全に付与できるようにします。これこそが、多くの場合においてエージェントを真に有用なものにする要素です。
- 攻撃だけでなく、悪意のない誤りも制限します。同一のコントロールで、無限ループとインジェクションされたペイロードの両方を捕捉できます。
- 観察のための明確な場所を提供します。タスクが触れたものはすべて、単一の境界を越えるためです。
リスク
- 想定よりも隔離が弱いこと：共有カーネルは、執拗なエスケープに対するセキュリティ境界にはならず、コンテナをmicroVMのように扱うのはカテゴリーエラーです。
- 利便性のために資格情報が持ち込まれること：マウントされた設定ファイルが1つあるだけで、このパターン全体が台無しになります。
- 再構築が遅いためにサンドボックスが密かに永続化し、安全性を担保していたエフェメラル（一時的）な性質が失われること。
- 残された共有サーフェス（マウントされたボリューム、オーケストレーターAPI、またはサンドボックスが依然として到達できるネットワーク）を介したエスケープ。
非推奨のケース
- 実行能力を持たない読み取り専用のエージェント。隔離すべき対象がなく、コストに見合うメリットが得られません。
- 環境の起動時間がタスクの大部分を占める、レイテンシーが極めて重要なインラインパス。この場合は、制限されたインタプリタや純粋関数など、より限定的なコントロールの方が適しています。
- サンドボックスが、本来は与えないために存在するはずの資格情報を必要とする場合。これは、タスクを隔離するのではなく、分割すべきであるという兆候です。
テクノロジー
事例
- タスクごとに新しいコンテナにクローンを作成するコーディングエージェント。リポジトリはマウントされ、クラウドの資格情報は存在せず、送信（egress）はパッケージレジストリに制限されています。悪意のある依存関係がインストールされても、破棄されるのはそのコンテナだけであり、それ以外に影響はありません。
- 入力データセットを読み取り専用でマウントし、ネットワーク接続を一切持たず、実行時間の上限を設定したmicroVM内で、生成されたPythonを実行するデータ分析エージェント。生成されたコードが誤っている可能性はありますが、高コストになったり、データを外部に流出させたりすることはありません。
- 信頼できないPDFを使い捨て環境内で開く文書処理エージェント。アップロードされたファイル内のパーサーの脆弱性を突くエクスプロイトは、ホストへの現実的な侵入経路であり、そのファイルは外部から届いたものだからです。
KPI
- サンドボックス化された実行の割合
- カバレッジの数値。サンドボックス化された割合がどうであれ、サンドボックスの外で実行されているものこそが、実際のセキュリティ体制を示します。
- サンドボックスの生存期間
- 環境が存続する期間。生存期間が長くなっている場合は、エフェメラル（一時的）な性質が失われ、永続化へと侵食されていることを意味します。
- リソース上限への到達回数
- クォータやタイムアウトによって停止されたタスク。暴走した生成と、厳しすぎる実際の上限設定の両方が混在する、有用な指標です。
- 実行時に存在するシークレット数
- 環境内でアクセス可能な資格情報の数。目標はタスクが必要とする最小限であり、多くの場合ゼロです。
観察された失敗パターン
- 利便性のためのマウント：タスクのエラーを解消するために、ホームディレクトリ、資格情報ファイル、またはソケットをマウントしてしまうこと。
- 永続的な再利用：再構築コストが高すぎるために環境がタスクごとのものではなくなり、状態と侵害の両方が存続してしまうこと。
- 境界内部での送信（egress）の開放：強力に隔離されていてもネットワークが自由であれば、それはファイルシステムに対してのみ機能する封じ込めにすぎません。
- オーケストレーターへの到達可能性：サンドボックスがサンドボックスを管理するAPIを呼び出せる状態。これはエクスプロイトによるものではなく、設計上のエスケープです。
得られた教訓
- 生成を信頼する前に、実行を隔離します。サンドボックスこそが、エージェントにコードを実行させることを妥当にする要素です。
- エフェメラル（一時的）であることがセキュリティ特性です。隔離だけでは問題を先送りするにすぎません。
- 存在しない資格情報は盗まれません。そして、それこそがエスケープが発生した後に機能する唯一のコントロールです。
- サンドボックスが作動する原因のほとんどは、攻撃ではなく悪意のない誤りです。それはこのパターンが機能している証拠であり、不要であったことを示すものではありません。
FAQ
- コンテナで十分ですか、それともmicroVMが必要ですか？
- 内部で何を実行するかによって異なります。インジェクションのリスクがある自社コードの場合、資格情報を持たず、送信（egress）を制限した堅牢なコンテナで通常は十分です。信頼できないソースからの任意のコードを実行する場合は、共有カーネルからエスケープされる可能性があると想定し、microVMを使用してください。
- 最小権限のツール設定とはどのように異なりますか？
- 最小権限はエージェントが要求できるものを制限し、サンドボックスは何かを実行したときに起こることを制限します。一方はリクエストを管理し、もう一方はそれが実行される環境を管理します。コードを実行するエージェントにはその両方が必要です。
- サンドボックスを導入すると動作が遅くなります。それだけの価値はありますか？
- ゼロと比較するのではなく、代替コストと比較してください。レイテンシーの大部分は環境の起動によるものですが、これはプールや事前ウォームアップされたイメージによって大幅に削減できます。サンドボックスが防ぐ障害は、エージェントを実行するホストの侵害です。