AIインシデントレスポンス：AIシステムが操作された場合、またはデータを漏えいした場合に何をすべきか

AIセキュリティインシデントは、必ずしもマルウェア、盗まれた管理者パスワード、あるいは侵害されたサーバーから始まるわけではありません。悪意のある命令が埋め込まれた文書、AIエージェントの挙動を変えるプロンプト、別テナントのデータを露出させる検索システム、あるいはユーザーが意図していなかった操作を実行するAIツールから始まる場合があります。

そのため、AI時代のインシデントレスポンスには従来とは異なる視点が必要です。

組織には依然として、準備、封じ込め、証拠保全、根絶、復旧、インシデントからの学習というサイバーセキュリティ・インシデントレスポンスの基本が必要です。NISTは2025年4月にSP 800-61 Revision 3を最終化し、インシデントレスポンスをサイバーセキュリティリスク管理全体へ統合しました。また、NIST AI Risk Management FrameworkとGenerative AI Profileは、AIシステムの設計、導入、運用におけるリスク管理を扱っています。

しかしAIでは、新しい証拠ソースと新しい封じ込めの問題が生まれます。

モデルは操作されたのか。

どのコンテキストを受け取っていたのか。

どの文書が取得されたのか。

どのツールが利用可能だったのか。

エージェントはどの権限を持っていたのか。

機密情報は単にモデルコンテキストへ入っただけなのか、それとも実際に開示されたのか。

エージェントが危険な操作を要求しただけなのか、それとも下流のAPIが実際に実行したのか。

問題はプロンプトレイヤー、検索アーキテクチャ、認可、モデル出力処理、それとも接続先アプリケーションに存在したのか。

これらを区別する必要があります。

AIインシデントは、一つのコンポーネントだけの障害ではないことが多いからです。

複数の信頼境界にまたがる障害であることが多いのです。

AIセキュリティインシデントとは？

AIセキュリティインシデントとは、AI対応アプリケーション、モデル、エージェント、検索システム、接続ツールなどが、周辺システムの機密性、完全性、可用性、または正当な制御を脅かすように動作するセキュリティ上の事象です。

攻撃者が意図的にモデルを操作する場合もあります。

一方で、エージェントの誤動作、過剰な権限、安全でない統合、あるいはAIが生成した危険な助言を人間が信頼して行動した結果として発生する場合もあります。

OWASPのPrompt Injectionガイダンスでは、モデル操作によって機密情報の開示、LLMに接続された機能への不正アクセス、接続システム上での操作実行、重要な意思決定への干渉などが発生し得るとされています。また、Prompt Injectionの影響はビジネスコンテキストやモデルに与えられたエージェンシーの大きさに大きく左右されます。

したがって、インシデント対応担当者は、画面上で見えているAIの挙動だけがインシデント全体だと考えるべきではありません。

奇妙な回答だけなら影響は小さいかもしれません。

一見普通の回答でも、その裏で特権バックエンド操作が実行されていれば、はるかに重大です。

AIインシデントは従来のアプリケーションインシデントと異なって見えることがある

従来のセキュリティインシデントは、比較的分かりやすい技術的事象から始まることが多くあります。

アカウントが侵害される。

マルウェアが実行される。

APIが悪用される。

サーバーが予期しない外部ホストと通信する。

AIインシデントは、これほど明確ではない場合があります。

アプリケーションはオンラインのままかもしれません。

認証も正常に動いているかもしれません。

従来の意味でサーバーが「ハッキング」されたわけでもないかもしれません。

それでも攻撃者は、正規のワークフロー内でAIコンポーネントの推論方法を操作できる可能性があります。

OWASPが2026年にまとめたGenAIインシデントには、安全でない自律操作、機密データ露出、過剰なエージェント権限、ツールの悪用、連鎖的障害、間接的Prompt Injectionなどが含まれています。

ここから得られる運用上の教訓は明確です。

マルウェア、ネットワーク侵入、認証異常だけを監視していても、AIレイヤーで発生する重要なインシデントを見逃す可能性があります。

組織は、エージェントが実際に何をしているのかを観測できなければなりません。

最初に聞くべき質問は「どんなプロンプトが使われたか？」ではない

疑わしいAIインタラクションが発見されると、チームは自然にプロンプトへ注目します。

攻撃者は何を入力したのか。

どの命令がガードレールを回避したのか。

そのフレーズをブロックできるのか。

これらの質問は再現には役立ちます。

しかし、インシデントレスポンス全体をそれだけで定義してはいけません。

プロンプトは、単なるトリガーであることが多いからです。

本当の問題は別の場所にある可能性があります。

エージェントが過剰な権限を持っていた。

検索システムが許可されていないデータを返した。

内部APIがAIサービスアカウントを過度に信頼していた。

ツールが確認なしに状態変更操作を許可していた。

外部文書が信頼されたコンテキストとしてモデルへ入った。

バックエンドがモデル出力を十分な検証なしで実行した。

インシデントレスポンスが悪意あるフレーズだけに集中すると、症状だけを修正し、悪用可能なアーキテクチャを残してしまう可能性があります。

一般的なAIインシデントシナリオ

LLMアプリケーションやAIエージェントを運用する組織では、特に重要ないくつかのインシデントタイプがあります。

これらは互いに重複し、一つのイベントに複数の要素が含まれる場合があります。

Prompt Injectionと目的操作

Prompt Injectionインシデントは、信頼されていない入力によってモデルの挙動が変化し、本来のアプリケーション目的と異なる動作を行う場合に発生します。

入力は攻撃者から直接届く場合があります。

また、AIが処理する文書や外部コンテンツを通じて間接的に届く場合もあります。

OWASPは直接的・間接的Prompt Injectionの両方を認識しており、不正な機能アクセス、機密情報の開示、接続システム上でのコマンド実行などにつながる可能性があるとしています。完全な防止が難しいため、アーキテクチャ側で影響を抑えることが重要です。

そのため、インシデントレスポンスで重要なのは「モデルが悪意ある命令に従ったか」だけではありません。

その命令によってアプリケーションのどこまで到達できたのかを確認する必要があります。

機密データの漏えい

AIシステムは複数の経路で情報を露出する可能性があります。

許可されていないデータがモデルコンテキストへ取得される。

機密情報が回答に表示される。

接続ツールが必要以上のデータを返す。

モデルが複数ユーザーの情報を組み合わせる。

ログシステムが秘密情報を含むプロンプトを保存する。

外部リクエストによって情報が意図した環境外へ送信される。

ここで重要なのは、データへアクセス可能だったことと、実際にデータが開示されたことを区別することです。

別テナントの文書がモデルコンテキストに入った時点で、認可アーキテクチャはすでに失敗しています。

さらに、その情報が実際に表示された、外部へ送信された、別の操作に利用された証拠がある場合、インシデントの深刻度はさらに高くなります。

最終的なAI回答だけを見るのではなく、データの移動経路全体を追跡する必要があります。

ツール悪用と不正操作

Agentic AIでは、もう一つのタイプのインシデントが発生します。

モデルが実際に何かをするケースです。

エージェントが情報を削除する。

アカウントを変更する。

メッセージを送信する。

アクセス権を変更する。

外部サービスを呼び出す。

内部関数を実行する。

インシデントの原因は攻撃者による操作かもしれませんし、単に安全でないモデル挙動かもしれません。

根本原因分析ではこの違いが重要ですが、まず優先すべきは封じ込めです。

危険なツール能力がそのまま残っていれば、システムは同じ操作を再び実行できる可能性があります。

AI出力を人間が過度に信頼するケース

すべてのAIインシデントで自律実行が発生するわけではありません。

AIが何かを推奨する。

人間がそれを信じる。

そして人間が危険な変更を実行する。

この場合、封じ込めは一つのツールを無効化するだけでは不十分かもしれません。

誤った助言を受け取った人を特定し、その後どの操作を行ったのか、設定変更やアクセス変更が現在も有効なのかを調査する必要があります。

AIインシデント発生直後にすべきこと

最初の運用上の目標は、インシデントが拡大することを防ぐことです。

必ずしもAIプラットフォーム全体を停止する必要はありません。

封じ込めは、潜在的な影響を生み出している能力そのものを対象にすべきです。

怪しいチャット回答があっても、アプリケーションに特権ツールがなければ、対応は比較的限定的かもしれません。

一方、自律エージェントが本番システムを変更しているなら、まったく別の対応が必要です。

セキュリティチームは影響を受けたワークフローを特定し、どの権限がまだ利用可能なのか、危険な攻撃経路が現在も実行可能なのかを確認する必要があります。

プロンプトを完全に理解する前に危険な能力を封じ込める

進行中のインシデントでは、エージェントの権限を制限する前に、モデルの正確な挙動を再現することへ時間を使いすぎる場合があります。

順序が逆です。

エージェントがすでに不正な状態変更操作を行っているとします。

最初に確認すべきなのは、

その操作が再び実行できるか

です。

必要に応じて影響を受けた能力を無効化または制限します。

ツール権限を減らす。

問題のある統合を停止する。

侵害された資格情報を失効させる。

一時的に人間の承認を必須にする。

エージェントを機密性の高い下流サービスから隔離する。

正確な根本原因は、blast radiusを制御した後でも調査できます。

まず封じ込める。

継続的な影響を制限してから深く調査する。

これは従来のサイバーインシデントレスポンスと同じ考え方です。

チャット画面を無効化しただけで封じ込めたと考えない

AIアーキテクチャは、目に見えるチャット画面よりはるかに広い場合があります。

フロントエンドを停止してもバックグラウンドエージェントが動作し続ける可能性があります。

キューに入ったワークフローがツールを呼び続ける可能性があります。

永続的なエージェントセッションが認可状態を保持している可能性があります。

MCP接続がまだ有効かもしれません。

サービス資格情報が下流システムへのアクセスを許可し続けているかもしれません。

永続メモリに操作された状態が残っている可能性もあります。

したがって封じ込めはアーキテクチャ全体に沿って行う必要があります。

ユーザーとのインタラクションを止めることと、実行を止めることは同じではありません。

危険なエージェント権限を失効または縮小する

インシデントにツール悪用が含まれる場合、特権の封じ込めは最も価値の高い対応の一つです。

読み取り専用のAIエージェントと、本番システムを書き換えられるAIエージェントではblast radiusが大きく異なります。

技術的に可能であれば、調査中は影響を受けたエージェントを最小限の能力へ制限します。

書き込み経路が問題だったなら、一時的なread-only運用によって、危険な能力を封じ込めつつ他のサービスを継続できる場合があります。

すべて変更する前に証拠を保全する

封じ込めは重要ですが、インシデント対応担当者には証拠も必要です。

AIシステムでは、従来のインシデントレスポンスで自動的に収集されない証拠が発生します。

モデルへのリクエスト。

System Instructions。

会話履歴。

取得された文書。

RAG検索結果。

ツールディスカバリ状態。

ツールパラメータ。

APIレスポンス。

エージェントメモリ。

モデルバージョン。

Prompt Template。

認可コンテキスト。

ユーザーとテナントのアイデンティティ。

使用されたサービス資格情報。

人間による承認イベント。

下流アプリケーションログ。

外部リクエスト。

これらの情報によって、何が起こったのかを再構築できます。

これらがなければ、「AIが何かをした」ことは分かっても、なぜ、誰の権限で行われたのかが分からない可能性があります。

モデルとアプリケーションのバージョンを保存する

AIシステムは頻繁に変化します。

モデルプロバイダーが更新を行う。

System Promptが変更される。

Retrieval Pipelineが変わる。

エージェントツールが追加される。

ルーティングロジックによって別モデルへリクエストが送られる。

そのため、1週間後に同じセキュリティイベントを再現しても挙動が変わっている可能性があります。

インシデント記録には、その時点で使用されていたモデルとアプリケーション設定を含めるべきです。

重要なのは、

どのシステムが実際にインシデントを発生させたのか

を後から判断できることです。

Retrievalの証拠を保存する

RAGインシデントでは、最終的なモデル出力より検索証拠の方が重要な場合があります。

どの文書がコンテキストに入ったのか。

どのテナントが所有していたのか。

どのメタデータフィルターが適用されたのか。

文書はどこから来たのか。

最近認可状態が変更されていたのか。

攻撃者が制御する内容を含んでいたのか。

検索そのものが不正だったのか、それとも生成後に初めて開示が発生したのか。

これらの違いによって、どのセキュリティ境界が破損したかを判断できます。

誤った文書を取得したことが問題なら、System Promptを変更しても根本的な認可問題は解決しません。

ツール実行の証拠を保存する

エージェントインシデントでは、モデル推論と実際の操作を結びつける必要があります。

どのツールが選択されたのか。

どのパラメータが生成されたのか。

どのバックエンドがリクエストを受け取ったのか。

どの資格情報が使われたのか。

下流認可は実行されたのか。

人間の承認は存在したのか。

どのオブジェクトが変更されたのか。

その操作は元に戻せるのか。

チャット履歴だけでは不十分です。

最終的なセキュリティ影響は、接続先システム上で発生しているからです。

実際のBlast Radiusを特定する

初期封じ込めができたら、次は範囲を確定します。

AI環境では、一つの侵害されたインタラクションが複数の下流操作につながるため難しい場合があります。

悪意ある文書がモデルに影響する。

モデルが内部システムへ問い合わせる。

返されたデータがコンテキストに入る。

エージェントが情報を外部へ送る。

会話メモリが残る。

そのメモリが後のワークフローにも影響する。

この時点でインシデントは単なる一つのPrompt/Responseではありません。

チェーンです。

そのためblast radius分析は、アクセス可能な能力のグラフに沿って進める必要があります。

影響を受けたユーザーとテナントを特定する

SaaS型AIシステムでは、ユーザー境界とテナント境界が最優先事項になります。

一つのアカウントだけか。

一つの組織だけか。

複数テナントか。

共有サービスアカウントがアクセス可能な全データか。

エージェントがグローバル権限を持つ資格情報で動いていた場合、理論上の露出範囲は最初に確認された一つのオブジェクトより広い可能性があります。

対応チームはまず、脆弱な能力が何にアクセスできた可能性があるかを確認します。

次にログと証拠から、実際に何へアクセスしたかを判断します。

両方が重要です。

データが「アクセス可能」「取得済み」「流出済み」のどれかを区別する

インシデント表現は正確でなければなりません。

潜在的にアクセス可能だった。

実際に取得された。

権限のないユーザーへ表示された。

別コンテキストへ保存された。

組織外へ送信された。

これらは、確認された露出レベルが異なります。

証拠以上に誇張してはいけません。

しかし破損した境界を過小評価してもいけません。

Cross-Tenant Retrievalの弱点は、調査でテスト用データしか露出していなかったとしても重大なアーキテクチャ問題です。

一方、通知義務、深刻度、インシデント範囲などは、実際の機密データが認可されたコンテキストから外へ出たかどうかによって変わる可能性があります。

エージェントが状態を変更したか確認する

データ漏えいだけが問題ではありません。

Agentic IncidentではIntegrityも影響を受けます。

どのレコードが変更されたか。

どの権限が変更されたか。

どのメッセージが送信されたか。

どの外部アクションが実行されたか。

新しいアカウント、資格情報、永続設定が作られたか。

その変更は最初のセッション終了後も残るか。

これは従来のセキュリティインシデントでPersistenceや下流変更を調査するのと同じ考え方です。

復旧では元の会話を停止するだけでなく、結果として残った変更を元に戻す必要があります。

破損した信頼境界を特定する

範囲が分かったら、セキュリティモデルのどこが壊れたかを特定します。

「モデルがなぜ悪い判断をしたのか」だけを聞くよりも重要です。

エージェントが信頼されていない外部コンテンツに影響された。

これは一つのレイヤーです。

しかし、

なぜその影響がセキュリティインシデントになったのか。

ツールに不要な書き込み権限があったのかもしれない。

バックエンドがグローバルなサービスアカウントを信頼していたのかもしれない。

取得データにテナントフィルターがなかったのかもしれない。

モデル出力が自動実行されたのかもしれない。

不可逆操作の前に人間確認がなかったのかもしれない。

つまりPrompt Manipulationがトリガーでも、根本的なセキュリティ障害はAuthorizationにある場合があります。

モデル障害とアプリケーション障害を区別する

この違いは、弱い修正を避けるために重要です。

Prompt Injectionによってモデルが別顧客のレコードを要求したとします。

APIは正しく拒否する。

モデルは誤った。

しかしアプリケーションは機密性を維持しました。

次に、AIツールがグローバル管理者権限で動いており、APIが別顧客のレコードを返したとします。

見た目のPrompt Injectionは似ています。

しかしセキュリティ結果はまったく違います。

インシデントレポートでは両方を分けて記録すべきです。

モデル挙動は、イベントがどのように始まったかを説明します。

アプリケーションコントロールは、なぜ実際の影響が発生したかを説明します。

「モデルが操作された」をRoot Causeにしない

それだけでは通常不十分です。

Prompt Injectionを完全かつ確実に防ぐことが難しい以上、確率的モデルに直接管理者権限を与えていたなら、「Prompt Injectionが発生した」という説明だけでは、なぜ管理者レベルの影響が可能だったのか説明できません。

より強いRoot Cause Analysisは、

なぜ操作されたモデル挙動が重大な影響を出せるだけの権限を持っていたのか

を問います。

そこから、より持続的な修正へ進めます。

IdentityとPermission Boundaryを見直す

エージェントインシデントでは、下流アイデンティティを確認する必要があります。

どのIdentityがサービスを呼び出したか。

ユーザー自身か。

Delegated Tokenか。

Agent Identityか。

Global Service Accountか。

下流アプリケーションは誰が操作を開始したか認識していたか。

エージェントはその人物のPermission Scope外のオブジェクトへアクセスできたか。

ワークフローの途中でユーザーIdentityが失われていたなら、修正すべきはPromptではなくAuthorization Contextかもしれません。

資格情報露出の可能性があればローテーションする

API Key、Token、その他の資格情報が許可されていないコンテキストへ入った可能性がある場合、証拠と機密度に応じてローテーションを検討します。

会話を削除しても、すでに漏えいした資格情報は無効になりません。

エージェントのService Identity自体が悪用された場合は、一時的な失効や権限縮小も必要になる場合があります。

目的は、攻撃者が元のAIインタラクションと無関係に利用し続けられる権限を取り除くことです。

永続的AI状態をクリーンアップする

AIアプリケーションは、一回のリクエストを超えて状態を保持することがあります。

会話メモリ。

長期Agent Memory。

Vector Index。

Cache。

生成済みTask。

Queued Workflow。

Tool Session State。

悪意ある内容や不正な情報が永続化された場合、現在のPromptだけを修正してもインシデントは解消されません。

どの状態ストアに汚染または不正情報が含まれている可能性があるかを特定し、無効化、修正、再構築の必要性を判断します。

RAGインシデントはソースレベルで修正する

間接的Prompt Injectionが一つの文書から入ったとします。

その文書を削除すれば、特定の再現は止まるかもしれません。

しかし、本当の問題を解決したとは限りません。

誰がKnowledge Baseへコンテンツを追加できたのか。

ユーザー制御コンテンツを信頼済みとして扱っていたのか。

別文書から同じ攻撃が入れるのか。

RetrievalでAuthorizationが保持されていたか。

一つのTenantのデータが別Tenantから利用可能だったか。

修正は、危険なKnowledge Flowのクラス全体を対象にすべきです。

個別の悪意ある文書は問題の証拠です。

それ自体が根本原因とは限りません。

ツール悪用インシデントではCapabilityを修正する

エージェントが安全でない操作を実行した場合、そもそもツールがその能力を持つ必要があったのかを確認します。

Read-Onlyにできなかったか。

状態変更機能を別ツールへ分離できなかったか。

資格情報をさらに狭くできなかったか。

高インパクト操作に独立Authorizationを要求できなかったか。

BackendでObject Ownershipをチェックできなかったか。

即時実行ではなくStaged Actionにできなかったか。

強すぎるツールを正しく使うようモデルへ何度も教えるより、能力そのものを縮小する方が効果的な場合があります。

データ漏えいインシデントではData Flowを修正する

機密情報が露出した場合、なぜモデルまたは出力へ到達したかを確認します。

ユーザーは取得権限を持っていたか。

Backendが必要以上のデータを取得したか。

モデルコンテキストに不要な機密情報が含まれていたか。

RAGがTenantをまたいで取得したか。

Tool OutputにHidden Fieldが含まれていたか。

ログに機密Promptが保存されていたか。

モデルが外部ツールへ情報を送信したか。

最も強い修正は、機密データが移動する範囲そのものを減らすことです。

モデルが必要としないならコンテキストへ入れない。

ユーザーに権限がないなら取得しない。

ツールが一つのFieldしか必要としないなら内部Object全体を返さない。

Data Minimizationは、将来のモデル障害による影響も減らします。

一つのPromptではなくRoot Causeを修正する

AIインシデント対応で最も弱いパターンの一つは、悪意ある命令そのものをBlock Listへ追加することです。

その攻撃だけは止まる。

しかし能力は残る。

攻撃者が言い回しを変える。

別文書に別バリエーションを埋め込む。

そしてインシデントが再発する。

Prompt Level MitigationはDefense in Depthとして有用ですが、永続的な修正はTrust Boundaryに置くべきです。

Authorization。

Least Privilege。

Tenant Isolation。

Data Minimization。

Tool Constraints。

Output Validation。

Approval Controls。

Network Restrictions。

これらは、将来現れるすべてのPromptを事前に認識する必要がありません。

インシデントレスポンスにはRetestingを含める

開発者が変更をデプロイしただけでAIインシデントをCloseすべきではありません。

破損したSecurity Propertyを再テストする必要があります。

Cross-Tenant Retrievalなら、別クエリでも他Tenantの情報を取得できないことを確認する。

Excessive Agent Permissionなら、そのRoleでは制限操作が技術的に利用不可能であることを確認する。

Indirect Prompt InjectionでTool Abuseが発生したなら、操作された外部コンテンツでも高インパクト結果が発生しないことを確認する。

資格情報露出なら、古いCredentialが機能しないことを確認する。

Retestは、元の一つの会話ではなくSecurity Objectiveを対象にすべきです。

慎重かつ安全に再現する

AI挙動は確率的なため、インシデントを再現できるまで何度も繰り返したくなる場合があります。

本番環境では注意が必要です。

一回のControlled ReproductionでUnauthorized Accessを証明できるなら、実ユーザーデータを何度も取得する価値はほとんどありません。

エージェントに破壊的能力がある場合、可能ならControl Objectまたは隔離環境を使います。

調査によって理解を深めるべきであり、二つ目のインシデントを作るべきではありません。

モデルが依然として誤動作しても修正が有効であることを確認する

これは最も強力なRetesting方法の一つです。

元のインシデントでは、Prompt InjectionによってモデルがPrivileged Toolを要求したとします。

修正後もPrompt Injection自体はモデルへ影響する可能性があります。

それだけで修正失敗とは限りません。

モデルが禁止Toolを要求しても、Deterministic Authorizationが実行を拒否するなら、高インパクトな脆弱性は取り除かれている可能性があります。

完璧なモデル拒否に依存するよりはるかに強いSecurity Propertyです。

モデルは失敗してもよい。

アプリケーションは安全なままでなければならない。

復旧では能力を段階的に戻す

封じ込め中にAI機能を制限した場合、復旧時にすべての権限を一度に戻す必要はありません。

高リスクエージェントを最初はRead-Onlyで戻す。

Sensitive Write機能は検証後に再有効化する。

外部Integrationを一つずつ戻す。

Approval Requirementを一時的に厳しく維持する。

段階的な復旧によって、本番条件でも修正が有効か確認しやすくなります。

不完全な修正の影響も抑えられます。

復旧後は重点監視する

復旧後のモニタリングでは、インシデントに関連する挙動を重点的に確認します。

不正データへの繰り返しアクセス。

拒否されたTool Call。

異常な外部Destination。

予期しないAgent Loop。

大量のRetrieval。

新しいAccess Failure。

高権限Actionへの繰り返しリクエスト。

通常のAI変動と、元の攻撃経路が再試行されている兆候を区別する必要があります。

そのためには、インシデント前からAction Level Observabilityが必要です。

AIインシデントレスポンスにはChat History以上のログが必要

会話ログは有用ですが不十分です。

セキュリティチームには運用上の可視性が必要です。

どのAgentがどのToolを使ったか。

どのUserの権限だったか。

どのResourceへアクセスしたか。

どのPermission Checkが実行されたか。

どのRequestが環境外へ送られたか。

どのModel Versionが判断したか。

こうしたTelemetryによって、自然言語での活動と実際のアプリケーション影響を接続できます。

これがなければ、「AIが何を言ったか」は分かっても、「AIが何をしたか」は分かりません。

ログ自体が新しいData Leakリスクになり得る

インシデント後に最大限のログを有効化したくなるのは自然です。

しかし注意が必要です。

AIログには以下が含まれる可能性があります。

機密Prompt。

取得された文書。

内部System Instructions。

個人情報。

Tool Output。

Access Token。

インシデント調査によって新しい無管理のSensitive Data Repositoryを作るべきではありません。

調査に必要な証拠は取得する。

その証拠を機密度に応じて保護する。

このバランスが重要です。

Incident PlaybookにAI特有のContainment Actionを含める

高インパクトなAIシステムを運用する組織は、インシデント前に封じ込め方法を定義しておくべきです。

特定Toolだけを停止できるか。

Chatbot全体を止めずにWrite Accessだけ削除できるか。

Agent ExecutionをPauseできるか。

特定Model ProviderをRoutingから外せるか。

Retrievalを制限できるか。

特定TenantのAI機能だけ隔離できるか。

Agent Credentialを即座に失効できるか。

外部Network Accessを遮断できるか。

こうしたControlがあれば、実際のインシデント時の対応時間を大きく短縮できます。

「AI Kill Switch」はUIではなくCapabilityを止めるものにする

チームは「AI Kill Switchがある」と説明することがあります。

しかし、リスクを生むCapabilityを制御できなければ意味がありません。

Frontendだけ止めてもBackground Agentが動いていれば不十分です。

Inferenceを止めても、すでに発行済みCredentialが独立して悪用できるなら不十分です。

有効なContainment Designは、実際のExecution Pathを特定し、それぞれを止める方法を持つ必要があります。

場合によっては最適な対応は、

「AIを全部停止する」

ではなく、

「危険なツールだけ停止し、安全なRead-Only機能は継続する」

ことです。

AIインシデントレスポンスには明確なOwnerが必要

AI製品は複数チームにまたがることが多くあります。

Machine Learning Engineeringがモデルを管理する。

Product Engineeringがアプリケーションを管理する。

SecurityがIncident Responseを担当する。

Platform EngineeringがAPIとInfrastructureを管理する。

Data TeamがRetrievalを管理する。

Third-Party Providerがモデルをホストしているかもしれない。

この分断は対応を遅らせます。

リリース前に、誰がToolを無効化できるのか、誰がAgent Credentialをローテーションできるのか、誰がRetrievalを停止できるのか、誰がModel Logへアクセスできるのか、誰が外部Providerへ連絡するのかを決めておく必要があります。

インシデント発生中に「AI Orchestration Serviceの責任者が誰か分からない」と気づくのは遅すぎます。

Third-Party AI ProviderもResponse Planへ含める

アプリケーションが外部モデルやAI Infrastructureへ依存している場合、Incident HandlingにProviderの協力が必要になる場合があります。

組織は、どのTelemetryを自社で持っているのか、どの情報がProvider側にあるのかを理解しておく必要があります。

Model Version、Log、Abuse Reportがどう扱われるかも確認する必要があります。

これは特定ベンダーの問題ではなくSupply Chain Preparednessの問題です。

重要なインシデント再構築が外部プラットフォームへ依存するなら、その依存関係は最初からResponse Planに含めるべきです。

インシデント後にThreat Modelingを実施する

復旧後のレビューを、その一件がなぜ発生したかだけで終わらせるべきではありません。

インシデントがアーキテクチャ全体について何を示したかを考えます。

一つの悪意ある文書がAgentへ影響したなら、他のどのUntrusted Data Sourceでも同じことが起きるか。

一つのToolが過剰権限だったなら、同様のService Identityを使う他のToolはないか。

RAGで一つのTenant Boundaryが失敗したなら、他のAI Data Storeでも同じAuthorization Modelを使っていないか。

Model OutputがValidationなしでExecution Pathへ入ったなら、他にどこでProgrammaticに利用されているか。

一つのインシデントを、Vulnerability Familyを探す機会に変えるべきです。

AIプラットフォーム全体で類似の弱点を探す

一つのRoot Causeは複数箇所に存在する可能性があります。

Support AgentがOverprivileged Service Accountを使っていることが判明した。

同じアーキテクチャがSales Assistant、Coding Agent、Internal Analytics Copilotにも存在するかもしれない。

最初のインシデントだけを直しても、他の場所は脆弱なままです。

そこでPost-Incident Security Testingが重要になります。

確定したインシデントを使って、新しいSecurity Hypothesisをプラットフォーム全体へ展開します。

そして体系的に検証します。

重大なAIインシデント後はThreat Modelを更新する

インシデントは、組織が持っていた前提の一部が間違っていたことを示します。

外部文書はTool Behaviorへ影響できないと思っていたかもしれない。

ユーザーは別TenantのObjectを推測できないと思っていたかもしれない。

Destructive Tool Useには必ずApprovalが必要だと思っていたかもしれない。

AI Backendだけが呼べるからService Accountは安全だと思っていたかもしれない。

こうした前提を明示的に更新します。

インシデントから得た教訓は、アーキテクチャとRisk Modelへ戻さなければなりません。

実際のインシデント前にAI Incident Exerciseを実施する

Tabletop Exerciseによって、本番環境へ影響を与えず運用上の欠陥を発見できます。

たとえば、

顧客がアップロードした文書によってAI Agentが別Tenantの機密情報を漏えいした証拠が届いた

とします。

誰が調査するのか。

誰がRetrievalを無効化できるのか。

どのLogで取得文書を確認できるのか。

Tool Accessだけを停止できるのか。

影響Tenantの範囲をどう判断するのか。

関連ModelとPrompt Configurationを再構築できるのか。

誰が機能を復旧してよいと判断するのか。

演習中に答えられないなら、実際のインシデントではさらに難しくなります。

AIインシデントでも通常のCybersecurity Incidentである可能性がある

AIだけに特化しすぎないことも重要です。

AIアプリケーション侵害の原因が、従来型脆弱性である場合もあります。

盗まれたCredential。

露出したAPI。

脆弱なDependency。

Cloud Misconfiguration。

Broken Access Control。

AI特有の分析だけに集中し、普通の侵害経路を見落としてはいけません。

AIシステムもソフトウェア上で動いています。

Traditional Incident Response Skillは依然として不可欠です。

Root Causeは「失敗したSecurity Property」として表現する

有用なインシデントレポートは、

「AIが予期しない挙動をした」

だけでは不十分です。

たとえば、

「ユーザー制御の文書が、機密ツールへの書き込みアクセスを持つエージェントへ影響でき、下流サービスが元ユーザーのAuthorizationを独立して確認していなかった。」

あるいは、

「共有RAG IndexがTenant Authorizationを適用する前にTenant横断でSemantic Retrievalを実行し、不正な文書がModel Contextへ入ることを許可していた。」

このように記述すると、Engineering Teamが何を直すべきか明確になります。

AIのResponseは証拠です。

失敗したSecurity PropertyがRoot Causeです。

成熟したAIインシデントレスポンスとは

成熟した組織は重要なアクションを観測できるため、AIインシデントを早期に検知できます。

影響を受けたWorkflowを特定し、プラットフォーム全体を不必要に停止せず危険なCapabilityだけを無効化できます。

Prompt、Retrieval Result、Model Configuration、Tool Execution、Authorization Evidenceを保全できます。

影響を受けたユーザー、Tenant、Data、Downstream Serviceを特定できます。

Model Manipulationと、実際の影響を可能にしたArchitecture Control Failureを区別できます。

Root Trust Boundaryを修正します。

Security Propertyを再テストします。

機能を段階的に戻します。

そしてインシデントを次のThreat ModelingとSecurity Testingへ反映します。

これは通常のIncident Responseと根本的に別物ではありません。

新しいAI Trust Boundaryまで拡張された通常のIncident Responseです。

AIインシデントレスポンスの本質は「制御を取り戻すこと」

AIインシデントが重大になるのは、組織が「どの情報をシステムが露出できるか」「どの操作を実行できるか」を制御できなくなった時です。

したがって、レスポンスの目的はその制御を取り戻すことです。

AIインシデントレスポンスに関するよくある質問

AIインシデントレスポンスとは何ですか？

AIモデル、LLMアプリケーション、RAGシステム、エージェント、接続ツールなどに関するセキュリティインシデントを検知、封じ込め、調査、修正、復旧するプロセスです。通常のCybersecurity Incident Responseに加え、Model Context、Retrieval Activity、Tool Execution、Agent PermissionなどAI固有の証拠を扱います。

AI操作を検知した後、最初に何をすべきですか？

操作されたシステムが追加の損害を発生させる能力をまだ持っているか確認することが最優先です。必要に応じてTool、Credential、Integration、Agent Capabilityを制限しながら、調査に必要な証拠を保全します。

Prompt Injectionは常にSecurity Incidentですか？

必ずしもそうではありません。影響は、操作されたモデルが何へアクセスでき、何を実行できるかによって変わります。単なるContent Manipulationで終わる場合もあれば、Sensitive Data DisclosureやUnauthorized Function Useにつながる場合もあります。

AIセキュリティインシデントでは何をログすべきですか？

Initiating UserとTenant、Model Version、関連Model Context、Retrieved Document、Tool Call、Tool Parameter、Authorization Decision、Affected Object、External Request、Downstream Application Logなどが有用です。ただしログ自体のSensitive Dataも最小化・保護する必要があります。

AIシステムがデータを漏えいした場合、企業は何をすべきですか？

影響Workflowを封じ込め、どのデータへアクセス可能だったか、何が実際に開示されたかを特定し、証拠を保全します。その後、Retrieval、Authorization、Excessive Context、その他Data Pathのどこで障害が起きたか確認し、根本境界を修正して再テストします。

AI Agentが不正操作を行った場合は？

影響ToolまたはPermissionを制限し、どの状態が変更されたか確認し、Execution Logを保全します。Agentが使用したCredentialとAuthorization Contextをレビューし、必要に応じて危険な変更を元に戻し、操作を許可したCapabilityまたはAccess-Control Boundaryを修正します。

Prompt Injection後はSystem Promptだけ更新すればよいですか？

いいえ。Prompt改善はDefense in Depthとして有用ですが、実際のSecurity Impactを伴うインシデントでは唯一の修正策にすべきではありません。Deterministic Authorization、Least Privilege、その他のImpact Reduction Controlも必要です。

AIインシデントはどのようにRetestすべきですか？

元のPromptだけを再生するのではなく、元のAttack Objectiveを再現します。不正データアクセスならAuthorization Boundaryを確認します。Tool Abuseなら、モデルが依然としてその操作を要求しても、対象Identityでは技術的に実行できないことを確認します。

なぜAI Agent Incidentは調査が難しいのですか？

エージェントはTool、API、Data Sourceをまたいで複数ステップを実行できるため、一つのユーザーインタラクションが複数の下流操作チェーンを生成する可能性があるからです。

企業はリリース前にAI Incident Response Playbookを用意すべきですか？

はい。Sensitive Toolの停止、Agent Credentialの失効、Retrieval制限、Model/Tool Evidenceの保全、影響ユーザーやTenantの特定、安全なCapability復旧方法を事前に決めておくべきです。

Evie Roybal