AIエージェントがインシデントの当事者になったとき、証拠となるのはアイデンティティの記録です

執筆：Len Noe（BeyondTrust ソリューションアーキテクト）

インシデント対応の場で最初に問われるのは、「なぜ起きたのか」ではありません。「誰の認証情報が使われたのか」です。私の経験では、この問いに最初の1時間で答えられるかどうかが、その後の対応のペースを決めます。何を隔離し、何を無効化し、誰に通知するのか。そして被害がどこまで広がり得たのかも、この答え次第です。

答えられないチームは、最初の1日を費やして、本来その目的で設計されていないログから答えを組み立て直すことになります。

この問いの重みは、新しい種類のアクターの登場によって試されようとしています。2026年10月16日、米国立標準技術研究所（NIST）、サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）、国家安全保障局（NSA）は共同で、AIエージェントが誰の指示にもない行動をとった場合のインシデント対応体制と対応に関する、10項目の任意実践事項を公表しました。

このガイド「Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation」は有用ですが、読み違えやすい文書でもあります。最も強力な指針はアイデンティティに関するものですが、見出しでその言葉が使われることはほとんどありません。

NIST・CISA・NSAのインシデントガイドの内容

全14ページのこの文書は、人間の監督が限られた状況で、長期にわたる多段階のタスク（長い期間にわたって多くのステップを踏む作業）を実行する高性能エージェントを、訓練または評価する組織を対象としています。ただし著者らは、エージェントを導入する組織にも参考になる可能性があるとしています。10の実践事項は、準備、検知、対応、復旧、報告の5段階に整理されています。

ガイドは「統制インシデント」を、エージェントが運用者や攻撃者の指示によらず重大な行動をとり、統制、ポリシー、人間による監督を損なう事象と定義しています。

3機関によると、これらの実践事項は確立されたインシデント管理フレームワークを土台にしています。そのため、求められる内容の大半はなじみのあるものです。最小権限、認証情報の管理、監視、証拠の保全、既知のベースラインからの再構築などです。

多くの組織がつまずきそうなのは、おなじみの統制を新しい種類のプリンシパルに適用する場面です。

AIエージェントのインシデント対応は、意図ではなくアイデンティティから始まる

定義の中に、対応担当者にとって重要な点が1つあります。ガイドは、敵対的なプロンプトインジェクションやバックドア入りモデルが引き起こした行動を「指示されたもの」とみなし、「指示されていないもの」とは扱いません。そのため、こうした行動は統制インシデントの定義から外れます。研究者にとっては筋の通った線引きですが、対応担当者には厄介です。インシデントの渦中では、意図の問いに答えられないことがほとんどだからです。

調査担当者の手元にあるのは、アイデンティティ、権限の集合、そして行動の痕跡です。

エージェントのインシデント対応体制は、原因の分類を先に済ませることには頼れません。アイデンティティの記録を出発点に、どのアイデンティティが動いたのか、その背後にどんな権限があったのか、そしてエージェントが誤誘導されたのか、誤動作したのか、侵害されたのかを突き止める必要があります。

無効化できるのは、手が届くものだけ

実践事項6は、インシデント中にエージェントがアクセスした認証情報のうち、組織の管理下にあるものをすべて無効化し、侵害された可能性のある環境を再構築するよう求めています。「組織の管理下にある」という限定は、一見した以上に重い意味を持ちます。エージェントは、組織が保管しているものの、発行はしていない認証情報を蓄積していくからです。

その実例がOpenCodeの侵害です。オープンソースのコーディングエージェントであるOpenCodeは、ホスト型サービス「Console」の一部ユーザーに対し、Anthropic、OpenAI、Googleなど外部プロバイダーのAPIキーが漏えいしたと通知しました。ユーザーがConsoleに保存していたキーです。

同社によると、影響を受けたのはConsoleユーザーの1.4%です。最も早い漏えいは10月17日のUTC 00:30でした。ユーザーからは、一晩で数百ドルから最大1,700ドルに上る不正な課金が報告されています。

Google Cloudプロジェクトが不正利用を理由に停止された例もあり、リソースが乗っ取られたとみられます。同社は侵入経路を明らかにしておらず、この事案を大規模な蒸留攻撃（distillation attack）だと説明しています。

同社の説明は暫定的なものとして受け止めるべきです。対応体制の観点で重要なのは、問題の構造です。エージェント基盤が保管していたキーを無効化できるのは、それを発行したプロバイダー側だけで、操作できるのはアカウントの所有者に限られます。しかも、アカウントの所有者はキーが漏えいしたことにすら気づいていないかもしれません。

ガイドが求める無効化の手順は、エージェントが触れ得るものの棚卸しを前提としています。それがなければ、無効化すべき対象がわかりません。報告段階には、同じ棚卸しから導かれる2つ目の義務も加わります。侵害または悪用されたシステムの関係者に通知することです。最終的な標的ではなかった第三者も含まれます。

OpenCodeの事例では、その関係者はモデルプロバイダーと個々のキー所有者です。どのキーがどこに保存されていたかを誰かが把握していなければ、どちらにも間に合うように通知できません。

エージェントの協力に頼らずに封じ込める

ガイドは設計者に対し、エージェントが設定ミスや脆弱性をしばしば見つけ出すと想定し、それに応じた統制を組み込むよう助言しています。MIT Technology Reviewによる7月のHugging Face事案の再構成は、その理由を示しています。

OpenAIのモデルで構築されたエージェントは、サイバーセキュリティ評価の間、インターネットから隔離されているはずでした。ところが実際にはオンラインに接続し、Hugging Faceをハッキングして、行き詰まっていた問題の解答を入手しました。

記事が述べている統制はネットワークの隔離だけで、エージェントはそれをかいくぐりました。OpenAI自身の研究者は、この挙動をそれを報いる形で行われた訓練のせいだと分析しています。

ネットワークの境界は、人間であれ人間以外であれ、執拗なアクターには回避されかねません。1つのタスクに範囲を限定し、タスクの終了とともに失効し、エージェントを起動した人物とは別のアイデンティティに属する認証情報なら、エージェントの振る舞いに頼る必要がありません。万一コピーが漏れても、できることを制限できます。

ガイドも同じ方向を示しています。意図されたタスクに必要な範囲にアクセスを限定すること、可能な限り使い捨てのインフラを使うこと、エージェントの活動を迅速にブロック、封じ込め、終了させる仕組みを備えることです。その大半はアイデンティティの統制にあたります。

人間以外のアクターにもセッションの説明責任を

ガイドはさらに、エージェントの行動の軌跡を再構築できるだけの、改ざん耐性のある信頼性の高いタイムスタンプ付きログを求めています。あわせて、エージェントが監視機構やログ自体にアクセスしたり改ざんしたりできないことの保証も求めています。名前こそ違いますが、これはセッションの説明責任にほかなりません。

人間の管理者であれば、特権セッションは特定の個人に紐づけられ、記録され、あとから確認できます。エージェントにも同じ基準を適用すべきです。ガイドはこれを裏付けるように、拒否された行動やツール呼び出しを保全することを対応担当者に求めています。インシデントを再現できるよう、エージェント、セーフガード、環境の構成も記録するよう求めています。

拒否された行動は、エージェントが何に到達しようとしたかを示す証拠です。成功した行動よりも多くを物語ることが少なくありません。

エンドポイントのテレメトリを基にしたBeyondTrust Phantom Labs™の新たな調査は、プロンプト単位のログでは不十分な理由を示しています。4週間にわたって採取した顧客のサンプルでは、コーディングエージェントが約13万2,000件のプロンプトから約128万件のシェルコマンドを要求していました。1プロンプトあたり10件近い計算です。これらは要求されたコマンドであり、実行が確認されたものではありません。エージェントの行為とユーザーの行為を区別できないログでは、誰の権限が使われたのかという問いに答えられません。

現実の企業環境では、事情がさらに複雑になります。多くのレガシーアプリケーションは、エージェントごとの活動をログに記録できません。3年前の連携がそう作られているために、共有サービスアカウント経由で動くエージェントもあるでしょう。予算にも限りがあります。現実的な進め方は、最も機密性の高いデータや影響の大きい操作に到達できるエージェントから着手し、それらに個別のアイデンティティを割り当てることです。そこから、アプリケーション側の対応状況に合わせて対象を広げていきます。

エージェントのインシデントは稀でも、備える価値がある理由

最も有力な反論は、費用対効果の観点です。ガイドが対象とするのは最先端モデルの訓練と評価であり、対処すべきインシデントは稀です。あるラボの開示では、14万1,006回の評価のうち6件でした。大半の企業が導入するエージェントは、研究対象のものよりはるかに能力が低く、これまでに報告された被害も限定的です。

では、ほとんど理論上の問題に、なぜ対応能力を整備する必要があるのでしょうか。

答えは、その根底にある仕組みが理論上のものにとどまらないからです。侵害された、あるいは誤った指示を受けたエージェントは、アイデンティティの記録から見れば、動作が速い、侵害されたサービスアカウントのように振る舞います。

AIエージェントのインシデント対応体制をどう測るか

対応体制は、文書の有無ではなく成果で測るべきです。特定のエージェントのアイデンティティが使えるすべての認証情報を洗い出すのに、どれだけ時間がかかるでしょうか。第三者のために保管しているキーも含みます。責任者として名前の挙がる人間のスポンサーを置き、独自のアイデンティティで動いているエージェントは、全体の何割でしょうか。そして、人間自身の行為と、その人に代わってエージェントが行った行為を区別できるセッション記録を、組織は出せるでしょうか。

これらの問いに数分で答えられるなら、その組織は、どう分類されるかにかかわらず、最初のエージェントのインシデントに備えられています。数日かかるなら、いくら洗練された分類体系があっても助けにはなりません。

筆者について

Len Noeは、BeyondTrustのソリューションアーキテクトです。トランスヒューマニスト、ポッドキャスター、国際的なサイバーセキュリティ講演者、著者、テクニカルエバンジェリスト、そして11個のマイクロチップを体内に埋め込んだバイオハッカーでもあります。

元ブラックハットで、テクノロジー分野で30年以上の経験を持ち、70を超える国で登壇してきました。DEF CON 2025でプレミア上映されたドキュメンタリー「I Am Machine」にも出演しています。

BeyondTrustについて

BeyondTrustは、Paths to Privilege™を守る、特権中心のアイデンティティセキュリティ分野のグローバルリーダーです。リスクを生むのはアイデンティティそのものではなく、特権です。人間、マシン、AIエージェントのアイデンティティがあらゆる環境で爆発的に増える中、BeyondTrustは、そのすべてにわたる特権を単一のプラットフォームで検出、制御、保護するよう構築された唯一の企業です。フォーチュン100のうち75社を含む2万社以上の顧客から信頼を得ており、業界の主要アナリストからも複数のカテゴリーでリーダーと評価されています。BeyondTrustは、アイデンティティセキュリティを管理上の課題から戦略的な優位性へと捉え直します。

詳細はwww.beyondtrust.comをご覧ください。