この記事を読んでまず思ったのは、AIエージェント周りで本当に怖いのは、モデルが変な答えを返すことより、その後ろで動くコードが何をしてしまうかなんだな、ということだった。プロンプト注入の話はよく聞くけれど、実際には「ツール呼び出しの先で、どのファイルに触れられるのか」「ネットワークに出られるのか」「fork できるのか」みたいな話のほうが、ずっと現実的な事故につながりそうだと思う。
Ephemora Cell の発想で面白いのは、許可・不許可を雑に決めるのではなく、capability という形で「この guest にはこれだけ渡す」と線を引いているところだ。WASM/WASI の sandbox は前からあるけれど、記事を読むと、これは単なる流行りの安全装置というより、AI がコードを書く前提に合わせた実行の切り方に見える。特に、MCP tool も「JSON schema だけじゃなくて実コードだ」という指摘にはうなずいた。見た目は API っぽくても、裏では普通に危ない処理が走る。そこを同じ箱に閉じ込めるのは筋がいい。
一方で、記事がかなり丁寧に「これは万能ではない」と釘を刺しているのも好感が持てた。8つの攻撃プリミティブを 0/8 で止めた、という数字は強い。ただ、その数字だけを見て安心すると危ない。どの攻撃を数えたのか、どこまで再現できるのか、WASI の境界で取りこぼすものはないのか。そういう疑いを持って読ませる書き方になっていて、そこは信用できると感じた。逆に言うと、こういう領域では「安全です」と大きく言い切る人より、「壊しに来てほしい」と言う人のほうが頼れるのかもしれない。
気になったのは、性能の話がかなり重要そうに書かれている点だ。サンドボックスは安全でも遅いと結局使われない。毎回コンテナを起動するのは重いから、warm な per-call isolation を狙う、というのは現場感がある。AI の tool call は細かく何度も走るので、ここが重いと実用にならないはずだ。安全性と速度を両立させたい、というより、両立させないと最初から選ばれない、という事情が透けて見えて、その切実さはよく分かった。
最後に残った印象は、「信頼をモデルに預けないで、実行境界に預けようとしている」記事だった、ということだと思う。AI の賢さを上げるより、その出力が触れる範囲を先に絞る。地味だけれど、たぶん本当に必要なのはこっちなんじゃないか、という感覚がある。
参考: Ephemora Cell: a capability-based WASM sandbox for untrusted AI code
