AIエージェントのセキュリティインシデント発生から最初の24時間

AIエージェントのセキュリティについて書かれた文章の多くは、判で押したように同じ構成をたどります。リスクの分類、ガバナンス原則の一覧、そして「責任あるAI活用の導入」を呼びかける内容です。取締役会向けの資料としては役に立つでしょう。しかし、生きた認証情報を持つ自律型エージェントが誰も許可していない行動を取ってしまった深夜2時に、次に何をすべきか問われている場面では、ほとんど何の助けにもなりません。

本稿では新たなフレームワークを提示するつもりはありません。AIエージェントが乗っ取られたり操られたり、あるいは誰も意図していなかった範囲を単純に逸脱してしまった行動を取ったりしたことが発覚してから最初の1日、時間単位で実際に何をすべきかを説明していきます。

エージェントでは時間の進み方が異なる理由

私がインシデント対応の基本的な勘所を培ったのは、人間の速度で動く攻撃者や、決まった命令セットを実行するマルウェアを前提とした環境でした。しかし、エージェント型AIが関わるインシデントに対応するたびに、その前提の一部を捨てざるを得なくなっています。エージェント型AIは、この2つの前提を同時に覆してしまうからです。

Anthropicが自ら公表したGTG-1002キャンペーンに関する報告は、私がこれまで目にした中で最も明快な事例です。中国の国家支援を受けたグループがClaude Codeを操り、約30の組織への侵入を試みさせたもので、この攻撃では戦術的な作業の大部分をAIが人間の関与をほとんど介さずに実行したとされています。この報告を初めて読んだとき、印象に残ったのは攻撃者の特定情報ではなく、その速度でした。これは、誰かがクリックするまで受信箱に1日放置されるフィッシングメールとは違います。私のチームがまだポケベルで呼び出されている最中にも、侵害そのものが自己増殖的に拡大していくのです。

その数か月前には、Aim Securityの研究者らがEchoLeakを公表しています。これはMicrosoft 365 Copilotに存在したゼロクリック型のプロンプトインジェクションの欠陥で、CVSSスコアは9.3。通常であれば、私のチームがあらゆる作業を中断してでも対応するレベルの深刻度です。日常的な要約処理の中で取り込まれた、細工された1通のメールだけで、ユーザーの操作を一切介さずにOneDrive、SharePoint、Teamsからのデータ流出を引き起こすには十分でした。サンドボックスで開くリンクも、起爆させる添付ファイルも不要です。エージェントが本来読み込むよう設計されていたコンテンツそのものが攻撃経路となったのです。これはまさに、OWASPのLLM Top 10がこれらのシステムにとって最大の脅威と位置付けているリスクの種類そのものです。

被害範囲の広がりという問題も、決して仮説上の話ではありません。Obsidian SecurityによるSalesloft-DriftのOAuth侵害に関する分析は、単一の連携アプリの侵害が、いかにして数百に及ぶ下流のSaaS環境へと連鎖していったかを示しています。エージェントが私たちに代わってトークンを保持し、システム間でツール呼び出しを連鎖させる立場になれば、こうしたパターンは今後、改善するどころかさらに悪化していくと私は見ています。

これらのインシデントに共通しているのは、最初の1日の対応の進め方を根本から変えることになった構造的な特徴です。それは、攻撃者がキーボードの向こうに座る人間ではなく、文書に埋め込まれた一連の命令、汚染されたツールの応答、あるいは操作されたメモリストアである場合があるという点です。封じ込めとは、ID(アイデンティティ)を無効化し、ツールへのアクセスを遮断することを意味します。ホストを隔離することを意味するのではありません。少なくとも最初にすべきことではなく、私自身、インシデント対応の最中に、反射的にLANケーブルへ手を伸ばそうとした同僚を制止したことが何度もあります。

時間単位のプレイブック

0時間目：直面している事態を正しく認識する

時計は検知の瞬間から動き始めますが、実はここで最も多くの時間を失いがちです。エージェント関連のインシデントは、SOCが監視するよう調整されているアラートでは、めったに検知されません。私が注目するのは、単一のエージェントIDから発生する統計的に異常なツール呼び出しの量、宣言されたタスクの範囲を逸脱したエージェントの行動(たとえば、メール要約用のエージェントが突然ファイル共有にクエリを投げるような場合)、あるいは人間のオペレーターが与えていない指示に言及する出力です。この段階での私の仕事は診断ではなくトリアージです。これは1つの侵害されたセッションなのか、共有された認証情報の問題なのか、それともどのエージェントでも取り込みうる文書に潜む、システム全体に関わるプロンプトインジェクションのベクトルなのかを見極めます。

0〜1時間目：ホスト単位ではなくID単位で封じ込める

ここは、従来のIRプレイブックがエージェントに対して最も判断を誤りやすいポイントだと感じています。3つ先のシステムでAPI呼び出しを通じてすでに被害が発生してしまっていれば、LANケーブルを抜いても何の意味もありません。私は侵害されたサービスアカウントを扱うのと同じ要領で、エージェントの認証情報、APIキー、OAuthトークンを直ちに無効化または停止します。オーケストレーション層がそれをサポートしていれば、アクティブなセッションも強制終了します。エージェントのメモリストアとツール呼び出し履歴は凍結しますが、削除はしません。後の調査ですべて必要になるからです。そして、エージェントがブローカーやゲートウェイを経由して動作している場合は、下流の個々のシステムを1つずつ追いかけるのではなく、そのブローカーやゲートウェイ側で登録済みのツールを無効化します。

1〜4時間目：被害範囲を特定する

ここからは、エージェントが実際に何に触れたのかを明らかにしていく段階です。呼び出されたすべてのAPI、渡されたすべてのパラメータ、受け取ったすべての応答を含む完全なツール呼び出しログを取得し、それをエージェントの権限と突き合わせて、「アクセスし得た範囲」と「実際にアクセスした範囲」を照合します。また、エージェント自身の行動が、その過程で新たな痕跡を生み出していないかも確認します。スケジュールタスク、転送ルール、新しいAPIキーなどです。というのも、自律型エージェントは、それを作った人間よりも持続的な足場を確保する能力に長けていることが少なくないからです。侵入経路が間接的なプロンプトインジェクションによるものと見られる場合は、同じ汚染されたコンテンツを取り込んだ他のすべてのセッションを特定するよう努めます。これは単一の被害者だけで終わるケースはまれです。

4〜8時間目：確証を得る前に報告する

法務、プライバシー、経営層への最初の説明は、フォレンジック調査が完了するよりもかなり早い段階で行う必要があります。確証を得るまで待つことが、AI関連インシデントを開示の失敗へとつなげてしまう原因になると、私はこれまでの経験から学びました。経営層には次の3点を伝えます。エージェントが何にアクセスし得たか、現時点の証拠から実際に何にアクセスしたと判明しているか、そして何がまだ分かっていないかです。エージェントが規制対象のデータに触れていた場合は、早い段階で法務を巻き込みます。さらに、同じベース設定やツール連携から構築された他のエージェントを予防的に停止する必要があるかどうかも、明確に判断します。1つの脆弱なパターンは、誰も気づかないうちにエージェント群全体に複製されてしまう可能性があるからです。

8〜16時間目：意思決定の連鎖を再構築する

ここが、従来型の侵害事案とは根本的に異なると実感するフォレンジック作業です。私が再構築しているのは、ディスク上で何が起きたかだけではありません。モデルがなぜその行動を取ることを「決定」したのかを再構築しているのです。異常な行動の前にエージェントが取得したあらゆる情報を含め、プロンプトと応答の連鎖全体をたどり、その挙動を誘導した具体的な指示を、目に見えるものであれ隠されたものであれ突き止めようとします。また、エージェント自身の推論の出力が、その指示を不審なものと認識しながらもそのまま実行してしまったことを示しているのか(これはガードレールの不備を意味します)、それとも一切疑わしいと判断していなかったのか(これは検知体制の不備を意味します)も確認します。どちらが判明するかによって、講じるべき対策は変わってきます。

16〜24時間目：復旧方針を決め、まず何かを変更する

私はエージェントを元の設定にそのまま復元することは、原則として行いません。それこそが、こうしたインシデントが1週間以内に再発する原因になるからです。まず、具体的な攻撃経路にパッチを当て、取り込み経路を無害化し、ツールの権限範囲を絞り込むか、悪用された種類の行動には承認ゲートを追加します。認証情報は再発行しますが、以前より権限を狭めたものにし、以前と同一の権限は決して与えません。そして、時系列がまだ鮮明なうちに24時間分のインシデント要約をまとめます。これはインシデント後のレビューだけでなく、規制当局や顧客への通知が必要になった場合にも、その入力情報となることが少なくないからです。

再発するインシデントと、そこから確実に立ち直れるインシデントを分けるもの

リスクフレームワークは、エージェントに最小権限のアクセスと人間による監視が必要だと説きます。私もそれに異論はありませんが、それだけでは、自分がまさに呼び出しを受けている「1時間目」に実際に行動へ移せるものにはならないことも、身をもって学びました。私がその場で本当に必要としているのは、次のような運用上の順序立てです。ホスト単位ではなくID単位で封じ込める。パッチを当てる前に証拠を凍結する。確証を得る前に報告する。そして、直前に破綻した設定とまったく同じ状態には決して復元しない。EchoLeak級、あるいはGTG-1002級のインシデントにチームが見事に対処できた場面を目にするたびに感じるのは、それが壁に貼られた最高のリスク分類表のおかげではなかったということです。むしろ、必要になる前にすでに最初の24時間を訓練し尽くしていたからこそ、うまく対処できたのです。

これこそが、この業界にまだ欠けているものだと私は考えています。私たちはこの2年間、エージェントのガバナンス原則を書き連ねることに費やしてきました。それよりも、これからの1年は、時間との勝負を想定したテーブルトップ演習を重ねることに費やすべきではないでしょうか。次のインシデントは、私たちのポリシー整備が追いつくのを待ってはくれないのですから。