AIエージェントサンドボックスの分離レビューでは、生成されたコードが実際のシステムやデータに対して実行される前に、実行境界、ファイルシステムの露出、プロセスとリソースの制御、ネットワークとDNSポリシー、パッケージ取得動作、シークレットの取り扱い、ログ、アーティファクトのキャプチャ、リセットセマンティクス、人間の承認ポイント、およびインシデント対応の前提条件を検証する必要があります。
AIエージェント分離レビューが重要な理由
従来のサンドボックスレビューは、多くの場合、「このシステムはホストを危険にさらすことなく信頼できないコードを実行できるか？」という1つの質問から始まります。AIエージェントのレビューでもその質問は必要ですが、エージェントは単一のスクリプトを実行する以上のことを行うため、より広範なチェックリストも必要です。エージェントは、リポジトリのクローン、パッケージのインストール、サイトの閲覧、ファイルの書き込み、APIの呼び出し、GUIセッションの開始、失敗したコマンドの再試行、モデル出力をシェルアクションに変換することなどを行います。
これにより、リスクモデルが変化します。コーディングエージェントは、ターミナルアクセス権を持つジュニアエンジニアのように振る舞う可能性があります。データ分析エージェントは、ファイルをアップロードし、パッケージを取得し、チャートをエクスポートするノートブックユーザーのように振る舞う可能性があります。ブラウザエージェントは、Cookie、ダウンロード、スクリーンショット、フォーム入力操作を行うユーザーのように振る舞う可能性があります。強化学習または評価エージェントは、同じタスクを何千回も実行する可能性があり、その場合、小さなエグレス、リソース、またはログのギャップが大規模に影響を及ぼします。
以下のチェックリストを使用して、サンドボックスを機密性の高いリポジトリ、顧客データ、内部API、特権認証情報、または本番デプロイメントシステムに接続する前に、境界をレビューしてください。
実行境界のセキュリティ
エージェントのワークロードをホストや他のテナントから分離する境界から始めます。レビューは、セキュリティエンジニアがエージェントが悪意のあるコードを実行した場合に何が失敗するかを説明できるほど明確である必要があります。
確認事項：
- 使用されている分離レイヤーは何か：コンテナ、microVM、フルVM、gVisorのようなシステムコール仲介、Kubernetesサンドボックス、またはその他のモデルか？
- 各サンドボックスは独自のカーネル境界を取得するか、それともホストカーネルを共有するか？
- CPU、メモリ、ファイルシステム、プロセステーブル、ネットワークスタック、およびデバイスアクセスは、他のワークロードから分離されているか？
- サンドボックスは、コンテナランタイムソケット、ホストプロセス名前空間、ホストパス、クラウドメタデータサービス、または特権デバイスにアクセスできるか？
- ブラウザセッション、GUIデスクトップ、VNCストリーム、コードインタプリタは、同じ境界内にどのように配置されているか？
- 文書化されたホスト脱出の前提条件は何か：封じ込め、リスク低減、またはより強力な保証か？
「安全なサンドボックス」という一般的な記述を回答全体として受け入れることは避けてください。具体的な分離メカニズム、境界の内側にあるもの、外側にあるもの、そしてどの前提条件にまだ補完的制御が必要かを尋ねてください。
ファイルシステムとマウントのセキュリティ
エージェントファイルシステムは、別途レビューに値します。なぜなら、エージェントは通常の作業の一部としてファイルを作成、編集、および外部に持ち出すことが多いからです。リスクがあるのは、読み取り/書き込みアクセスだけではありません。タスク間での偶発的な持ち越しや、ユーザーが共有するつもりのなかったプロジェクトファイルへの暗黙的なアクセスもリスクです。
確認事項：
- デフォルトのファイルシステムは、空、テンプレートベース、またはプロジェクトファイルがプリロードされているか？
- エージェントが書き込み可能なパスと、読み取り専用のパスはどれか？
- ホストディレクトリ、リポジトリマウント、SSHキー、パッケージキャッシュ、ブラウザプロファイル、またはクラウド設定ファイルがサンドボックスにマウントされているか？
- エージェントは、シンボリックリンクやバインドマウントをたどって意図しないパスにアクセスできるか？
- ファイルアクセスは、サンドボックスごと、ユーザーごと、プロジェクトごと、または組織ごとにスコープされているか？
- アップロードされたファイルは、削除、保持、スナップショット作成、または後続のセッションで利用可能になるか？
- 生成されたファイルと差分は、サンドボックスから持ち出される前にレビュー可能か？
コーディングエージェントの場合、最も安全なパターンは通常、狭いプロジェクトワークスペース、明示的なアーティファクトエクスポート、および開発者のホームディレクトリや共有認証情報ストアへのアンビエントアクセスがないことです。
プロセスとリソースの制御
エージェントは、誤ってフォーク爆弾を作成したり、ビルドをハングさせたり、ディスクを満たしたり、バックグラウンドサーバーを実行したり、高価なコマンドを再試行し続けたりする可能性があります。リソース制御は、それらの障害を限定された障害に変えます。
確認事項：
- CPU、メモリ、ディスク、ファイルディスクリプタ、プロセス数、およびランタイム制限は適用されているか？
- コマンドとセッションの最大経過時間は設定されているか？
- バックグラウンドプロセスは、コマンドが終了した後も存続するか？
- サンドボックスが停止またはリセットされたときに、子プロセスは強制終了されるか？
- エージェントはリッスンポートを開くことができ、もし可能であれば、それらのポートは明示的なプレビューメカニズムを介してのみ公開されるか？
- 大量のstdout/stderrログは、切り詰められ、ストリームされ、または保存されるか？
- クォータ違反は、サイレントに再試行されるのではなく、呼び出し元に表示されるか？
本番エージェントワークフローの場合、制限は単なる課金の概念ではなく、APIコントラクトの一部であるべきです。セキュリティチームは、エージェントが制限に達したときに何が起こるか、そしてその障害が部分的な状態を残すかどうかを知っている必要があります。
ネットワークとエグレス制御
ネットワークポリシーは、多くのサンドボックスレビューが曖昧になりがちな部分です。一部のエージェントワークロードはインターネットアクセスを必要としますが、他のワークロードはデフォルトでアクセスを持つべきではありません。正しい答えは、サンドボックスがテストを実行しているのか、公開ページを閲覧しているのか、パッケージを取得しているのか、内部APIを呼び出しているのか、機密データを処理しているのかによって異なります。
確認事項：
- アウトバウンドインターネットアクセスはデフォルトで有効か？
- ネットワークアクセスは、サンドボックスごと、テンプレートごと、またはプロジェクトごとに無効化できるか？
- ドメイン、IP範囲、ポート、またはプロトコルに対して、エグレス許可リストは利用可能か？
- クラウドメタデータエンドポイントへのアクセスはブロックされているか？
- サンドボックスは、プライベートVPC、内部サービス、データベース、またはデプロイメントシステムに到達できるか？
- ブラウザトラフィック、CLIトラフィック、パッケージマネージャートラフィック、および直接ソケット接続は、同じポリシーによって管理されているか？
- アウトバウンドリクエストは、タイムスタンプ、宛先、プロセスまたはコマンドコンテキスト、および応答ステータスとともにログに記録されているか？
エージェントのエグレスは、ビルドシステムのエグレスと同様に扱ってください。エージェントがパッケージをインストールしたり、アーティファクトをアップロードしたり、Webhookを呼び出したり、任意のサイトを閲覧したりできる場合、レビューでは悪意のあるコードとプロンプトインジェクションによる動作の両方をカバーする必要があります。
DNSとパッケージアクセスのリスク
DNSとパッケージマネージャーは、インフラストラクチャの配管のように感じられるため、見落とされがちです。エージェントにとって、それらは実行面の一部です。生成されたスクリプトは、DNSクエリにデータをエンコードしたり、タイポスクワッティングされたパッケージを取得したり、レビューされたことのないURLからスクリプトをプルしたりする可能性があります。
確認事項：
- DNSトラフィックは、HTTPやHTTPSと同じエグレスポリシーに従うか？
- DNSクエリはログに記録され、フィルタリングされ、または管理されたリゾルバーを強制的に通過するか？
- パッケージマネージャーは、デフォルトでパブリックレジストリに到達できるか？
- パッケージレジストリは、許可リスト化、プロキシ化、キャッシュ化、または固定化されているか？
- インストールされたパッケージ名、バージョン、URL、ハッシュ、およびロックファイルの変更はキャプチャされるか？
- エージェントは、インストールスクリプト、postinstallフック、または任意のパッケージビルドステップを実行できるか？
- 新しい依存関係をテンプレートまたは本番ワークフローに永続化する前に、レビューゲートはあるか？
パッケージアクセスが必要な場合は、固定バージョン、ロックファイル、レジストリ許可リスト、およびレビュー担当者が何がダウンロードされ実行されたかを再構築できるログを優先してください。
シークレットの取り扱い
シークレットは、通常、サンドボックス境界を無意味にする最も速い方法です。エージェントが広範なトークンを認識した場合、ホストから脱出しなくてもデータを漏洩させる可能性があります。
確認事項：
- シークレットは、タスクが明示的に必要とする場合にのみ注入されるか？
- シークレットは、サンドボックス、タスク、リポジトリ、環境、および有効期間にスコープされているか？
- シークレットは、環境変数、ファイル、シェル履歴、プロセスリスト、ログ、スクリーンショット、またはブラウザストレージから読み取ることができるか？
- ログとアーティファクトは、保存またはエクスポートされる前に編集されているか？
- 長期有効な認証情報の代わりに、短期間のトークンが使用されているか？
- エージェントは、ホストからユーザーレベルのSSHキー、Git認証情報、クラウド認証情報、ブラウザCookie、またはAPIキーにアクセスできるか？
- シークレットアクセスは、監査ログに表示されるか？
実用的なルール：人間が信頼できないビルドジョブに認証情報を貼り付けることがないならば、より狭いスコープとより強力なログ記録なしに、自律エージェントにそれを与えないでください。
ログと監査証跡
セキュリティチームが必要とするのは、成功または失敗だけではありません。どのコードが実行されたか、どのファイルが変更されたか、どのネットワーク呼び出しが行われたか、そしてどの出力が生成されたかを知る必要があります。
確認事項：
- コマンド呼び出しは、引数、作業ディレクトリ、終了コード、開始時間、および期間とともにログに記録されているか？
- ファイルの読み取り、書き込み、削除、アップロード、ダウンロード、および権限変更は記録されているか？
- パッケージのインストールと外部フェッチはログに記録されているか？
- ブラウザのアクション、スクリーンショット、ダウンロード、およびフォーム送信は、関連する場合にキャプチャされているか？
- API呼び出し、ツール呼び出し、およびモデルからツールへの遷移は、同じセッションに関連付けられているか？
- ログは、サンドボックス内部からの改ざんに対して耐性があるか？
- 保持期間はどのくらいか、そして誰がログにアクセスできるか？
規制対象またはエンタープライズワークフローの場合、監査証跡はデバッグとインシデント後の再構築の両方をサポートする必要があります。部分的なターミナル転記では通常不十分です。
アーティファクトのキャプチャとレビュー
エージェントは、差分、テスト結果、レポート、スクリーンショット、生成されたファイル、プレビューURL、データセットなど、有用な出力を作成します。アーティファクトの取り扱いは、必要以上に状態を公開することなく、それらの出力をレビュー可能にする必要があります。
確認事項：
- どのアーティファクトが自動的にエクスポートされ、どのアーティファクトが明示的な選択を必要とするか？
- レビュー担当者は、生成されたファイルがコミット、アップロード、または別のサービスに送信される前に、それらを検査できるか？
- アーティファクトは、シークレット、マルウェア、安全でないファイルタイプ、または予期しないサイズについてスキャンされているか？
- ブラウザのダウンロードは、ソースコードの差分やテスト出力とは別に保存されているか？
- アーティファクトは、それらを生成した正確なコマンド、エージェントステップ、およびサンドボックスセッションにリンクバックできるか？
- アーティファクトは、サンドボックス削除後も保持され、そしてパージできるか？
目標は、ログ、スクリーンショット、アーカイブ、または生成されたバンドルを介した2番目のデータ漏洩チャネルを回避しながら、有用な証拠を保存することです。
ライフサイクルとリセット制御
エージェントセッションは、短命、長時間実行、一時停止、再開、スナップショット作成、またはテンプレートからクローン作成される可能性があります。各ライフサイクルモードによって境界が変わります。
確認事項：
- 各サンドボックスは、新規作成、状態からの再開、またはテンプレートからのクローン作成のいずれかか？
- 一時停止、再開、スナップショット、テンプレート作成、および削除の際に、どのデータが保持されるか？
- 一時ファイル、パッケージキャッシュ、シェル履歴、ブラウザCookie、およびローカルデータベースは、リセット時にクリアされるか？
- 侵害されたセッションは、再利用可能なテンプレートを汚染する可能性があるか？
- 最大セッションライフタイムはあるか？
- 停止されたサンドボックスは本当に終了するか、それともバックグラウンドタスクが継続する可能性があるか？
- 同じタスクをクリーンな環境から再現できるか？
リセット可能性は、評価や強化学習のワークロードにとっても重要です。各試行がわずかに異なる状態から開始される場合、セキュリティ所見とモデルの動作の信頼性が低下します。
人間の承認制御
人間の承認は、単なるUX機能ではありません。これは、信頼境界を越えるアクションのための制御プレーンです。
確認事項：
- どのアクションが自律的に実行でき、どのアクションに承認が必要か？
- 承認プロンプトは、コマンド、ファイル、宛先、認証情報スコープ、および予想される効果を表示するのに十分具体的か？
- ポリシーは、パッケージインストール、外部ネットワークアクセス、リポジトリ書き込み、デプロイメントコマンド、またはシークレットアクセスに対して承認を要求できるか？
- 承認は、ユーザー、タイムスタンプ、アクション、および結果のコマンドとともにログに記録されているか？
- 承認は、時間制限とタスク制限にすることができ、将来の広範な権限を付与するのではなく、特定のアクションに限定できるか？
- 緊急時対応パスはあるか、そしてそれは監査されているか？
不可逆的または影響の大きいアクション（ファイルの削除、本番ブランチへの書き込み、デプロイメントAPIの呼び出し、顧客データへのアクセス、サンドボックステンプレートの変更）には、人間の承認を使用してください。
インシデント対応の前提条件
境界が失敗した場合やワークフローが予期せぬ動作をした場合に何が起こるかを尋ねることなしに、サンドボックスレビューは完了しません。これは、リスクのあるアクションがモデル出力、プロンプトインジェクション、依存関係の侵害、または通常のソフトウェアバグによって引き起こされる可能性があるため、エージェントシステムでは特に重要です。
確認事項：
- サンドボックスがデータ漏洩や悪意のあるコードの実行の疑いがある場合、トリアージの責任者は誰か？
- サンドボックスは、プロジェクトまたは組織ごとに強制終了、隔離、またはブロックできるか？
- ネットワークエグレスは迅速に無効化できるか？
- ログとアーティファクトは調査のために保存されるか？
- 影響を受けたテンプレート、パッケージキャッシュ、およびスナップショットは無効化されるか？
- 認証情報は自動的に、または文書化されたランブックを通じてローテーションされるか？
- サンドボックス封じ込めの問題とエージェントポリシーの問題の間には、明確な区別があるか？
レビューは、文書化された脅威モデルと短いランブックで終了する必要があります。最終的な決定が「機密性の低いワークロードのみ承認」であっても、その境界は有用です。
Novita Agent Sandboxの位置づけ
Novita Agent Sandbox は、AI生成コード、ブラウザワークフロー、コンピュータ使用、評価、強化学習環境、および長時間実行タスク向けに設計されています。製品ページでは、分離されたサンドボックス、サブ秒の起動、永続セッション、VNCベースのライブセッションビュー、使用量ベースの価格設定、テンプレート、および分離されたファイルシステムのサポートについて説明されています。Novita Agent Sandbox クイックスタート では、SDKベースのサンドボックス作成、コマンド実行、ファイル一覧表示、およびサンドボックスシャットダウンを示しています。
これらの機能は、このチェックリストの多くのワークフローをサポートできますが、評価基準と製品の主張は分離しておく必要があります。あなたのチームがNovita Agent Sandbox、または他のエージェントランタイムをレビューする際は、使用を計画している実際の設定を上記の制御項目（境界、ファイル、プロセス制限、ネットワーク、DNS、パッケージフェッチ、シークレット、ログ、アーティファクト、ライフサイクル、承認、インシデント対応）にマッピングしてください。
すでにNovita AIモデルAPIを使用しているエンジニアリングチームにとって、モデル推論とサンドボックス実行を組み合わせることで、エージェントワークロードのプラットフォームの分散を減らすことができます。セキュリティ重視の本番使用の場合は、サンドボックスをプライベートリポジトリ、機密データセット、内部サービス、またはデプロイメント認証情報に接続する前に、必ずワークロード固有のレビューを実行してください。
結論
以下の3つの質問に明確に回答できる場合にのみ、AIエージェントサンドボックスを承認してください：何が分離されているか、何が依然として境界から出る可能性があるか、そして何か問題が発生した場合にどのような証拠が残るか。これらの回答が曖昧な場合は、不足している制御が文書化されテストされるまで、サンドボックスを機密性の低いワークロードに制限してください。
FAQ
セキュリティチームは、AIエージェントサンドボックスのレビューで最初に何を確認すべきですか？
実行境界、ファイルシステムの露出、およびネットワークのデフォルトから始めてください。これら3つの制御は、承認やアーティファクトエクスポートなどのワークフロー固有の詳細に入る前に、悪意のあるコードがホスト、機密ファイル、または外部の宛先に到達できるかどうかを決定します。
コンテナのみのサンドボックスは、自律型コーディングエージェントに十分ですか？
ワークロードとそれが到達できるデータによって異なります。コンテナは、厳格なマウント、厳格なエグレスポリシー、短命な認証情報、および強力なログ記録を備えた低機密性タスクには受け入れられる可能性がありますが、セキュリティチームは「コンテナ」という言葉だけからではなく、文書化された制御からその決定を下す必要があります。
DNSとパッケージアクセスは、一般的なエグレスとは別にレビューする必要があるのはなぜですか？
エージェントは、通常の操作の一部として依存関係をインストールし、外部ホストを解決することが多いためです。DNSクエリとパッケージフェッチは、ログ記録、フィルタリング、または制限がされていない場合、データ流出経路とサプライチェーンリスクの両方になる可能性があります。
おすすめ記事：
