1月26日、Simon Willison氏が「the browser is the sandbox」と題したブログ記事を公開した。この記事では、Webブラウザをコーディングエージェント用の実行環境（サンドボックス）として活用し、ローカルPCの安全性を保ちながら信頼できないコードを扱う手法について詳しく紹介されている。

以下に、その内容を紹介する。

Googleのウェブプラットフォーム デベロッパー・アドボケイトであるPaul Kinlan氏は、AIエージェントが生成・実行するコードの安全性を確保する手段として、Webブラウザの再評価を提案している。ブラウザは長年、 出所の不明なコードを即座に、かつ安全に実行するための「究極のサンドボックス」として進化してきた からだ。

Kinlan氏が提唱する、サンドボックスを構成する主要技術とその役割は以下の通りである。

サンドボックスを支える要素技術

File System Access APIによるアクセス制御

ブラウザからローカルのファイルやディレクトリを直接操作することを可能にするこのAPIは、サンドボックスにおいて「権限の最小化」を担う。ユーザーが明示的に選択した特定のフォルダのみにアクセスを制限できるため、エージェントがPC内の全データに勝手にアクセスすることを防ぎつつ、必要な作業領域だけを安全に提供できるのが大きな利点である。

また、主要ブラウザ（Firefox、Safari、Chrome）で広くサポートされている <input type="file" webkitdirectory> も有用だ。

これはディレクトリ全体への「読み取り専用アクセス」を一度の操作で許可するもので、エージェントにプロジェクト全体の構造を安全かつ効率的に読み込ませる手法として、極めて実用的である。

CSPヘッダーとiframe sandboxによる境界構築

コンテンツ・セキュリティ・ポリシー（CSP）は、そのページが通信できるドメインを厳格に定義する仕組みである。これを <iframe> の sandbox 属性と組み合わせることで、実行されるコードの権限をさらに細分化できる。これらにより、エージェントが外部の悪意あるサーバーにデータを送信（データ流出）することを構造的に遮断する。

「二重iframe手法」によるネットワークの完全封鎖

Kinlan氏のテクニックで特に興味深いのが、この「二重iframe手法（double-iframe technique）」である。通常、一つのiframeに強固なCSPを適用しようとしても、親ページからの制約を完全に引き継ぐことが難しいケースがある。

そこで、まず一つ目のiframe（外側）を作り、その中にもう一つのiframe（内側）を配置する。外側のフレームに特定のCSPを設定し、内側のフレームを「別オリジン（unique origin）」として扱うよう強制することで、内側で実行されるコードのネットワークアクセスを、ブラウザのセキュリティモデルを利用して完全に封鎖することが可能になる。これは、信頼できないコードを「箱の中の箱」に閉じ込めることで、通信の自由度を極限まで奪う高度な防護策である。

Web WorkersとWebAssemblyによる実行環境の分離

メインスレッドから独立して動作する Web Workers 上で、バイナリ形式の WebAssembly (Wasm) を実行する手法は、計算処理の「論理的隔離」を実現する。
Wasmはホスト環境のメモリやリソースに直接アクセスできないよう設計されており、万が一実行中のコードが暴走したり悪意のある挙動を見せたりしても、ブラウザのメインプロセスやOS本体への波及を防ぐ強固な防壁として機能する。

これらの技術を統合し、実用性を示したのがデモアプリ「Co-do」である。

Co-doは、数GBにおよぶ巨大なローカルコンテナ（Docker等）を起動することなく、ブラウザ標準の機能だけでセキュアな作業空間を実現している。ユーザーが指定したディレクトリに対してのみ、プロバイダー経由で安全にツールを実行できる仕組みだ。

まとめ

この記事は、独自のサンドボックス環境を一から構築する代わりに、すでに高度なセキュリティ機能を備えたブラウザを「エージェントの実行基盤」として活用するという、合理的かつ強力なアプローチを提示している。

詳細はthe browser is the sandboxを参照していただきたい。