1. エージェントにサンドボックスが必要な理由は何ですか?
Claude Code や Codex などの AI プログラミング アシスタントを使用しているとします。
コードの変更、依存関係のインストール、テストの実行をエージェントに依頼すると、すべて自動的に完了します。
しかし、ここで問題が発生します。
エージェントが次のような危険なコマンドを実行した場合 **rm -rf ~/**個人ファイルをすべて削除した場合はどうすればよいですか?
さらに深刻なのは、エージェントがプロンプト インジェクションによって攻撃される可能性があることです。
たとえば、悪意のある命令を含むファイルを読み取り、その中の命令がユーザーの要件であると誤って信じ、密かに SSH 秘密キーを読み取って外部サーバーに送信しようとします。
問題の根本は次のとおりです。
エージェントは自律的にタスクを実行できますが、無制限の操作権限を持たせることはできません。
これは、Agent Sandbox (サンドボックス) が解決したい問題です。
2. エージェント サンドボックスとは何ですか?
中国語でサンドボックスと呼ばれるサンドボックス本質的には隔離された動作環境です。
柵で囲まれた庭だと考えてください。
- 庭ではエージェントは自由に移動できます。
- 中庭の外では、エージェントは自由に訪問することはできません。
- フェンスを越える必要がある場合は、追加の許可を取得する必要があります。
たとえば、エージェントに Python プロジェクトを変更するように依頼します。
サンドボックスがないと、実行されるコマンドに現在のユーザーの完全なファイル アクセス権が与えられる可能性があります。
サンドボックスを設置すると、次のことを規定できます。
- プロジェクトコードの読み取りを許可します。
- 現在のプロジェクト ディレクトリのみを変更できます。
- SSH 秘密キーなどの機密ファイルへのアクセスを無効にします。
- 指定されたネットワーク サービスへの接続のみを許可します。
これにより、エージェントが誤った指示や悪意のある指示を実行した場合でも、被害の範囲をある程度限定することができます。
許可ポップアップを使用しないのはなぜでしょうか?
従来の方法では、エージェントがコマンドを実行するたびに、最初にユーザーの同意を求めるように要求されます。
ただし、エージェントが 1 つのタスクで数十のコマンドを実行する必要がある場合は、[許可]をクリックし続ける必要があります。
時間が経つと、ユーザーはコマンドを注意深くチェックしなくなってしまいがちです。
これは呼ばれます 承認疲労。
サンドボックスは別の考え方を提供します。
ユーザーに繰り返し承認を求めるのではなく、エージェントのアクティビティの範囲を事前に定義し、その範囲内で自動的に実行し、範囲を超えて制限や承認を課す方が適切です。
自動化の程度が向上するだけでなく、セキュリティ リスクも軽減できます。
3. エージェント サンドボックスはどのように実装されますか?
サンドボックスの 2 つの中心的な機能は次のとおりです。
ファイルシステムの分離 + ネットワークの分離。
1. ファイルシステムの分離
ファイル システムの分離により、主に次の 2 つの問題が解決されます。
- エージェントはどのようなファイルを読み取ることができますか?
- エージェントはどのファイルを変更できますか?
プロジェクト ディレクトリが次であると仮定します。
/home/user/project/
サンドボックスを設定できます。
エージェントに次の変更を許可します。
/home/user/project/
エージェントのアクセスを無効にします。
/home/user/.ssh/
エージェントの変更は禁止されています。
/home/user/.bashrc
これにより、エージェントが不正なファイル操作を実行した場合でも、サンドボックスによってブロックされます。
注意すべき点は、読み取り権限と書き込み権限は 2 つの独立した概念です。
たとえば、エージェントはシステム依存ライブラリを読み取る必要がある場合がありますが、これらのファイルを変更する権限を与えるべきではありません。
2. ネットワークの分離
ファイルアクセスを制限するだけでは十分ではありません。
エージェントが何らかの機密情報を読み取ったと仮定すると、ネットワーク制限がない場合、エージェントは引き続き情報を送信しようとする可能性があります。
したがって、サンドボックスはネットワーク アクセスも制御する必要があります。
一般的な実装は次のとおりです ネットワーク プロキシ (プロキシ) + ドメイン名のホワイトリスト。
たとえば、次のように指定できます。
以下へのアクセスを許可します:
registry.npmjs.org
アクセス禁止:
malicious.example.com
エージェントの実行時 npm install 通常の依存関係のダウンロードは続行できます。
ただし、悪意のある依存関係が未承認のサーバーに接続しようとすると、リクエストは傍受されます。
もちろん、サンドボックスが直接ネットワークを効果的に制限し、プログラムがプロキシをバイパスするのを防ぐことができることが前提です。
ファイル システムの分離はローカル リソースへのアクセスを制限する役割を果たし、ネットワークの分離は外部通信を制限する役割を果たします。二人は協力して働きます。
4. これらの制限を実際に施行するのは誰ですか?
ここで重要な質問があります。
エージェントがサンドボックス ルールに準拠していない場合はどうなりますか?
したがって、信頼できるサンドボックスは、Prompt に依存してモデルに「特定のファイルを変更しない」ように指示するだけではなく、オペレーティング システムが提供する分離メカニズムを使用する必要があります。
Claude Code のサンドボックス ソリューションを例に挙げます。
macOS：シートベルト
シートベルトは、macOS が提供するサンドボックス メカニズムで、ファイル システムなどのリソースへのプロセス アクセスを制限できます。
Linux：バブルラップ（bwrap）
bubblewrap は、Linux ネームスペースなどのメカニズムを使用して、プロセスの分離環境を作成します。
たとえば、エージェントは必要なシステム ディレクトリとプロジェクト ディレクトリのみを参照できますが、ホスト マシン上の一部の機密ファイルは参照できません。
これは、単純な Prompt 制約とは本質的に異なります。
プロンプト制約はエージェントに「これを行うべきではありません」と伝えます。
オペレーティング システムの分離は次のとおりです。
エージェントがこれを実行したくても、オペレーティング システムはそれを許可しません。
5. Docker、gVisor、MicroVM とは何ですか?
シートベルトやバブルラップに加えて、業界にはさまざまな絶縁技術があります。
それらの主な違いは、分離方法とセキュリティ境界です。
| テクノロジー | コア機能 |
|---|---|
| ドッカー | コンテナの分離、共有ホストカーネル |
| バブルラップ | Linux ネームスペースを活用した軽量プロセス分離 |
| gバイザー | ホスト カーネルの露出を減らすために、ユーザー空間で多数のシステム コールを処理します。 |
| ファイアクラッカー MicroVM | 独立したゲスト カーネルを備えた軽量の仮想マシンを使用する |
これは単純に次のように理解できます。
Docker、バブルラップ 多くの一般的なアプリケーション分離シナリオに適していますが、ホスト カーネルは引き続き共有されます。
gバイザー 信頼できないプログラムがホスト カーネルに直接接触する可能性をさらに減らします。
ファイアクラッカー MicroVM 仮想マシンを通じて、より独立したオペレーティング環境を提供します。これは、高いセキュリティ要件が必要なマルチテナントのシナリオに適しています。
ただし、隔離することが必ずしも良いとは限りません。
ローカルのパーソナル エージェントの場合は、通常、軽量のサンドボックスの方が便利です。大量の馴染みのないユーザー コードを実行する必要があるクラウド エージェントの場合は、より強力な分離ソリューションを検討する必要があります。
具体的な選択は、権限の構成、パフォーマンスのオーバーヘッド、セキュリティ要件によっても異なります。
6. サンドボックスを使用すると、エージェントは絶対に安全ですか?
あまり。
サンドボックスはエージェントの操作範囲のみを制限できます。エージェントが許容範囲内で間違いを犯さないという保証はありません。
例えば：
1. サンドボックスを使用すると、現在のプロジェクトを変更できます。
エージェントが誤ってプロジェクト コードを削除する可能性は依然としてあります。
2. ネットワーク ホワイトリストの設定範囲が広すぎる
悪意のあるプログラムが、許可されたネットワーク サービスを悪用してデータを窃取する可能性があります。
3. サンドボックスにより危険なインターフェイスへのアクセスが可能になる
たとえば、Docker ソケットを開くと、サンドボックス内のプロセスがホスト リソースを間接的に制御できるようになります。
4. サンドボックスの起動に失敗した後の自動ダウングレード
サンドボックスの起動に失敗した場合でも、システムがエージェントによるコマンドの実行を制限なく許可している場合、分離は無意味になります。
したがって、エンジニアリングの実践では、次の 3 つの原則に従う必要があります。
- 最小限の権限: タスクを完了するために必要な権限のみを付与します。
- デフォルトで拒否: 明示的に許可されていない機密操作は、自動的に許可されるべきではありません。
- 多層防御: サンドボックスは、権限の承認、ログの監査、バックアップ、その他のメカニズムと連携して、システムを共同で保護します。
7. まとめ
エージェント サンドボックスの核となるアイデアは、実際には非常にシンプルです。
エージェントにタスクを完了する権限を与えますが、ユーザーのすべての権限を持っている必要はありません。
それは 3 つのレベルから理解できます。
- なぜ必要なのでしょうか? エージェントの誤った操作や悪意のある指示が制御不能な損害を引き起こすことを防ぎます。
- それを達成するにはどうすればよいでしょうか? ファイル システムの分離、ネットワークの分離、オペレーティング システム レベルの権限制御を通じて、エージェントの操作範囲を制限します。
- 選び方は？ ローカル エージェントは軽量のサンドボックスを検討できますが、クラウド マルチテナント エージェントはより強力な分離テクノロジーを必要とする場合があります。
エージェントが単純なチャット アシスタントから、コードの作成、コマンドの実行、サービスの展開が可能な自動システムに徐々に変化するにつれて、サンドボックスはエージェント エンジニアリング アーキテクチャの重要な部分になるでしょう。
サンドボックスの目標は、エージェントに何もさせないことではなく、制御された境界内でエージェントが安全に動作できるようにすることです。
