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