Engineering · セキュリティ

agens の封じ込め設計 — サンドボックスは1種類ではない。仕事ごとに“被害の範囲”で強度を選ぶ

実行型AIを安全に任せる鍵は、危険を完璧に予防することではなく、万一のときに被害が及ぶ範囲（blast radius）を構造で小さく抑えること。封じ込めは1種類ではなく、仕事ごとに“ちょうどいい”強度を選びます。

強度は“仕事”で選ぶ

強い隔離ほど安全ですが、用意や運用の手間も増えます。だからすべてを最強の隔離で動かすのではなく、仕事の性質に応じて“ちょうどいい”強度を選ぶのが現実的です。

目安は3つ。扱うデータの機密度（高いほど強く）、任せる人の習熟度（不慣れなほど強く）、操作の取り返しのつかなさ（戻せないほど強く）。この3つで、その仕事に必要十分な封じ込めを決めます。

業界でも、実行環境は隔離方式によって強度と軽さのトレードオフが分かれます。コンテナをカーネルごと分ける方式（AWS の Firecracker などの microVM）は隔離が強く、共有カーネルのコンテナ方式は起動が速い、という具合です。エージェント向けの実行サンドボックスを提供する E2B・Daytona・Modal・Cloudflare なども、それぞれ異なる強度の選択肢を用意しています。どれが正解ということではなく、仕事に合わせて選ぶものです。

「許可した宛先」でなく「許可した“操作”」で絞る

封じ込めで見落とされがちなのが、通信の許可リスト（allowlist）の捉え方です。「この宛先（ドメイン）は許可」とだけ決めると、実はその宛先で“できること”すべてを許可したことになります。あるサービスのドメインを許可しただけのつもりが、そのサービス上のファイルアップロード機能まで開いてしまう——つまりデータの持ち出し経路を与えてしまう、ということが起こり得ます。Anthropic も前述の記事で、許可ドメインを“宛先のフィルタ”と捉えていたために許可先の全機能が開いていた、と振り返っています。

だから agens は、外部への送信を既定で絞り、許可した宛先・操作の範囲だけに限ります。「宛先」ではなく「できる操作」の粒度で考えるのが、持ち出しを防ぐ要点です。

信頼している相手の操作でも、最後に効くのは“境界”

もうひとつの教訓は、「信頼できる相手だから安全」とは限らない、という点です。AIに紛れ込む不正な指示（プロンプトインジェクション）を見分けるモデル側の仕組みは、利用者本人の意図を手がかりにします。だから、もし悪意ある指示が“本人の操作”として入ってくると、振る舞いベースの検知はすり抜けやすくなります。

こうした“確率的な防御が全部外れたとき”に最後に効くのが、決定論的な環境の境界です。隔離されていれば、何が起きても被害はその箱の中にとどまります。agens が監査ログ・操作の巻き戻し・異常時の自動停止まで備えるのは、「起きないようにする」だけでなく「起きても被害を局所化し、後から戻せる」ためです。

関連