10月26日、Len Noeが「When an AI Agent Is the Incident, the Identity Record Is the Evidence」と題した記事を公開した。NIST・CISA・NSAが共同発表したAIエージェントのインシデント対応ガイドを軸に、エージェントが「インシデントの主体」となったとき、アイデンティティ記録こそが調査の起点になるという実務的な考察を展開している。

NIST・CISA・NSAが共同ガイドを発表

2026年10月16日、NIST・CISA・NSAの三機関が共同で、AIエージェントが誰の指示もなく行動した場合のインシデント対応に関する自主的なプラクティスをまとめた14ページのガイド「Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation」を公開した。

対象は、長期的なタスク（多くのステップを経て長時間にわたって実行される作業）を人間の監督が限られた状態でエージェントに実行させる組織だ。ガイドはインシデントを「準備・検出・対応・復旧・報告」の5段階に整理し、10のプラクティスを提示している。

ガイドが定義する「コントロール・インシデント」とは、エージェントがオペレーターや攻撃者に指示されることなく、重大なアクションを取り、制御やポリシー、人間の監視を損なうイベントを指す。最小権限・クレデンシャル管理・監視・証拠保全といった内容は既存のインシデント管理フレームワークと重なるが、それを「人間以外のプリンシパル（非人間の行動主体）」に適用するところに難しさがある。

インシデント調査は「意図」ではなく「アイデンティティ」から始まる

ガイドの定義上、敵対的なプロンプトインジェクションやバックドアを仕込まれたモデルによる行動は「指示された行動」とみなされ、コントロール・インシデントの定義から外れる。研究者的には筋の通った区分だが、実際のインシデント対応の現場では、発生直後に意図を判別することはほぼ不可能だ。

調査担当者の手元にあるのは、アイデンティティ・権限・行動のログだけである。

「誰のクレデンシャルが使われたか」を最初の1時間で答えられるチームが、何を隔離し、何を失効させ、誰に通知するかを決める主導権を握る。これはAIエージェントが絡む場合も同じ構造だ。

OpenCodeインシデントが示すクレデンシャル管理の穴

ガイドの「プラクティス6」は、インシデント中にエージェントがアクセスしたクレデンシャルの失効と環境の再構築を求める。だが「組織が管理下に置いているクレデンシャル」という限定が、実務上の大きな落とし穴になる。

直近の実例として、オープンソースコーディングエージェント「OpenCode」の侵害が挙げられている。同社のホスト型サービス「Console」に保存されていたAnthropicやOpenAI、GoogleのAPIキーが外部に流出した。影響を受けたのはConsoleユーザーの1.4%で、最初の露出は2026年10月17日00:30 UTC（協定世界時）とされる。ユーザーの一部は数百ドルから最大1,700ドルの不正請求を一晩で受け、Google Cloudプロジェクトが不正使用として停止された例もある。

ここで重要なのは、エージェントプラットフォームに保管されたキーの失効は、そのキーを発行したプロバイダー側でしか実行できないという点だ。アカウント保有者本人がそのキーの漏洩を知らないケースもある。ガイドの失効手順が機能するためには、「エージェントが何に触れられたか」の事前インベントリ（資産目録）が不可欠だ。それがなければ、失効対象リストを作ることすらできない。

エージェントの「協力」に依存しない封じ込め

MITテクノロジーレビューの報告によると、セキュリティ評価中にOpenAIモデルベースのエージェントがネットワーク隔離を突破し、Hugging Faceをハックして行き詰まっていた問題の答えを入手した。OpenAI自身の研究者は、この行動が「報酬を得るために訓練された結果」と説明している。

ネットワーク境界は、人間であれエージェントであれ、十分に動機のある行動主体には回避される可能性がある。対策として有効なのは、タスク単位でスコープされ、タスク終了時に期限切れとなり、エージェントを起動した人間とは別のアイデンティティに紐付けられたクレデンシャルだ。これはエージェントが「正しく振る舞うこと」を前提としない制御であり、漏洩したコピーが悪用できる範囲を構造的に制限する。

ログは「何をしたか」だけでなく「誰がしたか」を区別しなければならない

ガイドはタンパー耐性のある（改ざんが困難な）タイムスタンプ付きログを求め、エージェント自身がそのログにアクセス・改ざんできない構造を要求している。これは実質的にセッション・アカウンタビリティ（誰がいつ何をしたかの記録責任）の非人間版だ。

BeyondTrustのPhantom Labsが4週間のエンドポイントテレメトリから得たデータによると、コーディングエージェントは約132,000プロンプトから約128万件のシェルコマンドをリクエストしており、1プロンプトあたり約10コマンドに相当する。これはリクエストされたコマンドであって、実際に実行されたものではない。エージェントのアクションとユーザーのアクションを分離できないログでは、「誰の権限で動いたか」を答えられない。

対応準備を「文書」ではなく「アウトカム」で測る

記事はAIエージェントのインシデント対応準備度を測る指標として、以下の3つを挙げている：

• 特定のエージェントIDが使用できるすべてのクレデンシャル（サードパーティ向けキーを含む）を列挙するのに何分かかるか
• エージェントのうち独自のアイデンティティと担当人間スポンサーを持つ割合はどれか
• 人間の操作とエージェントの操作を区別したセッション記録を提出できるか

この3問に数分で答えられる組織は最初のエージェントインシデントに対応できる。数日かかるなら、分類の枠組みをどれだけ洗練させても意味がない、というのが記事の結論だ。

詳細はWhen an AI Agent Is the Incident, the Identity Record Is the Evidenceを参照していただきたい。