AWS Strands Boxが示す、AIエージェントを隔離と許可の二段構えで守る設計
ニュースの概要
AWSのStrands Agentsチームが、オープンソースの「Strands Box」を公開した。狙いは、AIエージェントが人間の承認を待たずに危険な操作を実行してしまう、いわゆるYOLOモード（＝確認なしで何でも実行させる設定）を抑えることだ。仕組みの核はAWS Lambdaのマイクロ仮想マシンである。エージェントごとにカーネルを分けて隔離するだけでなく、実行するコマンド一つひとつに方針（ポリシー）を当てはめる点が特徴とされる。紹介記事の根底には、コンテナやマイクロVMに閉じ込めるだけでは足りないという問題意識がある。箱の中でエージェントが破壊的な操作をできてしまえば、被害は箱の中の資産に及ぶからだ。隔離と許可の制御を組み合わせる設計思想が、今回の公開の要点である。
引用元: AWS、AIエージェントの実行を制御するオープンソースのStrands Boxを公開（AWS Builder）
分析・見解
「閉じ込めるだけ」では守れないという発想の転換
従来、AIエージェントの安全対策といえば、コンテナやマイクロVM（＝軽量な仮想マシン）に入れて外へ出さないことだった。家の鍵を頑丈にする発想である。しかし、家の中に大事なものを置いたまま住人が勝手に壊すなら、鍵では防げない。エージェントは箱の中でもファイルを消し、認証情報を読み、外部へ送信できる。Strands Boxが問題にしたのは、この「箱の中での振る舞い」である。
二段構えの設計：カーネル隔離とコマンド単位の許可
カーネルとは、OSの中核部分のことだ。エージェントごとにカーネルを分ければ、一つの暴走が他のエージェントや土台の基盤へ波及しにくくなる。Lambdaのマイクロ仮想マシンは、他社のコードと同居しても壊れないように作られた技術で、その実績を流用できるのは大きい。さらにコマンド単位のポリシー適用が加わる。たとえば「読み取りは許可、削除は承認待ち、外部通信は拒否」といった線引きを一件ずつ行う。空港で、建物に入る検査と搭乗口ごとの確認を二重に行う構造に近い。
YOLOモードが生まれる本当の理由
YOLOモードが使われるのは、利用者が怠けているからではない。承認ボタンを押す回数が多すぎて、人間が確認疲れを起こすからだ。毎回の承認は安全に見えるが、実際には惰性の「はい」を量産する。ポリシーで安全な操作を自動で通し、危険な操作だけを人間に回せば、承認の回数が減り、一回あたりの重みが戻る。ここが本件の最も面白い点だと考える。安全機能は、使われなければ無意味である。使いやすさを上げることが、結果として安全性を上げるのだ。
他の隔離技術との位置づけと残る課題
smolvmのようなローカル向けマイクロVMも、同じ隔離の系譜にある。違いは、実行の場所がクラウドか手元かという点だ。一方で、ポリシーの質は書く人次第である。許可を緩く書けば、隔離は飾りになる。また、コマンドの文字列だけを見る方式では、スクリプトの中に危険な処理を隠されると見抜きにくい。コマンド単位の制御が万能でないことは、導入前に理解しておきたい。今後は、ポリシーの雛形の共有や、実行記録を使った自動調整が競争の焦点になるだろう。
ビジネスへの影響
導入前に決めておくべき三つの線引き
エージェントを業務で動かすなら、最初に操作を「読むだけ」「元に戻せる」「元に戻せない」の三つに分類したい。読むだけは自動で通し、戻せる操作は記録を残して通し、戻せない操作は必ず人間の承認に回す。この分類ができていれば、Strands Boxのような仕組みのポリシーにそのまま写し取れる。分類が曖昧なまま導入すると、すべて承認待ちか、すべて許可かの両極端に陥りやすい。
小さく試して、承認の回数を測る
最初から全社に広げず、開発用の使い捨て環境で一つのエージェントを動かすのが現実的だ。見るべき指標は、一日あたりの承認回数と、そのうち本当に止めるべきだった件数の比率である。止めるべき件数が1割に満たないなら、ポリシーが厳しすぎる可能性が高い。数字で見直せば、感覚の議論を避けられる。
基盤の選択は運用体制で決まる
AWS上で運用を完結させたい企業にはLambda基盤が合う。機密データを社外に出せない場合や、手元で素早く試したい場合は、ローカルで動くマイクロVMが候補になる。どちらでも「隔離」と「許可制御」を分けて考える視点は共通だ。経営層には、事故が起きてから対策を論じるより、事故が起きても被害を箱の中に限る設計を先に求めるべきだと伝えたい。