導入の前提条件
キルスイッチを検討する前に、エージェントに与える権限・環境・リソースを万が一侵害されても重大な影響が出ないように構成しておく必要があります。取り組むべき事項はエージェント実行基盤にまとめていますが、キルスイッチとの関係で特に重要なのは次の4点です。- 誤作動が他の環境へ影響を広げないためのサンドボックス分離とネットワーク許可リスト
- 最小権限の原則に基づく権限付与と、ツールごとのBlast Radiusの特定・最小化
- リソース変更の回復可能性を常にトラッキングして維持すること
- 入力と出力・ツール実行・ネットワーク通信をカバーする多層の監査ログ
独立した制御プレーンとして設計する
キルスイッチと聞くと単一のボタンを想像しがちですが、実際には検知・判断・強制・証跡保全・巻き戻しといった機能を、エージェントの外側にある制御プレーンとして実装するものです。システムプロンプトに特定条件下で停止するよう書いてもモデルはコンテキスト内の指示を確率的に無視し得るため、停止機構はエージェントを動かすプラットフォーム側に構成する必要があります。 制御プレーンはエージェント本体から独立させ、エージェントと外部連携の双方を制御します。その際に少なくとも次の3原則を満たします。- 非バイパス性としてエージェントと外部連携のすべてがキルスイッチの制御下にあり、迂回できないこと
- 到達不能性として制御プレーンがエージェントの把握・操作できる範囲の外にあり、エージェントが制御機構を変更できないこと
- fail-closedとして制御プレーンが停止・分断された場合に、エージェントが動き続けるのではなく止まる側に倒れること
停止をスコープと強度で段階化する
停止トリガーでプロセスを一律に止めるだけでは、複数人のリクエストを処理している場合に他の利用者へ影響が及び、実行途中の処理の中断や呼び出し済み外部APIの未処理といった副作用も残ります。そのため停止はスコープと強度の2軸で段階的に設計します。 スコープは個別の実行単位・特定のエージェント単位・特定のツールや接続先単位・全体といった粒度を用意し、最小の有効範囲から封じ込めを検討します。強度は監視の強化・人間承認への昇格・読み取り専用化・新規行動の拒否・認証情報の失効・ネットワーク遮断といった段階を用意します。セッションごと止めても影響が小さいケースでは実行単位で止める一方、完全停止の副作用が大きいケースでは、エージェントを止め切らずに被害拡大だけを防ぐ読み取り専用モードの強制のような中間段階も検討します。発動条件を決定的判定と非決定的判定で構成する
ユーザーが自由に押せるボタンを用意しても、停止判断とタイミングを人間に委ねることには大きな困難が伴います。バックグラウンドで動くエージェントでは動作がそもそも見えず、ボタンを押せません。そのため発動条件は自動化された判定として実装し、決定的判定と非決定的判定を組み合わせます。 決定的判定は、特定のツールを特定の引数で呼び出そうとしたら拒否する、許可リスト外の接続先への通信を遮断する、実行回数や消費リソースの上限超過で停止するといった、ルールとして機械的に評価できるものです。非決定的判定は監視エージェントによる逐次評価や、出力内容・行動パターンの異常検知です。想定外の異常を捕捉できる一方で判定に時間がかかり、誤検知と見逃しの両方が起こり得ます。 判定のタイミングにも注意が必要です。ツール呼び出しの実行前に異常を検知して止められれば被害を防げますが、呼び出し後の検知では間に合いません。またエージェントの自然言語出力そのものが悪影響になり得る場合、ストリーミング出力が常にユーザーへ表示されている限り、検知した時点で内容は公開済みです。個人情報など機微な情報を扱うエージェントでは、ストリーミング出力をそのままユーザーへ露出させず、判定を挟むためのバッファリングや遅延表示を許容する設計が必要になります。ここでは安全性とUXのトレードオフを考慮することになります。強制手段を即時性の異なる多層で用意する
外部サービスの権限剥奪や認証情報の無効化がAPI呼び出しに反映されるまで5〜10分程度かかることがあり、権限剥奪だけでは直ちに動作を止められません。その間にリソースへの影響が発生し得るため、強制手段は即時性の異なる多層で設計します。- ツールゲートウェイでの拒否は、ツール実行を止めることでリソース操作を即時に防止します
- 認証情報の失効は伝播遅延があるため、即時停止ではなく以後の再開を防ぐ手段と位置づけ、重大インシデント時に継続的な停止が必要な場合に用います
- ネットワーク遮断は、ツールを経由しないコマンド等を介した通信に対する最終手段として機能します
改ざん不能な証跡を事前に残す
監査ログがなければ、停止した後に途中まで実行されていたリソース変更の特定や影響範囲の調査ができません。停止時点で次の問いに答えられる証跡が事前に記録されている必要があります。- どの入力・指示から始まった実行だったか
- どのツールをどの引数でどこまで呼び出したか
- 呼び出し済みの外部APIのうち完了したもの・進行中のもの・結果不明のものはどれか
- 変更されたリソースはどれで、それぞれ巻き戻し可能か