概要
https://www.luiscardoso.dev/blog/sandboxes-for-ai
詳細内容
## AIエージェントのためのサンドボックス構築ガイド
https://www.luiscardoso.dev/blog/sandboxes-for-ai
**Original Title**: A field guide to sandboxes for AI
AIエージェントが実行する未知のコードからシステムを保護するため、隔離レベルの異なるサンドボックス技術の特性と選択基準を体系的に提示する。
**Content Type**: 🔬 Research & Analysis
**Language**: en
**Scores**: Signal:5/5 | Depth:5/5 | Unique:4/5 | Practical:5/5 | Anti-Hype:5/5
**Main Journal**: 96/100 | **Annex Potential**: 94/100 | **Overall**: 96/100
**Topics**: [[サンドボックス, セキュリティ, AIエージェント, MicroVM, WebAssembly]]
AIエージェントが生成・実行するコードは、事実上の「未知のマルウェア」として扱う必要がある。著者は、エージェントによるSSHキーの窃取や内部ネットワークへの侵入といったリスクを回避するため、サンドボックス技術を「境界（隔離の場所）」「ポリシー（操作権限）」「ライフサイクル（持続性）」の3つの軸で評価するフレームワークを提唱している。
記事では、現在主流の4つの隔離境界について、システムコールの扱いという技術的深部から比較を行っている。標準的なコンテナはホストカーネルを共有するため、カーネルの脆弱性を突いた攻撃に対して脆弱だが、gVisorはユーザ空間でシステムコールを再実装することで露出を抑える。さらに強力な境界として、FirecrackerなどのMicroVMが挙げられており、これはハードウェア仮想化によって独立したゲストカーネルを提供しつつ、高速な起動とスナップショット機能を実現している。著者は、マルチテナントで信頼できないコードを実行する環境では、このMicroVMが事実上の標準であると論じている。
一方、WebAssembly（Wasm）やV8 Isolateのようなランタイムサンドボックスは、OSのシステムコールABIを一切持たず、ホストが明示的に提供した「ケパビリティ」のみを許可するモデルを採用している。これは軽量かつ安全だが、既存のバイナリやライブラリとの互換性に制約がある。
著者は結論として、単一の「最強の技術」を選ぶのではなく、ワークロードに応じた使い分けを推奨している。例えば、シェルやパッケージマネージャが必要な複雑なタスクにはMicroVMを、特定のツール実行にはWasmを、そして信頼できる内部処理にはコンテナを割り当てるべきだとしている。また、開発者のローカル環境においても、macOSのSeatbeltやLinuxのLandlockといったOSネイティブの機能を活用し、エージェントの権限を最小限に絞る「セルフサンドボックス化」の重要性を説いている。Webエンジニアにとって、AIエージェントの構築は単なるAPI連携ではなく、セキュアなコード実行基盤の設計というOSレイヤーの課題を再認識させるものであると示唆している。