エージェントキルスイッチの設計と運用
非決定的な動作をするエージェントがより強力な権限を扱うようになり、外部からのAgent Goal Hijackingの影響を受けたり通常の処理の中で誤作動したりした場合の影響範囲が広がってきています。
そのため、エージェントの動作による破壊的な変更を阻止する手段の一つとして、キルスイッチ機能が度々話題に上がっています。実際にAnthropicから新機能のInference hooksがリリースされるなど、エージェントのキルスイッチ機能を支えるエコシステムの拡充も進んでいます。
一方で、キルスイッチの導入は基本的なエージェントセキュリティのエコシステムの成熟が前提であり、キルスイッチ自体を銀の弾丸として扱わないことも非常に重要です。エージェントのセキュリティエコシステムの発展と、その先にあるキルスイッチの必要性・効果・実装方法をまとめていきます。
エージェントセキュリティのロードマップ
エージェントはファイルシステム操作・コマンド実行・外部サービスとのMCP連携など、さまざまなツールへアクセスできます。結果として各種リソースの取得・変更・削除が可能になり、こうしたエージェントが誤作動すると深刻な悪影響を招き得ます。実際に組織内外で社内データベースが破壊された、エージェントが外部インフラストラクチャを攻撃したといった報告もあります。
このような背景から、誤作動などで意図しない動作が起きた際にエージェントの行動を停止して安全を確保するキルスイッチ機能に注目が集まっています。ただしキルスイッチによる安全性向上は自然な発想であるものの、正しく動作させるための実装・運用方法や、エージェント活用を前提とした停止措置の扱いといった周辺課題は十分に整理されていません。
また、キルスイッチ導入の前提として、エージェントのセキュリティを確認・確保するために取り組むべき事項は数多くあります。詳細はAgent Platform Security Checklistにまとめられていますが、主に次のような点が挙げられます。
- システムプロンプトでの特定の行動を禁止する指示
- 特定の変更の実施前に人間による承認となるHITLを要求する
- エージェントが取り扱う環境をサンドボックスとして分離する
- 外部ネットワーク接続を許可リストで管理する
- ファイルシステム分離により、意図しないファイル変更の影響範囲を狭める
- エージェントが操作する範囲内で機密情報を直接扱わないよう、MITMプロキシを用意する
- 付与する権限は最小権限の原則に従って必要最小限にする
- Confused deputy problemを避けるため、エージェントのセッションを特定の指示者に紐づけ、OAuthを用いて個人権限をベースにする
- 付与したツールによるBlast Radiusを正確に特定して最小化する
- リソース変更時の回復可能性を常にトラッキングして維持する
- 入力と出力・ツール実行・ネットワーク通信といった複数レイヤーの監査ログを導入する
- 導入ライブラリ等の展開によるマルウェア混入を念頭に置いたランタイム監視を行う
- Agent Goal Hijacking等の意図しない指示を検知したりツール呼び出しの正当性を確認したりする自動検証エージェントを構築する
このように多角的なセキュリティ対策が必要とされます。基本的な考え方として、エージェントに与える権限・環境・リソースは万が一侵害されたとしても重大な影響を与えないように構成することが重要です。
つまり誤作動が起きても他の環境へ影響を広げないためのサンドボックス化、リソース変更の回復可能性の継続的な担保、他者のリソースを本来アクセスできない対象へ不正に誘導させない工夫、そして誤作動やマルウェア混入などのインシデント時の可視性の担保といった対応が求められます。
これらの対策を十分に行ったうえで、さらにエージェントの動作に一定のコントロールを持ちたい場合や、外部システム等の制約によって回復可能性を十分に維持できず破損時のリスクを受容できない場合に、キルスイッチ導入の機運が生まれます。キルスイッチは銀の弾丸ではありません。影響範囲を十分に絞ったうえでの次の一手として、リスクをゼロにするものではなく低減するための手段です。決定的な対策だけでなく非決定的な対策も含み得るため、どのような対策なのかを言語化して構築し、運用・監視する前提で導入する必要があります。
キルスイッチへの期待と実情
エージェントによる多様なセキュリティインシデントの発生や規制要件の強まりを背景に、キルスイッチへの期待は高まっています。規制面ではEU AI Act第14条がハイリスクシステムに対し、stopボタンもしくは同等の手続きによって安全な状態で停止させる能力を求めており、止める能力がコンプライアンス要件として位置づけられつつあります。
こうした機運の中で、キルスイッチを導入すればセキュリティインシデントを防止できるという期待が強まっています。しかし実際に設計・運用しようとすると、この期待と実情の間には大きなギャップがあります。
期待1: システムプロンプトで指示すれば制御できる
エージェントに特定条件下で停止するよう指示を書いても強制力はありません。モデルはコンテキスト内の指示を確率的に無視し得るため、プロンプトによる停止指示は停止機構そのものにはなりません。そのため、エージェントの動作を支えるプラットフォーム側で制御機構を構成する必要があります。
期待2: プロセスを停止すれば制御できる
停止トリガーを用意してプロセスを止めるだけでは複数の副作用が生じます。たとえばエージェントが複数人のリクエストを処理している場合、プロセス停止は他の利用者にも影響します。そして一度呼び出した外部APIを適切に処理しないと意図しない影響が発生する可能性もあります。また監査ログがなければ、途中まで実行されていたリソース変更の特定や影響範囲の調査ができません。
期待3: 付与した権限を剥奪すれば制御できる
エージェントを止める方法として、外部サービスの権限を剥奪したり認証情報を無効化したりする手法が考えられます。一方で権限の剥奪が外部サービス側のAPI呼び出しに反映されるまで5〜10分程度かかることがあります。そのため権限剥奪や認証情報の無効化は直ちに動作を止めるものではなく、その間にリソースへの影響が発生し得る点に注意が必要です。
期待4: 異常を検知してから停止すれば間に合う
エージェントの出力は基本的にストリーミングで、常に新しい内容が生成され続けます。そのため、ツール呼び出しのようにエージェントの動作が一時的に止まるイベントの実行前に異常を検知して停止できれば、悪影響を招き得るツール呼び出しを事前に防げます。間に合いさえすれば被害を防げるという点で有効な手段です。
ただしツールをすでに呼び出した後に異常を検知しても間に合っていません。ツールは実行済みで、リソースが変更されていたりすでに悪影響が生じていたりします。
またエージェントの自然言語出力そのものが悪影響になり得る場合、ストリーミング出力が常にユーザーへ表示されている限り、異常を検知した時点で内容がすでに公開されている可能性があります。このケースではそもそも間に合いません。個人情報など機微な情報の出力が重大な影響になり得るエージェントでは特に顕著です。
期待5: ボタンを用意すれば止められる
キルスイッチを用意してユーザーが自由に押せる体制を整備したとしても、実際にそのボタンを押せなければ意味がありません。異常を検知してから停止しても間に合う場合と間に合わない場合があり、その判断や停止タイミングを人間に委ねることには大きな困難が伴います。
また近年はエージェントをバックグラウンドで動かしたい要望が増えています。その場合はエージェントの動作が人間から見えにくく、そもそもボタンを押せません。このためキルスイッチの発動条件には、特定のツールを特定の引数で呼び出した場合といった決定的な判定に加えて、特定の自然言語出力をトリガーにして停止する設計や、別のエージェントがメインのエージェントを逐次監視して異常検知時に止めるといった非決定的な判定を実装して運用する必要があります。
期待6: 発動条件を実装すれば迂回されない
キルスイッチの発動条件が決定的なものである場合、その条件を手動で実装する必要があります。実装が不十分だとキルスイッチは迂回され得ます。エージェントが非決定的に動作する以上、決定的な判定ルールを回避するような出力を行う可能性はゼロではありません。
また非決定的な判定として別のエージェントを併用する場合でも、その監視エージェント自体が非決定的に動作して100%の動作を保証できない前提に立ち、キルスイッチが期待どおりに機能せず迂回され得ることを十分に念頭に置く必要があります。
さらにサンドボックスを脱出できる高度なサイバーセキュリティ能力を獲得したエージェントが、キルスイッチの存在を把握しないとも限りません。そのため、このようなプラットフォームの存在をエージェントが把握できる範囲外に置いて管理することも、現在の高度なLLMを運用するうえで必須要件の一つとなります。
まとめ: 期待と実情のギャップの埋め方
以上のようにキルスイッチは単一のボタンではありません。検知・判断・強制・証跡保全・巻き戻しといった機能を、エージェントの外側にある制御プレーンとして実装する必要があります。
そして冒頭で述べた通り、権限の最小化・サンドボックス化・回復可能性の担保・多層の監査ログといった基本的なセキュリティ対策が前提になります。止める仕組みを作る前に、まず止めなくてよい状態を作ることが重要です。そのうえでなおキルスイッチによるリスク低減が必要な場合に、要件を満たす形で導入していきます。
キルスイッチの設計要件と実装指針
前章で見たとおり、キルスイッチは制御プレーンとしてプラットフォームエンジニアリングの観点から設計・実装する必要があります。
要件1: エージェントの外側にある独立した制御プレーン
キルスイッチの基本構造は、エージェント本体から独立した制御プレーンとしてエージェントと外部連携の双方を制御することです。その際に少なくとも次の3原則を満たす必要があります。
- 非バイパス性としてエージェントと外部連携のすべてがキルスイッチの制御下にあり、迂回できないこと
- 到達不能性として制御プレーンがエージェントの把握・操作できる範囲の外にあり、エージェントが制御機構を変更できないこと
- fail-closedとして制御プレーンが停止・分断された場合に、エージェントが動き続けるのではなく止まる側に倒れること
要件2: スコープと強度で段階化された停止
キルスイッチでプロセスを停止すると、他の利用者への影響や実行途中の処理の中断といった副作用が生じます。したがって停止はスコープと強度の2軸で段階的に設計する必要があります。
スコープは個別の実行単位・特定のエージェント単位・特定のツールや接続先単位・全体といった粒度を用意し、最小の有効範囲から封じ込めを検討します。強度は監視の強化・人間承認への昇格・読み取り専用化・新規行動の拒否・認証情報の失効・ネットワーク遮断といった段階を用意します。
実務上はセッションごと停止しても影響が小さいケースでは実行単位で止める一方、完全停止による副作用が大きいケースでは、エージェントを止め切らずに被害拡大だけを防ぐ読み取り専用モードの強制のような中間段階も検討することになります。
要件3: 決定的判定と非決定的判定を組み合わせた発動条件
期待5で述べたとおり、発動条件には決定的判定と非決定的判定の両方が必要です。
決定的判定とは、特定のツールを特定の引数で呼び出そうとしたら拒否する、許可リスト外の接続先への通信を検知して遮断する、実行回数や消費リソースの上限を超えたら停止するといった、ルールとして機械的に評価できるものです。
非決定的判定は別の監視エージェントによる逐次評価や、出力内容・行動パターンの異常検知などです。想定外の異常を捕捉できる一方で判定自体に時間がかかり、誤検知と見逃しの両方が起こり得ます。
また期待4で見たとおり、自然言語出力そのものが悪影響になり得るエージェントではストリーミング出力をそのままユーザーへ露出させず、判定を挟むためのバッファリングや遅延表示を許容する設計が必要になります。ここでは安全性とUXのトレードオフを考慮しなければなりません。
要件4: 即時性の異なる多層的な強制手段
期待3で見たとおり、権限剥奪や認証情報の無効化は外部サービス側への伝播に時間がかかるため即時の停止手段にはなりません。したがって強制手段には即時性の異なる多層設計が必要です。
- ツールゲートウェイでの拒否は、ツール実行を止めることでリソース操作を防止します
- 認証情報の失効は伝播遅延があるため、即時停止ではなく以後の再開を防ぐ手段と位置づけ、重大インシデント時に継続的な停止が必要な場合に用います
- ネットワーク遮断は、サードパーティ連携によるツールを経由しないコマンド等を介した通信に対する最終手段として機能します
そのうえでデータベース削除・バックアップ削除・送金のような不可逆かつ即時の操作は、キルスイッチでの検知・停止に頼る対象から外し、そもそも権限を渡さないかHITLを必須とする設計にするべきです。
要件5: 停止後の調査と復旧を支える改ざん不能な証跡
監査ログがなければ停止後に影響範囲の調査ができません。停止時点で次の問いに答えられる証跡が事前に記録されている必要があります。
- どの入力・指示から始まった実行だったか
- どのツールをどの引数でどこまで呼び出したか
- 呼び出し済みの外部APIのうち完了したもの・進行中のもの・結果不明のものはどれか
- 変更されたリソースはどれで、それぞれ巻き戻し可能か
さらに実行単位の識別子となるセッションID等がすべてのログで一貫して記録されていること、証跡がエージェント自身には改ざん・削除できない場所に追記専用で保存されていることが必要です。
要件6: 定期的な検証とインベントリ管理
最後に、キルスイッチは迂回・無効化の対象になり得る以上、実際の動作テストを含めて定期的に検証し、検知ポリシーを更新・調整する必要があります。
そのうえでエージェントと権限のインベントリ管理として、どのエージェントがどのツールと権限を持ちどのリソースに到達できるかを常に把握できるよう、登録・変更・廃止を管理プロセスに乗せます。あわせて各エージェントについて所有者・付与されたツールと権限・接続先・想定されるBlast Radiusを記録し、このインベントリを基準に監査やセキュリティ強化を実施していきます。
おわりに
エージェントのセキュリティロードマップを出発点に、キルスイッチへの期待と実情のギャップ、そしてそのギャップを埋めるための実装手法と維持管理のあり方を整理しました。
キルスイッチは銀の弾丸ではなく、エージェントの基本的なセキュリティ対策を積み上げた先にある次の一手です。止める仕組みを作る前に、まず止めなくてよい状態を作ることが重要です。そのうえで、それでもなお残るリスクに対してここで整理した条件を満たす形でキルスイッチを導入し、維持管理していきます。