AIコード実行サンドボックスのセキュリティは、その分離境界に依存します。しかし、分離境界は答えの一部に過ぎません。より適切な問いは、サンドボックスが実際に何を分離し、何がまだ外部に漏洩し得るのか、ということです。ほとんどのサンドボックスは、ある種の脅威（プロセスレベルのコード実行、ホストへの任意のファイルシステム書き込み）を適切に防ぎますが、他の脅威（アウトバウンドネットワーク、パッケージインストール、環境変数内のシークレット）はデフォルトで開放したままにします。これらのギャップを理解することが、サンドボックスが自身のリスクモデルに適合するかを評価する方法です。
コード実行サンドボックスにとって「安全」とは何か
コード実行サンドボックスにおけるセキュリティは、二値的な性質ではありません。それは一連の制御であり、それぞれが特定のリスクカテゴリに対処します。「このサンドボックスは安全ですか？」と尋ねる人は、通常、いくつかの異なる質問を同時に問うています。
- ホスト分離: サンドボックス内部で実行されるコードがホストシステムに脱出できるか？
- テナント分離: あるユーザーのコードが別のユーザーのセッションに影響を与えることができるか？
- Egress制御: サンドボックス内のコードがインターネット、内部サービス、またはメタデータエンドポイントに到達できるか？
- シークレットのスコープ設定: 認証情報が必要以上にサンドボックスの広い範囲にアクセス可能になっていないか？
- サプライチェーンリスク: パッケージインストールが予期せぬコードや悪意のあるコードを持ち込む可能性はあるか？
- 監査可能性: エージェントが実際に行ったことを事後的に再構築できるか？
サンドボックスは、ホスト分離には強くてもEgressには弱い場合があります。Egressには強くてもシークレットには弱い場合もあります。「どの程度安全か」を評価するには、各次元を個別に確認する必要があり、「コンテナ化」や「マイクロVMベース」といった単一のラベルを全体の答えとして受け入れてはいけません。
分離モデルの比較
AIコード実行サンドボックスで使用される主な分離モデルは3つあります。それぞれが異なる境界を提供します。
プロセス分離
プロセス分離は、OSレベルのプリミティブ（Linux名前空間、cgroups、seccompフィルター、AppArmorまたはSELinuxプロファイル）を使用して、プロセスがアクセスできるものを制限します。サンドボックスはホストOS上でプロセスとして実行され、ホストカーネルを共有します。
防止できるもの: 広範なファイルシステム、サンドボックス外の他のプロセス、およびseccompポリシーによって明示的にブロックされたシステムコールへのアクセス。
防止できないもの: 共有された脆弱性を悪用して権限を昇格させるカーネルエクスプロイト。seccompバイパスやカーネルの脆弱性は、ホスト境界を越える可能性があります。
適しているケース: 短命で、低リスクで、比較的信頼できるコードであり、起動速度と移植性がハードなVM境界よりも重要視される場合。外部ユーザーからの任意のエージェント生成コードを実行する場合には推奨されません。
コンテナ分離（Docker/名前空間）
コンテナ分離は、プロセス分離をより構造化されたイメージモデル、ネットワーク名前空間、ボリュームマウントで拡張します。ほとんどのDockerベースのサンドボックス実装は、最小限のイメージと制限されたseccompプロファイルを使用してコンテナ内でコードを実行します。
防止できるもの: ホストへの直接的なファイルシステムアクセス、適切に設定された場合の隣接コンテナへのほとんどのネットワークアクセス、ホストプロセスへの容易なアクセス。
防止できないもの: カーネルレベルのエクスプロイトは依然として有効です — コンテナはホストカーネルを共有します。誤って設定されたボリュームマウント、過度に広範なseccompプロファイル、--privileged モード、露出したDockerソケットはすべて、意図された境界を無効化する可能性があります。
適しているケース: 多くの本番環境では、seccompプロファイルが厳格で、イメージが最小限で、Egressが制限され、特権アクセスが付与されていない場合に、AIコード実行のためにコンテナを効果的に使用しています。リスクモデルはマイクロVMとは異なりますが、注意深い設定で管理可能です。
マイクロVM分離（Firecracker/gVisor）
マイクロVM分離は、各サンドボックスを独自のゲストカーネルを持つ軽量な仮想マシンで実行し、KVMハイパーバイザー境界によってホストから分離します。Firecrackerが最も一般的な実装であり、gVisor（ユーザー空間カーネルを使用）は異なるトレードオフを提供します。
防止できるもの: ゲストカーネルのエクスプロイトは、ホストカーネルや他のゲストに伝播しません。ホストの攻撃対象領域は、最小限になるように設計されたVMM（仮想マシンモニター）に縮減されます。
防止できないもの: VMM自体の脆弱性（まれですが不可能ではありません）。ネットワーク、パッケージ、シークレットの制御は依然としてVM境界の外側にあります — マイクロVM分離はこれらを処理しません。
適しているケース: 外部ユーザーからの信頼できないコードやエージェント生成コードの実行、ブラスト半径が重要なマルチテナント環境、任意のシェルコマンドやパッケージインストールスクリプトを実行する可能性のあるワークロード。
| 分離モデル | ホストカーネル共有 | テナント分離 | 起動オーバーヘッド | ホスト脱出リスク |
|---|---|---|---|---|
| プロセス | はい | 弱い | 最も低い | 最も高い |
| コンテナ | はい | 中程度 | 低い | 中程度（設定依存） |
| マイクロVM | いいえ | 強い | 中程度 | 低い |
各境界からまだ漏洩し得るもの
分離モデルはランタイムコード実行に対処します。他の経路を通じてサンドボックスに出入りするものを自動的に対処するわけではありません。
アウトバウンドネットワーク: 3つの分離モデルすべてにおいて、アウトバウンドネットワークアクセスはポリシー設定に委ねられます。デフォルトでEgressが開放されている場合、サンドボックス内のコードはパブリックインターネット、クラウドメタデータエンドポイント（AWSおよびGCPの 169.254.169.254）、同一ネットワーク上の内部サービス、および任意の外部APIに到達できます。これは、分離モデルに関係なく、データ流出経路、シークレット取得経路、およびC2（コマンド&コントロール）経路となります。
パッケージインストール: apt install、pip install、または npm install は、外部レジストリからコードを取得して実行します。サンドボックスがパッケージインストールを許可し、Egressが開放されている場合、パッケージ名の衝突、タイポスクワッティング攻撃、または依存関係混乱攻撃により、悪意のあるコードがサンドボックスのすべての権限で実行される可能性があります。分離境界はブラスト半径を封じ込めますが、インストール自体を防ぐわけではありません。
共有状態: マルチテナント環境では、共有キャッシュ、共有パッケージレジストリ、共有テンプレートイメージ、または共有ファイルシステムマウントが、分離境界を迂回してテナント間のチャネルを作成します。
環境変数内のシークレット: エージェントプロセスから見える環境変数は、エージェントが実行する任意のコードから読み取り可能です。データベースの認証情報やAPIキーが環境内にある場合、それはサンドボックスおよびその実行またはインストールするすべてのものからアクセス可能です。
Egressおよびネットワーク制御
Egressは、ほとんどのサンドボックスで最大のギャップがある領域です。アウトバウンドインターネットアクセスが開放されていることは一般的です。なぜなら、エージェントがパッケージをインストールしたり、APIを呼び出したり、リソースを取得したりするのに便利だからです。しかし、これにはリスクも伴います。
クラウドメタデータエンドポイント: ホスト型クラウドインフラストラクチャでは、169.254.169.254（およびそのIPv6相当）がインスタンスメタデータ（IAM認証情報を含む）を提供します。Egressが開放されたサンドボックス内のコードは、このエンドポイントに到達し、基盤となるホストの認証情報を取得できます。
DNSベースのデータ流出: HTTPがブロックされていても、アウトバウンドDNSクエリは、ドメインルックアップにデータをエンコードすることでデータの流出に使用される可能性があります。DNSブロッキングには、外部サーバーへのTCP/UDP 53をブロックするだけでなく、リゾルバーレベルでのフィルタリングが必要です。
内部サービス: サンドボックスがプライベートネットワークセグメント上で実行されている場合、Egressが開放されていると、エージェントコードから到達可能であることを意図していない内部データベース、管理パネル、APIへのアクセスが許可される可能性があります。
評価すべき制御項目：
| 制御 | 防止できるもの | 確認すべき点 |
|---|---|---|
| デフォルト拒否Egress | リスト外の宛先へのアウトバウンド接続 | DNSもTCP/UDPと同様にブロックするか？ |
| 許可リストベースEgress | 非承認ドメインへの接続 | 許可リストは顧客が設定可能か？ |
| メタデータエンドポイントブロッキング | 169.254.169.254 経由のクラウド認証情報取得 |
IPv6メタデータもブロックされているか？ |
| Egressプロキシ | 全アウトバウンドトラフィックのロギングと検査 | プロキシログはアクセス可能か？ |
| DNSフィルタリング | DNSベースのデータ流出と内部名前解決 | サンドボックス内部でどのリゾルバーが使用されているか？ |
普遍的に正しいEgressポリシーは存在しません。一部のエージェントワークロードは、有用であるために広範なインターネットアクセスを本当に必要とします。重要なのは、ポリシーが意図的かつ監査可能であり、設定されたことがないためにデフォルトで開放されたままになっていないことです。
シークレット管理
AIエージェントサンドボックスにおけるシークレットは、あらゆるソフトウェアシステムにおけるシークレットと同じ原則に従いますが、追加の制約が1つあります：エージェントは、開発者の意図なしに環境を読み取り、ログに記録し、または送信するコードを実行する可能性があります。
スコープ設定: サンドボックスが現在のタスクに実際に必要とする認証情報のみをマウントします。コーディングタスクを実行するサンドボックスに、本番データベースの認証情報は必要ありません。モデル出力を評価するサンドボックスに、課金サービスのAPIキーは必要ありません。
有効期間: 短期間の認証情報は、長期間のものよりも大幅に安全です。サンドボックス内で認証情報が漏洩した場合、短いTTLは露出の期間を制限します。多くのクラウドIAMシステムは、数分または数時間で期限切れになる短期トークンをサポートしています。
注入方法: 環境変数は最も一般的な注入方法であり、プロセス内の任意のコードが最もアクセスしやすい方法です。ファイルシステムマウントを介して注入されるシークレット、エージェントが通過する必要のないパスにマウントされるシークレット、または特定のツールが実行を必要とする場合にのみ動的に取得されるシークレットは、包括的な環境変数セットよりも制約が強くなります。
墨消し: シークレットは、stdout、stderr、ツール応答ペイロード、モデル可視コンテキスト、および監査ログから墨消しされるべきです。自身の環境をエコーしたり、env を呼び出したり、失敗したAPI呼び出しにトークンを渡したりするエージェントは、認証情報をログに漏洩させ、その後保存されたり、オペレーターから見えたりする可能性があります。
リソース制限とDoSリスク
リソース制限のないサンドボックスは、暴走コード、無限ループ、インストールされたパッケージのメモリリーク、または隣接するワークロードを意図的に妨害しようとする試みを通じて、CPU、メモリ、ディスク、またはネットワーク帯域幅を枯渇させるエージェントワークロードに対して脆弱です。
確認すべきリソース制御：
- CPU制限: セッションごとのスロットリングまたはハード制限により、1つのセッションがホスト容量を占有することを防ぎます。
- メモリ制限: OOM強制終了ポリシーは、ホストプロセスではなくサンドボックスセッションを終了する必要があります。
- ディスククォータ: セッションごとの書き込み制限により、セッションが共有ストレージを満たすことを防ぎます。
- 実行タイムアウト: ウォールクロック制限を超えたセッションは、クリーンに終了され、実行されたままになってはいけません。
- ネットワークレート制限: アウトバウンド帯域幅の制限は、Egressポリシーが宛先を許可している場合でも、データ流出を抑制できます。
- 同時プロセス制限: 過剰にフォークしたり、バックグラウンドプロセスを生成したりするエージェントは、プロセステーブルスロットを枯渇させる可能性があります。
リソース制限違反もログに記録する価値があります。軽量であるべきタスク中に一貫してCPUスロットルやOOM強制終了に達するセッションは、調査に値するシグナルです。
監査の可視性
分離制御は、何か問題が発生した場合のブラスト半径を減らします。監査ログは、問題が発生したことを発見し、何が起こったかを再構築する方法です。
特にAIエージェントサンドボックスにとって有用な監査範囲には以下が含まれます：
- プロセス実行: 実行されたすべてのコマンド（完全な引数リスト、UID、親プロセスを含む）。引数リストがなければ、ログ内の
curlやpythonは意味をなしません。 - ファイルシステムアクセス: 機密パスへの読み取りおよび書き込み。ほとんどの脅威モデルでは、読み取りよりも書き込みと削除が優先度が高くなります。
- アウトバウンドネットワーク: 宛先、プロトコル、DNSクエリ、転送バイト数。DNSクエリのロギングはしばしば欠落していますが、重要です。
- パッケージインストール: パッケージマネージャー、パッケージ名、バージョン、ソースレジストリ、ハッシュ。
- セッションライフサイクル: 作成、一時停止、再開、終了、およびクリーンアップイベント（理由コード付き）。
- リソース制限イベント: OOM強制終了、CPUスロットル、タイムアウト終了。
収集メカニズムは、範囲と同じくらい重要です。サンドボックスプロセス内部で生成されたログは、十分な権限を持つエージェントによって抑制または変更される可能性があります。カーネルレベルの収集（auditd、eBPF、またはハイパーバイザー計装を介する）は、アプリケーション層の下で生成され、エージェントは書き込みアクセスを持ちません。
サンドボックスプロバイダーまたはプロジェクトに問うべき質問
管理サンドボックスサービスまたはオープンソースサンドボックスフレームワークを評価する際には、このチェックリストを使用してください：
分離
- 各エージェントセッションは独自の分離環境を取得しますか、それともセッションは共有実行環境でグループ化されますか？
- 使用されている分離モデルは、プロセス、コンテナ、マイクロVMのうちどれですか？
- ゲストカーネルはホストと共有されていますか？
ネットワークとEgress
- Egressはデフォルトで開放されていますか、それともデフォルトで拒否されますか？
- Egressポリシーはテナントまたはセッションごとに設定できますか？
- クラウドメタデータエンドポイント（
169.254.169.254）はブロックされていますか？ - サンドボックス内部でDNSはどのように処理されますか？
パッケージインストール
- パッケージインストールはデフォルトで許可されていますか？
- インストールは承認されたレジストリに制限できますか？
- インストールイベントはソースとハッシュとともにログに記録されますか？
シークレット
- 認証情報はサンドボックスにどのように注入されますか？
- 認証情報は、それらを必要とする特定のツールまたはタスクにスコープできますか？
- シークレットはログおよびモデル可視出力から墨消しされますか？
リソース制限
- CPU、メモリ、ディスク、タイムアウトの制限は実施されていますか？
- 制限に達した場合、何が起こりますか — スロットル、強制終了、またはアラート？
監査ログ
- ログはカーネル/ハイパーバイザーレベルで生成されますか、それともサンドボックスプロセス内部で生成されますか？
- デフォルトでログに記録されるイベントカテゴリは何ですか？
- ログは外部のSIEMまたはログ集約システムにエクスポートできますか？
- ログ保持ポリシーは何ですか？
テナント管理
- 異なるテナントからのワークロードは互いに分離されていますか？
- テナント間のチャネルを作成する共有キャッシュ、イメージ、またはマウントはありますか？
Novita Agent Sandboxの位置づけ
Novita Agent Sandbox は、コード、ファイル、プロセス、および長期実行セッションのための分離実行環境を必要とするエージェントワークロード向けに設計されています。コーディングエージェント、評価パイプライン、データ分析エージェント、ブラウザベースのエージェントワークフローを構築するチームを対象としています。
このサンドボックスは、アイドルセッションのための一時停止、再開、自動一時停止を含むセッションライフサイクル制御をサポートしています。APIを通じてアクセス可能なリソースメトリクスとセッションレベルの実行ログを提供します。すでにNovitaモデルAPIを使用しているチームにとっては、モデルが計画しツールを呼び出し、サンドボックスが分離環境でランタイム実行を処理するエージェントアーキテクチャにおける実行層として機能します。
セキュリティ重視のユースケースでNovita Agent Sandboxを評価する場合は、アーキテクチャ上の決定を下す前に、製品ドキュメントで現在の分離モデル、Egressポリシーのデフォルト、ログ範囲、およびシークレット処理を確認してください。セキュリティ要件はワークロードによって大きく異なります。内部評価パイプラインに適したものが、ユーザー提供コードを処理するマルチテナント製品には十分でない場合があります。
他のサンドボックスと同様に、セキュリティ態勢はプラットフォームのデフォルトとアプリケーションレベルの制御（認証情報のスコープ設定方法、エージェントが要求を許可される内容、人間の承認が必要なツール呼び出し、監査ログの監視方法）の両方に依存します。
制限事項とサンドボックスが排除できないもの
どのサンドボックスもすべてのリスクを排除するわけではありません。境界の外側に何が残るかを理解することは、境界が提供するものを理解することと同じくらい重要です。
アプリケーション層の信頼決定: サンドボックスはランタイム実行を制御します。エージェントが何を要求することを許可されるかを決定するわけではありません。アプリケーションがエージェントに認証情報の要求、任意のシェルコマンドの実行、または任意のAPIの呼び出しを許可する場合、サンドボックスはブラスト半径を減らしますが、これらのアクションを防ぐわけではありません。
プロンプトインジェクション: 信頼できないコンテンツ（Webページ、ユーザーアップロードファイル、外部API応答）を処理するエージェントは、そのコンテンツを通じて操作され、行うべきでないアクションを実行する可能性があります。これはアプリケーション設計の問題であり、サンドボックスの問題ではありません。サンドボックスはそれらのアクションの着地点を制限できますが、決定ロジックはアプリケーションに存在します。
ゼロデイ脆弱性: すべての分離モデルには既知および未知の脆弱性があります。マイクロVM分離は現在の本番使用において最も強力な境界を提供しますが、VMMの脆弱性は存在します。多層防御（単一の境界を信頼するのではなく、複数の制御を組み合わせる）は、単一の分離モデルよりも堅牢な姿勢です。
モデル出力によるソーシャルエンジニアリング: エージェントは、人間のオペレーターに安全でないアクションを取るよう説得する出力を生成する可能性があります。サンドボックスは人間の決定を監査しません。
コンプライアンスおよび規制リスク: 分離制御は技術的リスクに対処します。規制要件（GDPR、HIPAA、SOC 2、ISO 27001）は、サンドボックスがインフラストラクチャレベルで提供するものを超えるデータ処理、保持、文書化、および監査要件に対処します。
コード実行サンドボックスにおけるセキュリティは、製品を選択することで得られるプロパティではなく、評価および設定するための一連の制御として捉えるのが最善です。上記の評価質問は、あらゆるサンドボックスの決定（購入ではなく構築している場合の自身のインフラストラクチャを含む）に適用されます。
よくある質問
サンドボックス化されたAIコード実行環境は、サーバー上でコードを実行する場合と比較してどの程度安全ですか？
適切に構成されたサンドボックスは、サーバー上で直接実行する場合と比較して、信頼できないコードを実行する際のブラスト半径を大幅に削減します。ファイルシステムアクセス、プロセススコープ、ネットワークアクセスを制限します。ただし、その差は構成に依存します。Egressが開放され、広範な環境変数が注入されたコンテナは、ネットワーク制御が施された堅牢化サーバーよりも安全性が低い場合があります。分離モデルは出発点であり、保証ではありません。
マイクロVM分離はサンドボックスが完全に安全であることを意味しますか？
いいえ。マイクロVM分離（Firecracker、KVMベース）は、カーネルを共有するコンテナにはない強力なホスト境界を提供します。しかし、Egress、シークレット、パッケージインストール、監査範囲を制御するわけではありません。Egressが開放されログ収集がないマイクロVMは、分離層が強力であっても「完全に安全」ではありません。
AI生成コードはサンドボックスから脱出できますか？
分離モデルと構成に依存します。コンテナの脱出にはカーネルまたは設定ミスの悪用が必要です。マイクロVMの脱出にはVMMの悪用が必要です。どちらも可能ですが、一般的ではありません。より現実的なリスクは、許可されたネットワーク経路を通じたデータ流出、環境からのシークレットの読み取り、または無制限のパッケージマネージャーを介した悪意のあるパッケージのインストールです。
ほとんどのAIコードサンドボックスにおける最大のセキュリティリスクは何ですか？
アウトバウンドEgressが開放されていることは、最も一般的に対処が不十分なリスクです。多くのサンドボックスは、パッケージのインストールやAPIの呼び出しが必要なエージェントにとって便利であるため、デフォルトで無制限のアウトバウンドインターネットアクセスを許可しています。これにより、分離境界の強力さに関係なく存在する、データ流出、クラウドメタデータエンドポイントを介した認証情報の窃取、およびC2通信の経路が作成されます。
管理サンドボックスを使用すべきですか、それとも独自に構築すべきですか？
管理サンドボックスは、マイクロVMまたはコンテナのライフサイクル、ホスト容量、イメージ管理の運用上の複雑さを処理します。独自に構築すると、全ポリシースタックをより細かく制御できます。どちらの場合でも、同じ評価質問が適用されます：Egressポリシー、シークレット処理、ログ範囲、リソース制限、監査エクスポート。構築か購入かの決定は、セキュリティ評価とは別の問題です。
エージェントサンドボックスのセキュリティは、従来のコード実行セキュリティと何が異なりますか？
従来のコード実行セキュリティは、どのようなコードが実行されるかをおおよそ把握していることを前提としています。AIエージェントはこれを変えます：単一のプロンプトが、セッションにパッケージのインストール、ファイルの書き込み、シェルコマンドの実行、外部APIの呼び出し、サブプロセスの生成を、各ステップに対する明示的な開発者の承認なしに引き起こす可能性があります。これにより、監査範囲（すべてのアクションを予測できない）、Egress制御（エージェントが予期しない宛先に到達する可能性がある）、シークレットのスコープ設定（エージェントは環境内のすべてにアクセスできる）がより重要になります。
