pydantic-aiのSmolSandbox提案に見る、エージェント実行環境をVMで隔離する意味

分析・見解

コンテナの共有カーネルが、エージェントには弱点になる

通常のコンテナは、ホストと同じカーネル（＝OSの中核部分）を共有する。人間が書いた決まりきった処理なら、これで十分だった。しかしAIエージェントは、実行時に自分でコードを書き、試し、失敗しては書き直す。動かすプログラムの中身が事前には分からない。

カーネルの弱点を突くコードが紛れ込めば、コンテナの壁は一枚の薄い板にすぎない。AIが生成したコードによる不要なファイル削除や、認証情報の外部送信への懸念は、これまで繰り返し指摘されてきた。

タスクごとに専用VMを持たせる発想の利点

smolvmは、タスクごとに専用の仮想マシンと専用のカーネルを用意する。万一壊されても、被害は使い捨ての部屋の中で止まる。従来の仮想マシンは起動が遅く、重かった。マイクロVMはその重さを削り、起動をぐっと速くする発想である。

重さが許容範囲に入れば、毎回新しい部屋を使い捨てる運用が現実になる。AWS Lambdaが内部でFirecrackerというマイクロVMを使っているのも、同じ理屈だ。もちろん専用カーネルを持つ分、メモリ消費は増える。軽さと強さの交換条件は残る。

ハーネスごと閉じ込める点が、提案の核心である

今回の提案で目を引くのは、ツール呼び出しだけを隔離するのではなく、ハーネス機能（＝エージェントを動かす周辺の仕組み。ファイル操作やシェル実行など）ごとVMに入れる点だ。ツール単位の隔離では、設定ファイルや認証情報へ至る経路が残りやすい。

作業領域全体を切り離せば、ホストのファイルは明示的に渡したものしか見えない。利用者の目には自分のパソコン内で動いているように見えて、実際は別室で動いている状態になる。一方で、VMの内外で状態をどう受け渡すか、ログやデバッグをどう扱うかという設計課題は増える。

隔離の方式が「選べる部品」になっていく流れ

筆者が注目するのは、隔離方式がフレームワークの差し替え可能な部品になる流れだ。Dockerを使う実装、クラウドのサンドボックスを使う実装があり、そこにsmolvmが並ぶ。開発者は用途に応じて、強さと速さを選べるようになる。

セキュリティが各チームの自作から、設定で選ぶ項目へ変わる。これは暗号化がライブラリ任せになった歴史と似ている。ただし現時点はissueの段階であり、取り込まれるかどうかは未定だ。