サンドボックス化されたコードが攻撃者管理のドメインを解決したり、DNSを発信データチャネルとして使用できる場合、DNS exfiltrationリスクが重要になります。そのため、チームはAIエージェントサンドボックスを機密性の高いワークフローで信頼する前に、DNSポリシー、ログ、パッケージフェッチパス、インシデント証拠を評価する必要があります。
サンドボックスの脅威モデルにおいてDNSが重要な理由
AIエージェントサンドボックスは、有用な自律性のために構築されています。コーディングエージェントは、人間がすべてのコマンドを承認することなく、テストの実行、パッケージのインストール、APIの呼び出し、ブラウザの起動、ファイルの検査、アーティファクトの生成を行う可能性があります。その柔軟性こそが、ネットワーク動作をCPU、メモリ、ファイルシステム、プロセス分離とは別に独自のレビューを必要とする理由です。
DNSはHTTPエグレスほど注目されないことがよくあります。なぜなら、インフラストラクチャの配管のように見えるからです。アプリケーションはAPI、レジストリ、Webページ、更新エンドポイントに到達するために名前解決を必要とします。しかし、DNSは依然として発信通信です。任意のドメインを解決できるサンドボックスは、クエリ名を通じて情報を明らかにしたり、攻撃者管理のインフラに接触したり、DNSトラフィックがWebリクエストと同じ注意でログに記録されない場合に盲点を作り出したりする可能性があります。
これはAIエージェントのために発明された理論上のカテゴリではありません。MITRE ATT&CKは、DNSを敵対者がコマンド＆コントロール通信に使用できるアプリケーション層プロトコルとして文書化しており、データがメインのアプリケーションプロトコルではないチャネルを介して流出する場合の代替プロトコルを介したexfiltrationを別途文書化しています。サンドボックス評価者にとっての教訓は明白です。DNSがHTTP POSTではないからといって無害として扱わないでください。
AIエージェントの場合、リスクは通常、1つの明白なミスではなく、小さな権限の連鎖から生じます。
| サンドボックス機能 | チームが許可する理由 | DNS関連の質問 |
|---|---|---|
| パッケージインストール | エージェントに不足している依存関係をインストールさせる | どのレジストリとリゾルバパスが許可されているか？ |
| Webアクセス | ブラウザエージェントに公開コンテキストを収集させる | コードは任意のドメインを解決できるか、それとも承認されたドメインのみか？ |
| API呼び出し | エージェントにアプリバックエンドと統合させる | 内部ドメインとメタデータエンドポイントはブロックされているか？ |
| ビルドツール | コーディングエージェントに現実的なテストを実行させる | インストール後のスクリプトが予期しないルックアップをトリガーする可能性があるか？ |
| 長時間実行セッション | エージェントにマルチステップタスクを継続させる | DNSログはセッションの全ライフサイクルにわたって保持されるか？ |
目標はすべてのネットワーク呼び出しを禁止することではありません。多くのエージェントワークロードは制御されたネットワークアクセスを必要とします。目標は、どのパスが存在するか、どのパスがブロックされているか、タスクが予期しない動作をした場合にどのような証拠が得られるかを知ることです。
エージェントワークフローでDNS解決が発生する場所
セキュリティレビューでは、サンドボックスにインターネットアクセスがあるかどうかがよく尋ねられます。その質問は大雑把すぎます。より良いレビューは、コード、ツール、パッケージマネージャー、ブラウザが名前解決をトリガーする可能性のあるすべての場所をマッピングすることから始まります。
一般的なDNSパスは次のとおりです。
- Python、JavaScript、シェルスクリプト、SDK、テストスイートからの直接コードリクエスト。
- ページ、サブリソース、フォント、画像、アナリティクススクリプト、リダイレクトをロードするブラウザ自動化。
- npm、pip、uv、pnpm、apt、cargo、または言語固有のプラグインインストーラーなどのパッケージマネージャー。
- バイナリ、テンプレート、ブラウザドライバー、モデルファイル、テストフィクスチャをフェッチするビルドツール。
- サードパーティAPIやWebhookエンドポイントを呼び出すエージェントツール。
- 可視のエージェントステップが戻った後も実行を続けるバックグラウンドジョブ。
そのマッピングには、意図的なトラフィックと付随的なトラフィックの両方を含める必要があります。開発者はエージェントに単体テストの実行のみを依頼するかもしれませんが、テストコマンドがパッケージをインストールし、パッケージマネージャーがレジストリドメインを解決し、ライフサイクルスクリプトが別のホストに接続する可能性があります。ブラウザタスクは1つの公開サイトに限定されているかもしれませんが、埋め込まれたリソースは多くの追加ドメインを解決します。
サンドボックスプロバイダーにとって、最も強力な答えは「ネットワークアクセスが利用可能」または「ネットワークアクセスが分離されている」だけではありません。有用な答えは解決パスを説明します。
- サンドボックスDNSは、プロバイダー管理のリゾルバ、顧客管理のリゾルバ、VPCリゾルバ、パブリックリゾルバのいずれを使用しますか？
- 顧客はドメイン、IP範囲、ポート、プロトコルを制限できますか？
- DNSリクエストは、サンドボックスごと、セッションごと、コマンドごと、または集約されたネットワークレイヤーでのみログに記録されますか？
- 拒否されたルックアップはログに記録されますか、それとも許可されたルックアップのみですか？
- 顧客はパッケージフェッチDNSとランタイムDNSを分離できますか？
これらの詳細が利用できない場合は、サンドボックスが安全でないという証拠としてではなく、未解決の評価項目として扱ってください。実際のリスクは、ワークロードの機密性、サンドボックス内で利用可能なシークレット、発信ポリシー、およびフォレンジック証拠の質に依存します。
発信ポリシーの評価方法
発信ポリシーは、DNSが日常的な配管になるのか、それともレビューされていない脱出経路になるのかを決定する制御面です。成熟したポリシーは、何が許可されているのか、なぜ許可されているのか、例外はどのように承認されるのかという3つの質問に答える必要があります。
デフォルトの姿勢から始めましょう。信頼されていないAI生成コードに使用されるサンドボックスは、開発者用ラップトップと同じ広範なネットワークアクセスを継承すべきではありません。デフォルトがオープンエグレスの場合、製品がリスクの高いワークロードに対してそのアクセスを狭めることをサポートしているかどうかを尋ねてください。デフォルトが制限付きエグレスの場合、開発者がタスクに必要な正確なドメインをどのように有効にするかを尋ねてください。
次に、DNSポリシーとHTTPポリシーを分離します。一部のシステムはHTTP許可リストを強制しますが、名前解決は広範なままにします。これにより、不整合が生じる可能性があります。承認されていないホストへのリクエストはHTTPレイヤーで失敗する可能性がありますが、DNSクエリは依然として環境を離れ、クエリされた名前にメタデータを運ぶ可能性があります。より厳格な設計は、解決と接続の試行を一緒に評価します。
セキュリティレビューでは、次のようなポリシーマトリックスを使用します。
| 評価領域 | 何を尋ねるか | より強力な証拠 |
|---|---|---|
| デフォルトエグレス | 発信ネットワークアクセスはオープン、拒否、またはテンプレートによって範囲指定されているか？ | 文書化されたデフォルトポリシーとサンドボックスレベルのテスト結果 |
| DNSリゾルバパス | どのリゾルバがサンドボックスDNSを処理するか？ | アーキテクチャ図または構成証明 |
| ドメイン許可リスト | チームは承認されたレジストリとAPIのみを許可できるか？ | 構成例と拒否ログ例 |
| IPおよびプライベートネットワークブロック | 内部範囲とメタデータサービスはデフォルトでブロックされるか？ | 文書化された拒否ルールとテスト証拠 |
| プロトコル制御 | DNS、HTTP、HTTPS、rawソケットは個別に制御されているか？ | マーケティング文言だけでなく、ポリシーモデル |
| 例外ワークフロー | 誰がドメインを追加したりポリシーを緩和したりできるか？ | ロールベースの承認と監査記録 |
ほとんどのチームにとって、最初の実用的な目標は完全なゼロエグレス環境ではありません。それは文書化された最小エグレスプロファイルです。承認されたパッケージレジストリ、承認されたAPIドメイン、明示的にルーティングされない限り内部ネットワークへのアクセスなし、許可された試行と拒否された試行の両方のログ。
パッケージフェッチと依存関係駆動型DNS
パッケージインストールは、サンドボックスエグレスを過小評価する最も簡単な方法の1つです。エージェント生成コードは、欠落している依存関係で失敗することが多く、最速の開発者エクスペリエンスはエージェントが必要なものをインストールさせることです。この利便性により、2番目のサプライチェーンの問題が発生します。パッケージ名、レジストリリダイレクト、インストールスクリプト、バイナリダウンロードにより、元のプロンプトで言及されなかったDNSおよびネットワークアクティビティがトリガーされる可能性があります。
OWASPのLLMアプリケーションガイダンスは、過度なエージェンシーとサプライチェーンへの露出に関するリスクを指摘しています。エージェントサンドボックスでは、これらのリスクはパッケージインストールで出会います。モデルはコマンドを選択できる場合があります。コマンドはパッケージマネージャーを呼び出す場合があります。パッケージマネージャーはレジストリからコードをフェッチする場合があります。フェッチされたパッケージはインストールフックを実行する場合があります。各ステップでDNSルックアップと発信接続が作成される可能性があります。
防御的な評価は、エクスプロイトの仕組みではなく、ガバナンスに焦点を当てるべきです。
- 反復可能なエージェントタスクには、固定された依存関係ファイルを優先します。
- 一般的なエコシステムには、承認されたレジストリまたはプルスルーキャッシュを使用します。
- 可能な場合は、パッケージ名、バージョン、レジストリURL、解決されたドメイン、アーティファクトハッシュをログに記録します。
- パッケージインストール権限を一般的なランタイムインターネットアクセスから分離します。
- 機密性の高いワークスペースでは、許可リスト外のパッケージをインストールする前に承認を要求します。
- エージェントが実行のたびに広範なネットワークアクセスを必要としないように、一般的なスタック用のプリビルドサンドボックステンプレートを検討します。
重要な区別は、「パッケージフェッチ」は1つの制御ではないということです。これには、DNS解決、レジストリ認証、アーティファクトのダウンロード、インストール時のコード実行、キャッシュ動作が含まれます。適切なサンドボックスレビューは、パス全体について尋ねます。
シークレットとデータ露出の前提
DNS exfiltrationは、漏洩する価値のある意味のあるものがある場合にのみ重要です。そのため、シークレットの配置とデータのスコーピングはDNSレビューの一部です。
AIエージェントサンドボックスは、そうでないことが証明されない限り、信頼されていないビルドワーカーのように扱われるべきです。サンドボックスがホストから分離されているという理由だけで、長期有効な本番認証情報、広範なクラウドトークン、顧客データ、内部ソースコードをサンドボックスに配置しないでください。分離は爆発半径を減らしますが、すべてのコマンドを安全にするわけではありません。
リスクの高いワークフローを設計するときは、次の前提を使用します。
- エージェント実行コードが読み取り可能なファイルは、ログ、出力、ネットワークリクエスト、エラーメッセージに含まれる可能性があります。
- プロセスに表示可能な環境変数は、そのプロセスによってコピーされる可能性があります。
- サンドボックスに許可された発信チャネルは、DNSを含め、同じデータ損失レビューに値します。
- ブラウザまたはドキュメントワークフローでのプロンプトインジェクション命令は、ツールの使用に影響を与えようとする可能性があります。
- 長時間実行セッションは、ライフサイクルログとトークンの有効期限の価値を高めます。
実用的な制御には、短命な認証情報、最小権限のAPIキー、スコープ指定されたサービスアカウント、タスクごとのシークレット、編集されたログ、公開データ調査タスクと機密コード実行タスクの明示的な分離が含まれます。
ログ、監査証跡、インシデント証拠
DNS制御は、チームがそれらを検証できる場合にのみ有用です。サンドボックスタスクが疑わしい場合、セキュリティチームは迅速に証拠を必要とします。何が実行されたか、何が解決されたか、何が接続されたか、どのファイルが変更されたか、どの出力が返されたか。
少なくとも、プラットフォームが特定のサンドボックスセッションに対してこれらのイベントを再構築できるかどうかを尋ねてください。
- サンドボックス作成時間、テンプレート、リソース構成、所有者。
- エージェントまたはユーザーによって実行されたコマンド。
- 製品がファイル操作を公開する場合に読み取り、書き込み、アップロード、ダウンロードされたファイル。
- パッケージのインストールとレジストリフェッチ。
- DNSクエリ（タイムスタンプ、クエリされた名前、結果、サンドボックス/セッション識別子を含む）。
- 発信接続の試行（宛先ホスト、IP、ポート、プロトコル、許可/拒否の結果、可能な場合はボリュームを含む）。
- ツール呼び出し、ブラウザナビゲーションイベント、バックグラウンドプロセス。
- シークレット値をログに公開せずにシークレットインジェクションイベント。
- セッション終了、一時停止、再開、スナップショット、クリーンアップイベント。
成功したトラフィックのログだけを求めないでください。拒否されたイベントは、ポリシーが機能したかどうかを評価するためにより有用であることがよくあります。サンドボックスが未承認のドメインを解決しようとし、ポリシーがそれをブロックした場合、その拒否されたルックアップは、機能する制御とサイレント障害を区別する証拠です。
保持も重要です。7日間のログウィンドウはデバッグには十分かもしれませんが、インシデント対応には不十分です。規制対象または顧客の機密性の高いワークロードを持つチームは、サンドボックステレメトリの保持を、より広範なセキュリティログポリシーと整合させる必要があります。
Novita Agent Sandbox 評価ノート
Novita Agent Sandbox は、分離されたコード実行、ブラウザ自動化、コンピュータ使用スタイルのタスク、長時間実行セッション、評価または強化学習ワークロードを必要とするAIエージェントワークフロー向けに設計されています。Novita Agent Sandbox の概要 は、現在の製品動作を理解するための適切な出発点であり、Agent Sandbox 製品ページ は、より広範なプラットフォームの適合性を説明しています。
DNSに敏感なワークロードについてNovitaまたは他のサンドボックスプロバイダーを評価する場合、2種類のステートメントを分離してください。
- 製品適合性：サンドボックスが必要なエージェントワークフロー（コード実行、ブラウザ自動化、長時間実行タスクなど）をサポートしているかどうか。
- セキュリティ制御の証拠：正確なDNS、エグレス、パッケージフェッチ、シークレット、ログの制御が内部ポリシーを満たしているかどうか。
この分離により、過大評価を防ぎます。サンドボックスはエージェント実行に強く適合していても、DNSポリシー、リゾルバパス、許可リスト、監査保持、インシデントワークフローについて特定の顧客レビューが必要な場合があります。セキュリティチームは、機密性の高いワークロードを承認する前に、これらの制御の詳細について最新のドキュメントまたは製品の確認を求める必要があります。
すでにNovita AIモデルを使用しているチームにとって、プラットフォームの適合性は、モデルAPIとエージェント実行インフラストラクチャを一緒に評価できることです。これにより、運用の分散を減らすことができますが、脅威モデルの必要性がなくなるわけではありません。サンドボックスを制御された実行環境として扱い、各エージェントクラスが必要とするネットワークアクセスを定義し、制御の証拠が内部に配置されたデータのリスクと一致することを検証します。
セキュリティレビューチェックリスト
機密性の高いコード、認証情報、顧客データ、内部システムに触れる可能性のあるAIエージェントサンドボックスワークロードを承認する前に、このチェックリストを使用してください。
| レビュー質問 | なぜ重要か |
|---|---|
| サンドボックスはデフォルトで何を解決できるか？ | DNSはHTTPがブロックされていても発信信号になり得る。 |
| DNSはドメイン、テンプレート、ワークスペース、VPCポリシーによって制限できるか？ | 機密性の高いワークフローには、公開調査タスクよりも狭いデフォルトが必要。 |
| DNSクエリはサンドボックスセッションごとにログに記録されるか？ | インシデント対応には、集約されたリゾルバメトリックだけでなく、属性が必要。 |
| 拒否されたDNSおよび接続試行はログに記録されるか？ | 拒否されたイベントは、ポリシーが予期しない動作をブロックしたことを証明する。 |
| パッケージレジストリは許可リスト化またはプロキシされているか？ | パッケージマネージャーは依存関係駆動型のDNSおよびダウンロードをトリガーする可能性がある。 |
| パッケージインストールをランタイムネットワークアクセスから分離できるか？ | ビルド時と実行時のリスクは異なる。 |
| 内部IP範囲とメタデータエンドポイントはブロックされているか？ | エージェントは誤ってインフラストラクチャコントロールプレーンを発見したり接触したりするべきではない。 |
| シークレットはどのように注入、スコープ指定、ローテーション、編集されるか？ | 長期有効なシークレットがサンドボックスコードに利用可能な場合、DNSレビューは不完全。 |
| ブラウザのサブリソースはログに表示されるか？ | ブラウザエージェントはトップレベルURLよりも多くのドメインを解決する可能性がある。 |
| 一時停止、再開、スナップショット、クリーンアップ後にどのような証拠が利用可能か？ | 長時間実行セッションにはライフサイクル認識テレメトリが必要。 |
| 誰がエグレスポリシーを緩和できるか？ | 例外の変更は監査可能であるべき。 |
| 疑わしいセッションはどのように保存されるか？ | クリーンアップは唯一の有用なインシデント証拠を消去すべきではない。 |
いくつかの回答が不明な場合は、プロバイダーまたは内部プラットフォームチームが制御パスを文書化できるまで、ワークロードをサンドボックスから遠ざけてください。ワークロードが公開データのみを処理し、シークレットを使用しない場合、同じギャップは初期プロトタイピング中は許容されるかもしれませんが、本番使用前に追跡する必要があります。
結論
本番エージェントサンドボックスの場合、DNSをエグレスの一部としてレビューし、脚注として扱わないでください。最小限の防御可能なセットアップは、スコープ指定された発信ポリシー、明示的なパッケージフェッチガバナンス、短命なシークレット、セッションごとのDNSおよび接続ログ、および証拠を保存するためのテスト済みインシデントワークフローです。
データが非機密であり、エージェントに意味のあるシークレットがない場合にのみ、リスクの低いプロトタイプに広範なネットワークアクセスを使用してください。機密性の高いコードベース、顧客データ、内部API、または規制対象のワークフローの場合、エージェントに自律的な実行を許可する前に、最小エグレスプロファイルと最新のプロバイダー証拠を要求してください。
よくある質問
DNS Exfiltration はサンドボックスが HTTP をブロックしている場合でも関連しますか？
はい。HTTP制御とDNS制御は異なるレイヤーです。サンドボックスは発信Webリクエストをブロックしながら、DNSクエリを許可する場合があります。セキュリティチームは、解決ポリシーと接続ポリシーの両方を検証する必要があります。
AIエージェントサンドボックスはインターネットアクセスがないほうがよいですか？
常にそうとは限りません。多くの有用なエージェントタスクは、パッケージレジストリ、公開ドキュメント、API、ブラウザアクセスを必要とします。より安全な目標は、最小限で説明可能なエグレスです。タスクに必要なものを許可し、不要なものを拒否し、許可されたアクティビティと拒否されたアクティビティの両方をログに記録します。
パッケージインストールは一般的なネットワークアクセスと同じですか？
いいえ。パッケージインストールは、レジストリ、依存関係解決、アーティファクトのダウンロード、場合によってはインストール時のスクリプトが含まれるため、別のポリシーが必要です。チームは、承認されたキャッシュを介したパッケージフェッチを許可しながら、任意のランタイムエグレスを拒否する場合があります。
DNSリスクにとって最も重要なログは何ですか？
最も有用なログは、DNSクエリを特定のサンドボックス、コマンド、時間、ユーザーまたはエージェントワークフロー、ポリシー決定に結び付けます。拒否されたルックアップログは、制御が実際に機能したかどうかを示すため、特に重要です。
サンドボックスプロバイダーはデータ exfiltration がないことを保証できますか？
絶対的な保証には注意してください。プロバイダーは分離、ネットワーク制御、ログ、構成オプションを提供できますが、最終的なリスクはワークロードの設計、シークレット、データ配置、発信ポリシー、運用監視に依存します。
