WebAssembly / Wasm Advent Calendar 2025 23日目の記事です。
今日は思い出すシリーズです😅
軽くおさらいをすると、AI Agent に自由にコマンドを発行させると危険という話がありました。 rm -rf /* は極端ですが、全く意図しない場所にあるファイルを削除・改変されることはあり得ます。
- エージェントの実行するコマンドをいちいち確認・許可すればいい
- 結局それは人間側の認可ミスもありうるわけで、もっと仕組みで解決したい
- サンドボックスの機構を使えばいいという話もある
- でも、たとえばDockerの中でAgentを... とかは結構面倒では？ オーバーヘッドもあるし。
もっと軽量かつ汎用的なサンドボックスの機構を... といったところでWasmの話を前回したんですが、その時はエージェント自体をWasmで実装しようとしていました。
ですが、エージェントが利用するコマンドがWasmでできていれば安全性は確保できるんじゃね？ と思い至りました。そのアプローチを試す回です。
WASIによるファイル操作
さて、WASIの説明からはいるのですが、なんかシステムコール？的な？... あれ。この記事で細かく説明しなくていいですかね...。
自分が昔作った図を貼っとこう。
wasmtimeのようなコマンドでシステムを操作する際もWASIを経由しています。ただ、デフォルトではホストのファイルは何も操作ができない。
$ wasmtime --dir /Users/foobar/workspace delete_everything.wasm
このように --dir <HOST_DIR[::GUEST_DIR]> を明示的に渡さない限りホストのファイルシステムに何かしらの操作（参照、編集、削除）はできません。コンテナ感がありますね。
Wasmによるrmコマンド
を作ってみます。
初めは uutils のrmコマンドを wasm32-wasip1 でビルドすればいんじゃね、と思ってましたが少し前に試した感じ全然うまくいきませんでした。そのうち対応されるのかもですが。
で、最低限のオプションを持った rm コマンドをAIに作らせました。
イメージとしては以下のようなシェルスクリプトの rm を経由して、
#!/usr/bin/env bash
RM_WASM_PATH=${RM_WASM_PATH:-target/wasm32-wasip1/release/rm.wasm}
wasmtime --dir `pwd` --env PWD=`pwd` $RM_WASM_PATH "$@"
こういう感じで実行します。ちなみに -R は実装していない。
$ touch hoge $ ./rm.sh -v hoge removed '/Users/udzura/ghq/github.com/udzura/wasi_rm/hoge' $ ./rm.sh hoge rm: cannot remove 'hoge': No such file or directory (os error 44) $ ./rm.sh -f hoge
ここで、現状 wasmtime は「現在のディレクトリ」をうまく指定することができない（WASI p2で提案中？）っぽいので、環境変数 PWD を経由して相対ファイルパスを解決させるようにしました。
エージェントに使わせてみるとどうなる？
以下のように $PATH 環境変数を上書きして gemini を起動します。
cp rm.sh ~/.local/bin/rm chmod +x ~/.local/bin/rm export PATH=~/.local/bin:$PATH touch ~/secret.txt gemini
今、自分の環境で実行させてみた結果です。
うまくサンドボクシングできてそうです。
まとめ
個別のコマンドをWasm化するの、それなりに需要があるんじゃないかなという気持ちになりました。実装量は半端ないですが、やるだけではあるので...。
LLMに詳しくないため、今日日のコーディングエージェントならもっといい感じのやり方がある気もしますが、追えていません！ あくまで思考実験という感じで。
どうしてもしなければいけない宣伝
福岡でRubyに関するカンファレンスをするので行きましょう。WebAssemblyの話はないんですが...。VMを自作している人の話はあります（？）。あと僕はいるので、僭越ながら僕とWebAssemblyの話しましょう。
