Firecrackerは、特定のAIエージェントサンドボックスワークロードにおいて、特に生成されたコード、パッケージインストール、サブプロセス、テナント分離において、共有カーネルのコンテナよりも強力な境界が必要な場合に、分離性を強化できます。しかし、それ自体が完全なサンドボックス戦略というわけではありません。Firecrackerを適切な分離境界と見なす前に、チームはワークロード適合性、起動およびライフサイクルのオーバーヘッド、言語やツールの互換性、ファイルシステムポリシー、ネットワークとパッケージの制御、シークレットの取り扱い、可観測性、そして周辺のアプリケーション制御を評価する必要があります。
Firecrackerがエージェントサンドボックスにもたらす変化
AIエージェントサンドボックスは、通常のステートレスなリクエストハンドラではありません。有用なコーディングエージェント、データ分析エージェント、ブラウザエージェント、評価ランナーは、ファイルを作成し、シェルコマンドを実行し、依存関係をインストールし、バックグラウンドプロセスを開始し、Webリソースを取得し、複数のステップにわたって状態を保持する必要があります。そのため、サンドボックスは生産性のレイヤーであると同時にセキュリティの境界でもあります。
Firecrackerは、軽量マイクロVM向けの仮想マシンモニターです。Linux KVMと意図的に小さなデバイスモデルを利用しており、各ワークロードは通常のコンテナ境界よりもVM境界に近いゲスト環境内で実行されます。また、FirecrackerはvCPUやメモリ構成、virtioブロック/ネットワークデバイス、レートリミッター、seccompフィルタリング、cgroups、名前空間、そして多層防御のためのjailerプロセスなどの構成要素を提供します。
エージェントシステムにとっての実質的な違いは次のとおりです。マイクロVMは、各エージェントの実行、テナント、またはツールグループに、独自のゲストカーネルとVM境界を与えることができます。これにより、生成されたコードが不正に動作した場合、パッケージインストールが予期しないコードを引き込んだ場合、またはエージェントが他のワークロードとホストカーネルを共有すべきでないコマンドを実行した場合の爆発半径を縮小できます。
ただし、この表現は意図的に限定されています。Firecrackerは分離のためのプリミティブであり、プロダクトレベルのポリシーではありません。最終的なサンドボックスのセキュリティ態勢は、プラットフォームがゲストイメージ、ファイルシステムマウント、ネットワーキング、パッケージアクセス、シークレットインジェクション、ログ、ライフサイクル、およびマイクロVM周辺のホスト制御をどのように構成するかに依存します。
マイクロVM分離が有効なケース
FirecrackerスタイルのマイクロVMは、サンドボックスが幅広いランタイム動作を持つ信頼できない、または半信頼のコードを実行する可能性がある場合に最も適しています。AIエージェント製品では、通常、モデルが書いたコード、リポジトリからコピーされたコード、パッケージマネージャーのスクリプト、ブラウザ自動化ヘルパー、生成されたシェルコマンド、またはユーザーが提供する評価ジョブが該当します。
最も強力なユースケースは次のとおりです。
| ワークロード | マイクロVM境界が役立つ理由 | 依然としてポリシーが必要なもの |
|---|---|---|
| コーディングエージェント | コマンド、テスト、コンパイラ、パッケージスクリプトが任意のコードを実行する可能性がある | リポジトリマウント、コマンド許可リスト、ネットワークポリシー、後処理 |
| データ分析エージェント | PythonやRのコードがユーザーファイルを解析し、ライブラリをインストールする可能性がある | ファイルスコープ、パッケージレジストリ制御、出力保持、シークレット編集 |
| ブラウザ・コンピュータ利用エージェント | セッションにCookie、ダウンロード、スクリーンショット、ブラウザプロファイルが含まれる可能性がある | クレデンシャル分離、外部通信、再生ログ、クリーンアップ |
| マルチテナント評価・強化学習実行 | 複数のタスクが異なるユーザー、データセット、ポリシーで並行実行される可能性がある | テナント分離、リソースクォータ、決定的リセット、監査記録 |
| サブプロセスアクセスを持つツール/MCPサーバー | ツールサーバーがモデル出力から実際の実行へのブリッジになる可能性がある | ツール権限、ファイルシステムルート、クレデンシャル、承認ゲート |
マイクロVM境界は、代替手段がエージェントコードをアプリケーションホスト、開発者ワークステーション、共有CIランナー、またはタスクごとの分離が弱いKubernetesノードで直接実行することである場合に特に有用です。また、コンテナが運用上便利だが、すべてのコンテナがホストカーネルを共有するためリスクモデルに不安がある場合にも役立ちます。
Firecrackerでは問題全体を解決できない領域
Firecrackerは、エージェントが呼び出してもよいドメイン、マウントされるファイル、存在するシークレット、信頼できるパッケージ、承認が必要なツールコールを決定しません。また、生成されたコードが正しい、安全である、悪意がない、またはビジネスルールに準拠していることを保証するものでもありません。
Firecracker自身の設計ノートでは、ゲストのネットワークトラフィックは信頼できないものとして扱われ、ホストレベルでのフィルタリングが期待されています。この点はAIエージェントに直接当てはまります。エージェントがパブリックインターネット、内部メタデータサービス、プライベートAPI、または任意のDNSに到達できる場合、マイクロVM境界だけでは不十分です。外部通信の制御が依然として必要です。
また、Firecrackerは互換性の問題を解決しません。サンドボックスプラットフォームは、オペレーティングシステムイメージ、言語ランタイム、パッケージマネージャー、ブラウザ依存関係、フォント、証明書、ビルドツール、エージェントが期待するSDKを提供する必要があります。イメージが最小限すぎると、通常の開発者タスクが失敗する可能性があります。イメージが広すぎると、不要な攻撃対象領域や遅い起動動作をもたらす可能性があります。
運用面での境界も評価が必要です。マイクロVMの実行は、カーネル、ルートファイルシステム、イメージ、スナップショット、ブロックデバイス、ネットワーキング、ホスト容量、レート制限、メトリクス、クリーンアップの管理を意味します。マネージドサンドボックスはこれらの作業の多くを隠蔽できますが、作業自体はスタックのどこかに存在します。
ライフサイクルと起動のトレードオフ
エージェントワークロードすべてが同じライフサイクルを必要とするわけではありません。中には、起動して実行し、ファイルを返して消えるだけの短いコードインタプリタ呼び出しもあります。一方、永続的なワークスペース、バックグラウンドサーバー、ブラウザセッション、後で再開するための一時停止状態を必要とする長時間のコーディングセッションもあります。
Firecrackerは軽量マイクロVM向けに設計されていますが、実際のサンドボックスには常にライフサイクルの選択肢があります。
- タスクごとに新しい環境を起動しますか？
- ウォームプールやスナップショットから起動しますか？
- エージェントセッション全体にわたってワークスペースを生かし続けますか？
- アイドル状態のサンドボックスを一時停止し、後で再開しますか、それとも破棄しますか？
- 生成されたファイル、完全な状態、または選択したアーティファクトのみを保持しますか？
新しい環境からのスタートは、各タスクが既知のベースラインから始まるため、推論が容易です。ただし、エージェントが多くの小さなアクションを実行する場合、オーバーヘッドが増える可能性があります。長時間存続するセッションは継続性を向上させますが、状態のドリフト（インストールされたパッケージ、生成されたファイル、シェル履歴、ブラウザキャッシュ、バックグラウンドプロセス、クレデンシャルが蓄積される）を引き起こします。
スナップショットとテンプレートは役立ちますが、ガバナンスが必要です。テンプレートには、以前のエージェント実行中にたまたまインストールされたものではなく、承認されたツールと依存関係が含まれている必要があります。スナップショットは、適切なユーザー、テナント、プロジェクト、ポリシーに属している必要があります。サンドボックスが再開する場合、同じかより厳しい権限で再開すべきであり、古いクレデンシャルや広いネットワークパスで再開すべきではありません。
ファイルシステム、パッケージ、ワークスペースポリシー
ファイルシステムアクセスは、サンドボックスアーキテクチャがプロダクトデザインになる部分です。マイクロVMは分離されたゲストファイルシステムを提供できますが、プラットフォームがそのファイルシステムに何を入れ、何を出すかを決定します。
エージェントサンドボックスでは、ワークスペースを実用的なゾーンに分割します。
| ゾーン | 標準的なアクセス | ポリシーの質問 |
|---|---|---|
| 入力ファイル | 可能な場合は読み取り専用 | 生成されたコードがソースファイルやユーザーアップロードを変更できるか？ |
| 作業ディレクトリ | 読み書き可能 | これは使い捨てか、永続的か、レビュー可能か？ |
| ビルド・パッケージキャッシュ | 読み書き可能だが制御下 | どのパッケージマネージャーとレジストリが許可されるか？ |
| 出力アーティファクト | レビューまたはポリシーチェック後にエクスポート | どのファイルがサンドボックスから出ることができるか？ |
| シークレット | 可能な限りファイルマウントを避ける | どのプロセスがクレデンシャルを読み取ることができ、その期間は？ |
パッケージインストールは特別な注意が必要です。エージェントはしばしば pip install、npm install、ブラウザダウンロード、Gitクローン、または任意のURLフェッチを要求します。この柔軟性はデータサイエンスやコーディングタスクには価値がありますが、サプライチェーンリスクを生み出します。実用的なサンドボックスポリシーでは、許可リスト化されたレジストリ、プルスルーキャッシュ、固定バージョン、ロックファイル、ハッシュログ、パッケージサイズ制限、異常なソースに対する承認を使用する場合があります。
重要な質問は「Firecrackerはパッケージインストールを許可するか？」ではありません。重要な質問は「プラットフォームは、どのコードがサンドボックスに入ることができ、インストール中にどのスクリプトが実行でき、どの出力が出ることができるかを説明し、強制できるか？」です。
ネットワーク、シークレット、監査制御
ネットワークポリシーは明示的であるべきです。デフォルトで外部通信が許可されていると、Web検索やパッケージインストールには便利ですが、データ流出や依存関係の侵害を推論するのが難しくなります。デフォルトで拒否する方がレビューしやすいですが、有用なエージェントタスクが機能するように、慎重に設計された許可リスト、プロキシルール、レジストリアクセス、エラーハンドリングが必要です。
ネットワーク制御はいくつかのレベルで評価します。
- DNS動作: DNSが外部通信ポリシーを回避したり、内部名に到達したりできるか？
- 外部HTTPアクセス: 宛先は許可リスト化、プロキシ経由、ログ記録、または無制限か？
- パッケージレジストリ: パッケージダウンロードは承認されたレジストリまたはミラーに制限されているか？
- 内部サービス: サンドボックスはプライベートAPI、メタデータエンドポイント、データベース、管理パネルに到達できるか？
- 受信リスナー: エージェントはポートを公開でき、誰が到達できるか？
シークレットはサンドボックスよりも狭くする必要があります。すべてのセッションに広範な環境ファイルをマウントしないでください。各ツールに必要なクレデンシャルを与え、可能であれば短期間で、テナント、プロジェクト、アクション、環境によってスコープを設定します。stdout、stderr、トレース、スクリーンショット、ブラウザダウンロード、例外メッセージ、モデルから見えるツール応答からシークレットを編集します。
監査ログは、エージェントの動作を再構築可能にしつつ、第二のシークレットストアにならないようにする必要があります。有用な記録には、サンドボックスID、ユーザーまたはテナント、テンプレートバージョン、コマンドカテゴリ、パッケージ名、外部ドメイン、読み取りまたは書き込みされたファイル、出力アーティファクト、終了ステータス、ネットワーク判断、クリーンアップ結果が含まれます。デフォルトでは、未加工の顧客ファイル、完全なコマンド出力、トークン、完全なプロンプトをログに記録しないようにします。ただし、保持とアクセス制御がそのデータ向けに設計されている場合は別です。
別の分離モデルの方がシンプルな場合
Firecrackerがすべてのエージェントタスクに自動的に最適な答えというわけではありません。一部のワークロードは、よりシンプルな境界で十分に処理できます。
「ツール」が実際には狭いAPI呼び出し（請求ステータスの確認、カレンダーの読み取り、サーバー側認証によるレコード検索）である場合、通常のバックエンドサービスで十分なことがよくあります。そのようなAPIクライアントをマイクロVM内に配置すると、リスクを意味的に低減することなく、レイテンシと運用の複雑さが増す可能性があります。
コンテナやプロセスレベルのサンドボックスは、起動速度、イメージ互換性、運用のシンプルさがVMスタイルの境界よりも重要な、低リスクで短命なタスクに適しています。内部のみの変換、決定論的な変換、シークレットやネットワークアクセスのない信頼できるコードパスは、より軽い分離の良い候補です。
専用のマネージドブラウザ、CIランナー、ワークフローエンジンは、主なリスクが任意のコード実行ではなく特殊な状態管理である場合に適しています。たとえば、ブラウザ自動化製品は、汎用的なLinuxマイクロVMよりも、深いセッション再生、プロキシローテーション、視覚的デバッグを必要とする場合があります。
専用インフラストラクチャは、ハードウェアアクセス、GPUワークロード、カスタムカーネル、厳格なデータ所在地、オンプレミス要件が決定要因となる場合に適切な選択です。マイクロVMベースのサンドボックスはその設計の一部になる可能性がありますが、デプロイメント制御の必要性を置き換えるものではありません。
Firecrackerを選択する前の評価質問
「Firecrackerベース」というだけで十分な証拠と見なす前に、完全なサンドボックス設計に関する具体的な質問をしてください。
| 領域 | 質問すべきこと |
|---|---|
| 境界 | 各エージェント、テナント、タスクに個別のマイクロVMが割り当てられるか、それともワークロードがグループ化されるか？ |
| ゲストイメージ | どのOS、カーネル、ランタイム、ブラウザ、パッケージマネージャーが含まれるか？ |
| 起動 | プラットフォームは新規起動、ウォームプール、スナップショット、長時間セッションのどれを使用するか？ |
| ワークスペース | どのファイルがマウント、永続化、スナップショット、エクスポート、削除されるか？ |
| プロセス | CPU、メモリ、プロセス数、実行時間、バックグラウンドジョブは制限されるか？ |
| ネットワーク | 外部通信はデフォルト拒否、許可リスト化、プロキシ経由、ログ記録、または無制限か？ |
| パッケージ | どのレジストリ、Gitリモート、インストールスクリプト、ロックファイル、キャッシュが許可されるか？ |
| シークレット | クレデンシャルはどのようにスコープ設定、注入、ローテーション、編集、削除されるか？ |
| 可観測性 | セキュリティチームはコマンド、ファイル、ドメイン、パッケージ、アーティファクト、ライフサイクルイベントを確認できるか？ |
| 互換性 | 通常のエージェントワークロードは、必要な言語、ブラウザ、フォント、CLI、システムパッケージで動作するか？ |
| 障害処理 | タイムアウト、クラッシュ、外部通信拒否、クリーンアップ失敗、ホスト負荷の後はどうなるか？ |
| レビューゲート | サンドボックス内であっても、どのアクションに依然として人間の承認が必要か？ |
求めたい答えは、単一のテクノロジーラベルではありません。それは、分離境界、その周りのポリシー、そしてそれらのポリシーがワークロードに有効であるという証拠の明確な説明です。
Novita Agent Sandboxの位置づけ
Novita Agent Sandboxは、コード、ファイル、プロセス、ブラウザ指向のワークフロー、長時間セッションに対して分離された実行環境を必要とするエージェントワークロード向けに構築されています。生成されたコードをアプリケーションサーバー、開発者ラップトップ、または広範な共有ランナーに直接配置することなく、AIエージェント向けの管理されたランタイム境界を求めるチームに適しています。
すでにNovita AIモデルAPIで構築しているチームにとって、Agent Sandboxはより広範なエージェントアーキテクチャの一部となりえます。モデルが計画を立てたりツールを呼び出したり、サンドボックスがコードやブラウザのステップを実行し、アプリケーションレイヤーが承認、クレデンシャル、ネットワークポリシー、ログ記録、アーティファクトレビューを強制します。この分離は重要です。サンドボックスはランタイムの爆発半径を減らすべきであり、製品はエージェントに何が許可されるかを決定します。
Novita Agent Sandboxを含む任意のサンドボックスを評価する際は、同じ質問を考慮に入れてください。ワークロードの適合性、ライフサイクル、ファイルシステムポリシー、外部通信、パッケージ取得、シークレット、ログ、互換性、機密アクションに対する人間のレビューです。Firecrackerスタイルの分離は強力な基盤となりえますが、安全なエージェント実行はサンドボックス周辺の制御システム全体から生まれます。
FAQ
FirecrackerはAIエージェントサンドボックスにおいてDockerよりも安全ですか？
FirecrackerはKVMをバックエンドとするマイクロVM境界を提供し、Dockerコンテナは通常ホストカーネルを共有します。そのため、Firecrackerは信頼できないエージェントコードに魅力的に見えますが、自動的にサンドボックスを安全にするわけではありません。ネットワークポリシー、ファイルシステムスコープ、パッケージガバナンス、シークレット、ログ記録、ライフサイクル制御が実際のリスクを決定します。
FirecrackerはAIエージェントからのデータ流出を防ぎますか？
それだけでは防ぎません。マイクロVM境界はランタイムを分離できますが、データ流出はネットワーク外部通信、DNSポリシー、パッケージダウンロード、マウントされたファイル、シークレット、出力エクスポート、ログに大きく依存します。外部通信制御は別個の要件として扱ってください。
Firecrackerサンドボックスは常にエージェントにとって十分な速度ですか？
常にそうとは限りません。Firecrackerは軽量マイクロVM向けに設計されていますが、実際の起動時間はホスト、ゲストイメージ、スナップショット戦略、言語ランタイム、ブラウザ依存関係、パッケージキャッシュ、プラットフォームがウォームプールと新規環境のどちらを使用するかに依存します。一般的な起動時間の主張に頼るのではなく、独自のエージェントワークフローでテストしてください。
すべてのAIエージェントタスクをFirecrackerマイクロVMで実行すべきですか？
いいえ。リスクに一致する境界を使用してください。高リスクの生成コード、パッケージインストール、ブラウザセッション、マルチテナント評価ジョブ、サブプロセスアクセスを持つツールサーバーは、より強力な候補です。狭いバックエンドAPI呼び出しや信頼できる内部タスクは、マイクロVMの外部の方がシンプルな場合があります。
セキュリティチームはFirecrackerベースのサンドボックスベンダーに何を質問すべきですか？
ワークロードがどのように分離されるか、ゲストイメージで何が実行されるか、外部通信とDNSがどのように制御されるか、パッケージがどのように取得されるか、シークレットがどのように注入・編集されるか、どのログが利用可能か、状態がどのようにクリーンアップされるか、そしてどのアクションに依然として承認が必要かを質問してください。
