エージェント用のコード実行サンドボックス

エージェントがコードを生成するときは、何かがそれを実行する必要があります。そのコードを開発者のラップトップまたは運用サーバーで直接実行するのは危険です。コードにより、ファイルの削除、環境変数からの資格情報の読み取り、ソフトウェアのインストール、暗号通貨のマイニング、またはネットワーク接続のオープンが行われる可能性があります。サンドボックスは、コードとその他すべての間に境界を置きます。分離にはいくつかの層があり、さまざまなトレードオフがあります。標準コンテナ (Docker など) は、Linux 名前空間と cgroup を使用して、コードにプロセス、ファイル、ネットワークの独自のビューを与え、CPU とメモリを制限します。これらはすぐに起動しますが、すべてのコンテナがホストのカーネルを共有するため、カーネルの脆弱性によりコードが漏洩する可能性があります。 Google のオープンソース プロジェクトである gVisor は、システム コールをインターセプトするユーザー空間カーネルを追加し、信頼できないコードが実際のカーネルに触れる可能性を縮小します。 Firecracker などの MicroVM は、もともと AWS によって Lambda と Fargate 用に構築されたもので、各ワークロードに独自の軽量仮想マシンとカーネルを与えながら、ほんの数秒で起動します。 E2B などのエージェント向けのホスト型サンドボックス サービスは、この microVM アプローチに基づいて構築されています。最も軽いエンドでは、WebAssembly ランタイムと Pyodide などのツールを使用して、システムに直接アクセスすることなく、ブラウザーまたは Wasm サンドボックスで Python を実行できます。絶縁技術は設計の半分にすぎません。優れたサンドボックスは、ネットワークを制限し (多くの場合、ホワイトリストでデフォルトで拒否されます)、スクラッチ ディレクトリを除いてファイル システムを読み取り専用でマウントし、機密情報を環境から完全に排除し、時間、メモリ、プロセス数、およびディスクの制限を強制します。通常、それらは一時的なものであり、タスクごとに作成され、その後破棄されます。よくある誤解は、サンドボックスによってエージェントが安全になるというものです。コード自体による被害は制限されますが、エージェントが誤った回答を生成することは阻止されず、サンドボックスに渡されたツールや資格情報には、挿入された命令に応答して記述されたコードを含め、そこで実行されるあらゆるコードがアクセス可能になります。