安全かつスケーラブルなエージェントサンドボックス基盤の構築方法について

AWS Lambda から制御プレーンアーキテクチャを備えた Unikraft マイクロ VM まで。 Browser Use では数百万の Web エージェントを運用しています。当初は AWS Lambda でブラウザ操作に特化したエージェントを実行していました。各呼び出しが完全に隔離され、スケーリングは瞬時に行われ、機密情報の管理も不要でした。 その後、コード実行機能を追加しました。エージェントは Python の記述と実行、シェルコマンドの実行、ファイルの作成が可能になります。これらはすべて、エージェントがツールとして呼び出す独立したサンドボックス内で動作するように構築しました。セキュリティ面では問題ありませんでした。コードはバックエンドではなく、あくまでサンドボックス内で実行されるからです。 しかし、エージェントループ自体は REST API と同じバックエンド上で動いていました。再デプロイすればすべての実行中のエージェントが停止し、メモリを大量に消費するエージェントが発生すると API の応答が遅延します。本質的に異なる 2 つのワークロードが、同じプロセス内で競合していたのです。 エージェントが任意のコードを実行できる場合、そのマシン上のあらゆるものへのアクセスが可能になります。環境変数、API キー、データベース認証情報、内部サービスなどです。これらはインフラや機密情報から完全に隔離される必要があります。そのためには主に 2 つのアプローチがあります。 パターン 1：ツールを隔離する。エージェントは自社のインフラ上で動作し、危険な操作（コード実行やターミナルアクセス）のみが別々のサンドボックスで実行されます。エージェントは HTTP を介してサンドボックスを呼び出し、コードは機密情報を漏洩させる余地のない環境で実行されます。 パターン 1 - ツールの隔離 パターン 2：エージェントを隔離する。エージェント全体をゼロトラストのサンドボックス内で動作させます。外部との通信は、すべての認証情報を管理する制御プレーンを介して行われます。 エージェントは使い捨てのものになります。盗まれる秘密も、保存すべき状態もありません。必要に応じて殺し、再起動し、独立してスケールさせることができます。真実はコントロールプレーンが保持します。 パターン 2：エージェントを隔離する 私たちはまずパターン 1 から始め、次にパターン 2 へと移行しました。 同じコンテナイメージをどこでも実行します。本番環境ではマイクロ VM として動作し、ローカル開発や評価用テストではコンテナとして動作します。プロビジョニングコードのパスを切り替えるのは、単一の設定スイッチ（sandbox_mode: 'docker' | 'ukc'）だけです。 各エージェントには独自の Unikraft マイクロ VM が割り当てられ、起動は 1 秒未満で完了します。これらは AWS の専用ベアメタルマシン上で、Unikraft Cloud の REST API を経由してプロビジョニングされます。 サンドボックスが外部から受け取る環境変数は、セッショントークン（SESSION_TOKEN）、コントロールプレーンの URL（CONTROL_PLANE_URL）、そしてセッション ID（SESSION_ID）の 3 つだけです。AWS キーもデータベース認証情報も API トークンもありません。 Unikraft を使えば、スケール・トゥ・ゼロが標準で実現できます。サンドボックスがアイドル状態になると VM はサスペンドされ、次のリクエストが来れば即座に再開します。クエリ間の待機中のコストはほぼゼロですが、フォローアップタスクには瞬時に起動します。 単一のメトロがボトルネックになるのを防ぐため、サンドボックスは複数の Unikraft メトロに分散されます。 ローカル環境や評価パイプラインでは、同じイメージを Docker コンテナとして実行します。イメージもエントリーポイントもコントロールプレーンのプロトコルもすべて共通です。開発者のノート PC で正確に同じエージェントを実行し、評価用には数百を並列で起動し、本番環境では Unikraft にデプロイできます。 エージェントコードが実行される前に、サンドボックスは以下の処理を行います： 1. バイトコードのみでの実行 Docker ビルド時にすべての Python ソースコードを .pyc バイトコードにコンパイルし、すべての .py ファイルを削除します。エージェントフレームワークのコードはルート権限でメモリ上に読み込まれます。一度読み込まれれば、ソースコードは消去されます。 2. 特権の降格 エントリーポイントは、ルート所有のバイトコードを読み込むためにルートユーザーとして起動しますが、すぐに `setuid`/`setgid` を介して `sandbox` ユーザーに権限を下げます。以降、すべての処理は特権なしで実行されます。 3. 環境の整理 SESSION_TOKEN、CONTROL_PLANE_URL、SESSION_ID を Python の変数として読み込んだ後、これらを os.environ から削除します。エージェントが環境を検査しても、これらの変数は存在しません。トークンはサンドボックス内のネットワーク外では無効です。この VM はプライベート VPC に配置されており、コントロールプレーンとの通信以外に許可される権限はありません。 コントロールプレーンをプロキシサービスと捉えてください。サンドボックスは外部世界への直接アクセスを持っていません。すべてのリクエストは必ずコントロールプレーンを介してホップする必要があります。LLM を呼び出したい場合も、S3 へのファイルアップロードを行いたい場合も、すべてコントロールプレーンを経由します。これがエージェントが VM 外の何らかのものに通信できる唯一の方法です。 これはステートレスな FastAPI サービスです。サンドボックスからのすべてのリクエストには `Bearer: {session_token}` ヘッダーが含まれます。コントロールプレーンはトークンでセッションを検索し、アクティブであることを検証した上で、実際の認証情報を用いて操作を実行します。 各LLM呼び出しにおいて、サンドボックスは新しいメッセージのみを送信します。一方、コントロールプレーンはデータベース内の会話履歴全体を保持しており、各呼び出し時にこれを再構築してプロバイダーへ完全なコンテキストとして転送します。これにより、サンドボックスの状態は非永続化（ステートレス）されます。必要に応じてプロセスを終了し、新しいインスタンスを起動しても、会話は中断された場所から継続できます。 コストの上限設定や請求処理もコントロールプレーンが担当しており、サンドボックスはタスク実行にのみ集中します。 サンドボックス内にはエージェントがファイルの読み書きを行う `/workspace` ディレクトリが存在します。ファイル同期サービスがこのディレクトリの監視を行い、変更を検知すると定期的に S3 へ同期しますが、サンドボックス自身が AWS の認証情報を取得することはありません。代わりに、サンドボックスはコントロールプレーンに対してプレサイン付き URL を要求します。 - サンドボックスが `/workspace` 内の更新されたファイルを検出 - ファイルパスを指定して `POST /presigned-urls` エンドポイントを呼び出し - コントロールプレーンがセッション限定のプレサイン付き S3 アップロード URL を生成 - サンドボックスはこれらの URL を使用してファイルを直接 S3 へアップロード ダウンロードも同様に逆方向で行われます。これにより、サンドボックスは AWS の認証情報を保持することなく、スコープ限定された S3 アクセス権を直接取得できます。 サンドボックス内部では、エージェントは「Gateway」プロトコルを通じてコントロールプレーンと通信します。 ```python class AgentGateway(Protocol): async def invoke_llm(self, new_messages, tools, tool_choice) -> LLMResponse: ... async def persist_messages(self, messages) -> None: ... ``` 本番環境では ControlPlaneGateway が制御プレーンに対して HTTP リクエストを送信します。一方、ローカル開発や評価用には DirectGateway が LLM に直接呼び出しを行い、履歴はメモリ上に保持されます。エージェント側のコードがどちらを使用しているかを意識する必要はありません。インターフェースも動作も同じで、バックエンドのみが異なります。 制御プレーンはステートレスです。トークンを検証し、処理を実行して結果を返すだけです。エージェントを増やしたければサンドボックスをさらに起動すればよく、スループットを上げたいのであればロードバランサーの背後に制御プレーンのインスタンスを追加するだけで済みます。各レイヤーはそれぞれのボトルネックに応じて独立してスケールします。 バックエンドは ALB の背後にあるプライベートサブネット上の ECS Fargate で稼働しています。制御プレーンは CPU 利用率に基づいて自動スケーリングし、サンドボックスは Unikraft を介して独立してスケールします。各セッションには専用の VM が割り当てられ、Unikraft がメトロ間でのスケジューリングを担います。 サービス（バックエンド、エージェント、制御プレーン）の独立したスケーリング コード実行可能なエージェントをサンドボックス化するアプローチには主に 2 つあります。1 つ目はツールを隔離する方法で、コード実行のみをサンドボックス内で行い、エージェント自体は自社のバックエンド上に置きます。2 つ目はエージェント全体を隔離する方法で、外部との通信はすべて制御プレーンを介して行います。 私たちは後者のパターンを採用しました。制御プレーンがすべての認証情報を保持し、LLM の呼び出し、ファイルストレージ、請求処理など全ての窓口としてプロキシの役割を果たします。サンドボックスには 3 つの環境変数だけが渡され、それ以外のリソースへのアクセスは一切できません。本番環境では Unikraft のマイクロ VM として動作し、開発や評価用には Docker コンテナとして起動されます。どこでも同じイメージを使用しています。 各操作でネットワークホップが1つ増え、デプロイするサービスも1 つから3 つに増えるというトレードオフがあります。しかし実際には、LLM の応答時間に比べれば遅延は誤差の範囲であり、運用上の複雑さも、Ops チームがすでに慣れ親しんでいるレベルです。 重要なポイント：エージェントには、盗む価値のあるものも、守る価値のあるものも存在してはいけません。

安全かつスケーラブルなエージェントサンドボックス基盤の構築方法について

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト