OS サンドボックスの仕組み
サンドボックスの実装はプラットフォームによって異なります。しかし、その多くは同じ OS プリミティブ（macOS の Seatbelt と Linux の bubblewrap）を使い、同じ既定の姿勢を取ります。読み取りは広く許可し、書き込みは作業ディレクトリと一時ディレクトリに制限し、ネットワークアクセスは制限するか既定で無効にします。各実装は、2 つの制御も分離します。サンドボックスはアクセス可能な対象を制限する技術的境界です。承認ポリシーは、エージェントが操作前に確認を求める必要がある場合を決めます。異なる保護レイヤー
コーディングエージェント用サンドボックスの限界
サンドボックスは書き込み可能な場所を制限します。しかし、その境界内の操作が破壊的かどうかは理解しません。次のコマンドはすべてサンドボックスで許可されます。現在の作業ディレクトリ内に書き込むか、サンドボックスが許可したファイルを読み取るか、許可されたリモートへアクセスするためです。これらのコマンドを自動実行するか確認を要求するかは、エージェントのサンドボックスモードと承認ポリシーによって決まります。
git push --force などのネットワーク依存コマンドは、許可ドメインの設定にも依存します。サンドボックスは
git reset --hard を安全な操作とみなします。このコマンドは現在のディレクトリ内のファイルのみを変更するためです。しかし、コーディングエージェントは未コミットの作業をすべて破棄します。cc-safety-net rule wrapper add <command> で宣言すると、CC Safety Net はプロキシを通して見える子コマンドを調べ、同じルールを適用します。サンドボックスは子コマンドを調べず、プロセスツリー全体がアクセスできる対象のみを制限します。
サンドボックスが適する場合
主な懸念が次の場合は、サンドボックスが適切です。- プロンプトインジェクション攻撃：外向きネットワークドメインを制限して、情報流出のリスクを低減する
- 悪意のある依存関係：信頼できないパッケージによるファイルシステムへの書き込みとネットワークアクセスを制限する
- 信頼できないコードの実行：OS レベルの封じ込めは、コマンドテキストの解析より根本的に強い
- ネットワーク制御：CC Safety Net にはネットワーク保護がない
CC Safety Net が対処できない範囲
CC Safety Net は対応するツール呼び出しを解釈しますが、プロセスを封じ込めません。次の制限には意味解析ではなく封じ込めが必要です。- ネットワーク経由の情報流出。 runtime 評価はネットワーク要求を行わず、pipeline は外向き通信を検査しません。ドメインの allowlist はサンドボックスが担当します。
- 認識対象外からの読み取り。 機密パス保護は、
.envとその派生形、SSH 鍵、クラウドの認証情報ストア、コーディング CLI の認証情報ファイル、設定した deny path という上限付きのパターン群を、対応するコマンド、パス、検索、patch の形式にわたって対象にします。完全な一覧は機密情報保護のリファレンスを参照してください。これは一般的な読み取り境界ではないため、認識されないファイル内の認証情報は保護されません。サンドボックスは、重要なファイルを特定せずにすべての読み取りを制限します。 - バイナリ内部に隠された動作。
some-tool --task destructive-cleanupはコマンドテキストでは安全に見えます。また、見える子コマンドを実行せずに書き換えるプロキシは、transparent wrapper として設定しても展開できません。 - 完全なファイルシステム適用。 拒否はツール呼び出しを止めますが、権限は適用しません。best-effort のインターセプトではなく完全な保護が必要な場合は、信頼できる write broker、OS 権限、またはサンドボックスを使います。