Anthropic Simonはsmolvmをテストしたが、サンドボックスには依然としてコントロールプレーンが必要

Anthropicの研究者であるSimon Willisonは、ネットワーク、ファイルシステム、リソースの乱用を許さずに信頼できないPythonとJavaScriptを安全に実行するという厳しい目標に対し、smolvmをテストした。この実験はすぐに矛盾に突き当たった。ウェブ版Claude CodeはFirecrackerゲスト内で動作していた一方、smolvmには、ゲストから公開されていないハードウェア仮想化へのアクセスが必要だった。

この失敗は、smolvmが安全でないことを示すものではない。セキュリティテストを始める前の段階で、別の制限付き仮想マシン内でmicroVMを評価しようとすると失敗し得ることを示した。ユーザー提供のスクリプト、AI生成プログラム、自動データ変換を検討するチームにとって、この違いは重要だ。

サンドボックスに関する研究ノートは、より大きなエンジニアリング上の不足も明らかにしている。堅牢な仮想マシン境界は、安全なコード実行サービスを構成する一部にすぎない。運用者には、その境界の周囲に期限、リソース計測、ファイルのステージング、出力制御、監視、クリーンアップがなお必要になる。

smolvmはいくつか有用な要素を備える。ネットワークはデフォルトで無効で、ワークロードには個別のゲストカーネルが割り当てられ、CPUとメモリの値も設定可能だ。しかし、これらの機能があるからといって、敵対的なコード向けの本番サービスが自動的に完成するわけではない。

したがって本質的な競争は、smolvmとDocker、あるいはPythonとJavaScriptの対決ではない。ワンコマンドでの隔離という約束と、信頼できるマルチユーザー実行に必要な運用上の制御との対比である。

信頼できないコードが実行される前にテストは失敗した

最初の結果は、サンドボックスからの脱出やリソース制限の失敗ではなく、環境互換性の失敗だった。

Willisonは、ウェブ版Claude Codeを通じて動作するAnthropicモデルに、高速なサンドボックスとしてsmolmachinesを調査させた。想定したワークロードは具体的で、構造化データの変換のようなジョブに対して、ユーザーが提供するコードを実行するというものだった。

そのコードには厳格な境界が必要だった。ネットワークを見られず、指定されたファイルだけにアクセスし、メモリ消費を制限し、運用者が定義した時間で停止しなければならない。while trueのような無限ループが、計算資源を無期限に占有してはならない。

モデルはプロジェクトを調査し、テストを設計できた。しかし、それらを実行するために必要なsmolvmマシンは起動できなかった。Willisonの説明によれば、Claude Code環境はすでにLinuxを実行するFirecrackerゲストだった。

smolvmは、プラットフォーム固有のハイパーバイザーを通じてハードウェア支援仮想化を利用する。Linuxでは通常、これはKVM、すなわちプロセッサの仮想化機能を仮想マシンモニターに公開するカーネルインターフェースを意味する。制限されたクラウドゲストには、多くの場合、別のハードウェアアクセラレーション対応ゲストを起動するための/dev/kvmデバイスがない。

これはネストされた仮想化の問題だ。仮想マシンが別の仮想マシンをホストできるのは、外側のプラットフォームが必要なプロセッサ機能とデバイスアクセスを公開している場合に限られる。多くのマネージドサンドボックスは意図的にそれらを提供しない。

この制約は、特異なテスト上のパラドックスを生む。ウェブ版Claude CodeはmicroVM内で実行されていたため、部分的に隔離されていた。その隔離が、評価を依頼された別のmicroVMを起動することを妨げた。

この試行では、有意なPythonまたはJavaScriptの攻撃ワークロードはsmolvmまで到達しなかった。起動レイテンシー、メモリ強制、CPU飽和、ファイル隔離、終了時の挙動について、独立した測定値は得られていない。

この欠けた証拠は、結論の形を左右すべきだ。この実験がsmolvmを安全な実行サービスとして検証したと主張するのは不正確である。同様に、起動が阻止されたことをsmolvmのゲスト隔離に不利な証拠として扱うのも不正確だ。

むしろ、この結果はデプロイメントの前提条件を特定している。チームはsmolvmを、互換性のある物理ホスト、またはネストされた仮想化を許可する仮想マシン上で動作させなければならない。

公式のsmolvmセキュリティモデルでは、LinuxバックエンドとしてKVMが挙げられている。また、各対応OS上でAppleのHypervisor frameworkとWindows Hypervisor Platformもサポートしている。

このクロスプラットフォーム設計はローカル開発に役立つ。しかし、それによってsmolvmが既存のあらゆるエージェントサンドボックス、継続的インテグレーションワーカー、サーバーレス環境内で実行可能になるわけではない。

anthropic simonの実験では、これが最初の重要な逆転である。研究エージェントを保護していた隔離層そのものが、エージェントによる第2の隔離層のテストを阻んだ。

Anthropic Simonは不足しているコントロールプレーンを浮き彫りにした

smolvmはVM境界を提供できるが、アプリケーション側はコードをいつ開始し、何を与え、いつ終了させるかを決めなければならない。

このプロジェクトはsmolvmを、隔離されたポータブルなLinux仮想マシン向けのコマンドラインツールとして説明している。各ワークロードは、軽量ワークロード向けに設計された仮想マシンモニターであるlibkrunを通じて、自身のゲストカーネルで実行される。

このアーキテクチャは、通常のコンテナよりも強力なデフォルト境界を作る。従来のコンテナは、namespaceによってプロセス、ネットワーク、マウントを隠していても、通常はホストカーネルを共有する。smolvmのゲストには、ハイパーバイザー境界の背後にある個別のカーネルが与えられる。

この違いにより、ホストカーネルへの直接的な露出は減る。ただし、ゲスト内部で実行されるすべてを信用してよいという意味ではない。smolvmのドキュメントは、運用者がゲストrootを信頼できないものとして扱うべきだと明示している。

デフォルトのネットワーク方針はWillisonの目標と一致する。ネットワークアクセスはオプトインであるため、ネットワークオプションなしで起動されたマシンには、通常の外部接続性が与えられないはずだ。アプリケーションが限定的な外部通信を必要とする場合には、ホストの許可リストを利用できる。

ファイルシステムへの露出も明示的だ。ホストディレクトリは、運用者がマウントした場合にのみ可視化される。これにより、変換ジョブ向けのステージングディレクトリ方式が可能になる。

実行サービスは、指定された入力を一時ディレクトリへコピーできる。そのディレクトリを読み取り専用でマウントし、別の書き込み可能な出力場所を提供し、結果の検証後に両方を破棄できる。

ただし、smolvmの文書化された制限は重要だ。そのボリュームインターフェースは、個別ファイルではなくディレクトリをマウントする。「指定されたファイルのみ」へのアクセスを約束するサービスは、したがって、それらのファイルだけを正確に含む隔離ディレクトリを構築しなければならない。

サービスは、このステージング工程も防御しなければならない。シンボリックリンク、異常なデバイスファイル、想定外の権限、意図したディレクトリから逸脱するパスを拒否すべきだ。VM境界は、不注意なホスト側のファイル準備プロセスを修正できない。

メモリ設定は、--memオプションまたはsmolvmの宣言的なマシン設定であるSmolfileを通じて利用できる。文書化されたデフォルトは8 GiBで、メモリはelastic virtio balloonを通じて提供される。

弾力的な割り当ては、ホストが設定済みの全容量を直ちにコミットしないため、ホスト利用率を向上させる。これは、多数の敵対的ジョブにまたがる受け入れ制御と混同すべきではない。

サービスが楽観的な割り当てで多数のゲストを起動すれば、総需要は依然としてホストを圧倒し得る。スケジューラーには、メモリ、仮想CPU、ストレージ、同時実行マシン数を対象とする別個の容量モデルが必要だ。

CPU設定にも同様の違いがある。仮想CPUを1つ割り当てることは、ゲスト内の並列実行を制限する。それは、プログラムが固定量のCPU秒しか受け取らないことを自動的に保証するものではない。

シングルスレッドの無限ループは、割り当てられた仮想CPUを永久に消費できる。ハイパーバイザーはループを封じ込めるが、外部スーパーバイザーが期限を強制し、マシンを終了させなければならない。

本番システムには通常、経過時間ベースとリソースベースの両方の方針が必要だ。経過時間のタイムアウトは、ハング、スリープ中のプロセス、デッドロックしたプログラムに対処する。CPU計測は、進捗を出さずに計算資源を消費するワークロードを検出する。

スーパーバイザーはゲストの外部に存在しなければならない。マシン内で実行されるコードが、タイマー、終了シグナル、最終的なクリーンアップ判断を制御すべきではない。そうでなければ、ワークロードは自身のガードレールを無効化しようと試みられる。

これが、「信頼できないコード向けのサンドボックス」という言葉が2つの別個の製品を隠し得る理由だ。1つは隔離エンジンである。もう1つは、そのエンジンを安全にスケジュールし監督するコントロールプレーンだ。

anthropic simonのテストは、完全な製品挙動を対象としていた。smolvmの公開インターフェースは主に、それを構築するための隔離エンジンと低レベルの設定を提供する。

MicroVMは境界を変えるが、脅威モデルを変えるわけではない

ハードウェア仮想化は封じ込めを改善するが、意図的にゲストへ転送されるすべての能力は攻撃面の一部となる。

smolvmは、軽量仮想マシンを起動するためにlibkrun VMMを使用する。ゲストは自身のカーネルを受け取り、ホストは仮想ハードウェアと公開されるデバイスを制御し続ける。

この設計は、コンテナに関する中心的な懸念に対処する。コンテナはカーネル機能を使ってワークロードを隔離するが、敵対的なプロセスは許可されたシステムコールを通じて、依然として同じホストカーネルとやり取りする。したがって、カーネルの脆弱性はコンテナ境界を脅かし得る。

microVMシステムは、その境界を外側へ移す。敵対的なコードが最初に接するのは、ゲストカーネルと仮想デバイスだ。ホストへ到達するには通常、仮想マシンモニターまたはハイパーバイザー境界を越える必要がある。

AWSは、サーバーレスワークロード向けに同様の原則に基づいてFirecracker microVMsを開発した。FirecrackerはKVM仮想化と意図的に縮小されたデバイスモデルを組み合わせ、不要なエミュレートハードウェアを制限する。

smolvmは単なるFirecrackerラッパーではない。現在のドキュメントでは、macOS、Linux、Windowsにまたがるlibkrunバックエンドが説明されている。それでも両アプローチは、各ワークロードを個別のゲストカーネルの背後に配置する。

この分離は、AIシステムが自律的にコードを書く場合に重要となる。生成コードには、意図しない破壊的な挙動、依存関係への攻撃、認証情報の探索、信頼できないデータからコピーされた意図的なペイロードが含まれ得る。

データ変換機能も、AIがなくても同じリスクに直面する。ユーザーは、ファイルシステムを走査し、繰り返しforkし、障害が起きるまでメモリを割り当て、外部接続を試みるPythonを送信できる。

JavaScriptが自動的に安全になるわけではない。Node.jsプログラムは、これらの能力が利用可能なままであれば、ファイルの読み取り、サブプロセスの開始、ソケットのオープン、ネイティブ拡張の読み込み、メモリの使い尽くしを行える。

言語レベルの制限だけでは、標準ライブラリが広範な機能を公開しているため、しばしば脆弱になる。推移的な依存関係がネイティブコードや予期しないアクセス経路を持ち込むこともある。

完全なLinuxゲストにより、開発者は特殊なランタイム向けに書き直すことなく、通常のPythonおよびNode.jsパッケージを実行できる。この互換性は、microVMが依然として魅力的である理由の1つだ。

その代償は、より大きなゲスト環境である。サービスはカーネル、ランタイムイメージ、ライブラリ、仮想デバイスを提供しなければならない。維持される各コンポーネントは、パッチ適用、再現性、信頼できるコンピューティングベースに影響する。

smolvmのドキュメントは、ホストOS、ハイパーバイザーバックエンド、libkrun、smolvm、そして呼び出し元のホストアカウントを信頼できるコンポーネントとして挙げている。これらの層で侵害が起きれば、約束された境界は弱まる可能性がある。

ドキュメントは、明示的な能力転送についても警告している。マウントされたディレクトリはその内容を公開する。ネットワークを有効化すると到達可能なサービスが増える。SSHエージェントを転送すると、ソケットが利用可能である間、ゲストプロセスは署名を要求できる。

開発マシンにとっては妥当な機能です。しかし、匿名または敵対的な投稿を処理するサービスでは、通常は無効のままにすべきです。

GPUアクセスには、さらに慎重な対応が必要です。smolvmは、ホストGPUリソースの共有やホスト側プロセスを伴うインターフェースをサポートしています。ドキュメントでは、CUDAリモーティングを堅牢なマルチテナントGPU分離として扱うべきではないとしています。

この制約は、単純なPythonのデータ変換ジョブには影響しません。しかしこれは、より広い原則を示しています。便利な機能は、基本アーキテクチャの魅力である明確なゲスト境界を越えてしまう可能性があります。

敵対的なワークロードに対しては、最も安全なプロファイルは意図的に地味なものです。ネットワーク、転送された認証情報、ホストサービス、GPUを使わず、最小限の読み取り専用入力と、使い捨ての出力領域だけを使用します。

VMは1ジョブごとに破棄すべきです。マシンを再利用すると、改変されたファイル、プロセス、キャッシュ、または隠れた状態が次のユーザーの実行に持ち込まれるリスクがあります。

ポータブルなイメージは、一貫したランタイムの確立に役立ちます。smolvmは、OCI image formatに基づくOCIイメージを使用しているため、運用担当者は使い慣れたパッケージング標準でPythonやNode.jsの環境を準備できます。

イメージの互換性は、イメージの信頼性を保証するものではありません。本番サービスには依然として、固定されたダイジェスト、管理されたレジストリ、脆弱性対応、セキュリティ更新後にランタイムを再構築するプロセスが必要です。

リソース制限にはCPUとメモリのフラグ以上が必要

最も難しい「while true」への対策は分離ではなく、あらゆる障害モードで確実に停止できることです。

メモリ設定は、ゲストから見えるRAMの上限を定めます。プログラムがその容量を超えると、ゲストカーネルはメモリ不足時の挙動を実行できます。これにより、ある種のリソース乱用を封じ込められます。

ただしホストは、その後に何が起きるかを監視する必要があります。ゲストは1つのプロセスだけを終了するかもしれず、応答不能になるかもしれず、あるいはメモリ回収に相当な時間を費やすかもしれません。サービスは、すべてのメモリ障害がきれいな結果を返すとは想定できません。

厳格なランナーは結果を分類すべきです。成功、ユーザー例外、メモリ枯渇、タイムアウト、出力超過、サンドボックス内部障害、ホスト容量不足による拒否は、それぞれ異なるイベントです。

この分類はユーザーと運用担当者の双方にとって重要です。構文が無効な変換スクリプトを、インフラ障害のように見せるべきではありません。起動に失敗したマシンが、ユーザーの再試行回数を消費してはなりません。

CPU制限には複数の層が必要です。ゲストには制限された仮想CPU数を割り当てられます。そのうえでcgroupsなどのホスト制御により、他のワークロードとの関係でVMMプロセスを制御できます。

デッドラインを監督する仕組みは、許可された時間が過ぎたらVM全体を終了させるべきです。プログラムは子プロセスやバックグラウンドプロセスを作成できるため、最上位のPythonまたはNode.jsプロセスだけを終了させても不十分です。

停止にはエスカレーションも必要です。監督機構はまず正常終了を要求し、ゲストが応答しなければVMMプロセスを停止できます。関連プロセスと一時リソースが消えたことを検証すべきです。

出力もリソースです。プログラムは無限に出力したり、巨大な結果ファイルを作成したり、実行終了後にパーサーのメモリを消費する深くネストしたデータを生成したりできます。

サービスには、標準出力、標準エラー、生成ファイルのバイト上限が必要です。アプリケーションメモリに無制限の内容をバッファリングせず、ログをストリーミングまたは切り詰めるべきです。

ストレージクォータは、ゲストの書き込み可能レイヤーと、すべてのエクスポート出力ディレクトリに適用する必要があります。そうしなければ、小さな入力でもホストのファイルシステムを埋め尽くすほどのデータを生成できます。

プロセス数も重要です。フォークボムは、人間の運用担当者が対応するより速くプロセスを作成します。ゲストカーネルにはプロセス制限が必要であり、ホスト側でもVMMとその補助プロセスを制約すべきです。

敵対的なプログラムは、CPUを飽和させずに時間を浪費することもできます。永遠にスリープしたり、存在しない入力を待ったり、デッドロックを作ったりするかもしれません。そのため、実時間に基づくデッドラインは依然として必須です。

時間は外部のコントロールプレーンで計測すべきです。ゲストは自身の時計を変更したり、内部のウォッチドッグプロセスに干渉したりできます。ホストの単調タイマーは、より信頼できる基準を提供します。

ファイルのエクスポートは、実行終了後にのみ行う必要があります。ホストは、結果を永続ストレージへ移動する前に、ファイルの種類、サイズ、パス、数を検査すべきです。

一般的なデータ変換では、より狭い出力契約によってリスクを減らせます。ランナーは任意のディレクトリツリーではなく、1つのJSONドキュメント、1つのCSVファイル、またはサイズを制限したアーカイブだけを受け付けるようにできます。

サービスはマシンを起動する前に、入力の複雑さも制限すべきです。圧縮アーカイブはアップロード時のサイズをはるかに超えて展開されることがあり、悪意ある形式はゲスト外のパーサーを標的にする可能性があります。

したがって、安全な手順はsmolvmより前から始まります。入力を検証してステージングし、新しいマシンを作成し、実行時制限を適用し、マシンを停止し、出力を検査してから、一時的な状態を破棄します。

可観測性もゲストの外部に置くべきです。運用担当者には、マシン識別子、イメージダイジェスト、開始・終了時刻、終了分類、リソース使用量のピーク、クリーンアップ状況が必要です。

こうした記録には、デフォルトで機密性の高いユーザーデータを保存しないようにすべきです。スクリプトが入力レコード、認証情報、または独自コンテンツを出力すると、ログも別の情報漏えい経路になり得ます。

これらの要件は、smolvmの価値を否定するものではありません。低レベルのプリミティブを信頼できるサービスへ変えるために必要な周辺作業を定義するものです。

Docker、WebAssembly、ホステッドサンドボックスも依然として競合する

smolvmは、共有カーネルのコンテナより強い分離と、通常のLinux互換性を両立する有用な中間的立場にあります。

Dockerは、多くのエンジニアリングチームにとって最も導入しやすい出発点であり続けています。イメージ、レジストリ、ビルドツール、オーケストレーションシステムは、すでに大規模なコンテナワークフローを支えています。

コンテナでは、名前空間、ケイパビリティ、seccompフィルター、読み取り専用ファイルシステム、cgroup制限を適用できます。こうした制御は、ワークロードが信頼されている場合や、リスクが中程度にとどまる場合には適切です。

完全に敵対的なコードでは、共有カーネルが依然として中心的な懸念です。ホストカーネルまたはコンテナランタイムのエスケープ脆弱性により、他のワークロードやホストデータが露出する可能性があります。

smolvmは、各マシンに別個のゲストカーネルを割り当てることで、この露出を変えます。またOCIイメージを受け入れるため、既存のPythonやNode.js環境を持つチームにとって、移行時の摩擦をある程度減らせます。

ただし、コンテナプラットフォームには成熟したスケジューリングおよびポリシー層があります。smolvmのセキュリティドキュメントでは、スタンドアロンツール自体は堅牢なマルチユーザー向けコントロールプレーンではないと述べています。

コンテナをsmolvmへ置き換えるチームは、その移行によって運用上の安全策を失わないようにしなければなりません。より弱いスケジューラーの下により強い分離を置いても、信頼性の低いサービスになり得ます。

WebAssemblyは別の経路を取ります。WebAssemblyランタイムは制約されたケイパビリティモデルから始まり、ファイルやネットワークへのアクセスといった機能を明示的に許可します。

このアプローチでは、コンパクトな変換ワークロードに対してより小さなインターフェースを実現できます。また、高速な起動とアプリケーションへの精密な埋め込みもサポートします。

トレードオフは互換性です。標準的なPythonやNode.jsパッケージは、制限されたWebAssembly環境では利用できないLinuxシステムコール、ネイティブ拡張、サブプロセス、ランタイム挙動を期待する場合があります。

変換言語を管理するチームは、こうした制約を受け入れられるかもしれません。幅広いPythonおよびJavaScript互換性を約束するサービスは、すぐにそれらの制約に直面します。

ホステッドコードサンドボックスは第3の道を提供します。ベンダーは、マシンライフサイクル、タイムアウト、ネットワークポリシー、ストレージ、APIをマネージドサービスとしてまとめています。

これにより実装期間を短縮できます。一方で、機密性の高いコードやデータを別の運用者へ移すことになり、サービスへの依存関係が生じ、基盤となる分離設計の制御も制限されます。

smolvmをセルフホストすれば、ランタイムは購入者の管理下に置かれます。同時に、ホストの堅牢化、セキュリティ更新、容量計画、監視、インシデント対応の責任も購入者が負うことになります。

選択は流行ではなく、ワークロードに従うべきです。制約された式評価器に完全なLinuxゲストは必要ありません。ネイティブ依存関係を持つ複雑なPythonパッケージには、おそらく必要です。

ワンショット変換では、microVMの起動時間をジョブ実行時間に比べて小さく保つ必要があります。smolvmによれば、パッケージ化されたワークロードは200ミリ秒未満で起動できますが、独立した測定では購入者の実際のホストとイメージを対象にするべきです。

ベンチマークには、コールド状態でのイメージ取得、マシン作成、ランタイム起動、入力ステージング、実行、出力検証、破棄を含めるべきです。ゲストの起動時間だけを測定すると、ユーザーに見えるレイテンシを過小評価します。

チームは密度もテストすべきです。1台のゲストが高速でも、メモリ圧迫下で何百もの同時投稿を実行するホストについては、ほとんど何も分かりません。

したがって競争上の問いは、分離強度だけにとどまりません。互換性、起動挙動、スケジューリングの成熟度、運用負荷、エスケープ成功時の影響も含まれます。

smolvmは、使い慣れたLinuxワークロードとVM境界を組み合わせるため、評価に値します。anthropic simon attemptは、このような評価が必要な仮想化機能を公開できるインフラ上で行われなければならないことを示しています。

smolvmの準備状況を決める3つのテスト

次に有用な証拠は、別の機能チェックリストではなく、敵対的ワークロードによるテストから得られる必要があります。

第1の指標は、互換性のあるベアメタルまたはネステッド仮想化ホストで再現可能なテストです。同じ外部監督機構を通じて、PythonとJavaScriptの両方のスイートを実行すべきです。

これらのスイートには、無限ループ、メモリ枯渇、フォークボム、過大な出力、ファイルシステム探索、ネットワーク探索、遅延した子プロセス、異常なゲスト終了を含めるべきです。すべてのケースに期待結果が必要です。

成功すれば、smolvmが変換ジョブの分離エンジンとして利用できるという主張を強めます。クリーンアップ失敗の繰り返しや停止動作の不整合があれば、その主張は弱まります。

第2の指標は、明示的で文書化されたライフサイクル強制です。リファレンスランナーは、実時間デッドライン、ホストレベルCPU制御、メモリ上限、出力クォータ、完全なマシン破棄をどのように課すかを示すべきです。

設定フラグだけでは不十分です。ゲストがシャットダウン要求を無視する場合、ストレージを埋め尽くす場合、子孫プロセスを残す場合の挙動をテストで検証すべきです。

この指標により、smolvmのVMプリミティブとWillisonが当初検討したかったサービスとの間にある隔たりを埋められます。これがなければ、導入者はそれぞれ重要な監督機構を独自に設計しなければなりません。

第3の指標は、明示された脅威モデルの下でのセキュリティレビューです。レビューでは、信頼されるホストコンポーネント、マウントされたファイルの挙動、ネットワーク強制、イメージの来歴、マルチテナント前提を特定すべきです。

smolvmの既存ドキュメントは、すでに有用な開示を行っています。リリースには現在、署名と来歴証明がない一方、チェックサムファイルをダウンロードできる場合にはチェックサム検証が可能だとしています。

この開示により、評価者はサプライチェーンについて具体的な問いを持てます。本番運用者には、smolvmバイナリとゲストイメージを取得、検証、固定、更新するための管理された方法が必要です。

評価では、ローカルの単一ユーザー実行と、敵対的なマルチテナントも区別すべきです。ノートPCで生成コードを実行する開発者と、匿名投稿を受け付ける公開サービスとでは、影響が異なります。

どのサンドボックスも、任意のコードをリスクのないワークロードに変えることはできません。実践的な目標は、多層的な封じ込め、制御されたケイパビリティ、制限されたリソース消費、そして1つの層が失敗した際の迅速な復旧です。

最も有望なデプロイパターンは、そのシステムの1層としてsmolvmを使用します。ホストサービスは入力を検証し、使い捨てのゲストを作成し、ネットワークアクセスを与えず、デッドラインを強制し、出力を確認して、環境を破棄します。

AIワークフローを構築するチームにとって、この教訓はコード実行の範囲にとどまりません。モデルがローカル情報にアクセスして行動できるシステムには、モデルが読み取り、書き込み、保持できるものについて明確な境界が必要です。

検索可能なナレッジベースは、エンジニアがテスト結果、脅威モデル、インシデントの知見を蓄積する助けになります。実行時の隔離に取って代わるものではありませんが、セキュリティ上の判断を監査しやすくできます。

したがって、Anthropic Simon experiment は、有用な最初の知見を得たものの、未完了の評価として扱うべきです。smolvm は、外側のサンドボックスが仮想化へのアクセスを許可しなかったため、選定された Claude Code 環境内では実行できませんでした。

次にすべきことは、その外側のサンドボックスを緩和することではありません。外部スーパーバイザーと公開された敵対的テストスイートを備えた、専用の互換ホスト上で評価を繰り返すことです。

ゲストが悪意ある状態になった場合でも、サービスはすべてのジョブを停止し、承認済みの出力だけを保持し、完全にクリーンアップできるでしょうか。その答えが測定されていないなら、そのサンドボックスはユーザーコードを実行する準備ができていません。