AI IR Overlay – Incident Response Specification for AI Agents – Darknet – Hacking Tools, Hacker News & Cyber Security

OAuthトークンが有効で、APIコールが認可されており、それでもなお、誰も意図していなかった行為が実行されてしまうことがあります。エージェントは与えられた認証情報を、承認済みのインターフェース経由で使用し、監査ログにはそのすべてが正しく記録されます。この一連の流れのどこにも侵入の痕跡は見当たりません。なぜなら、実際には何も「侵入」されていないからです。

AI IR Overlayは、まさにこうしたケースを想定して構築されています。インシデント対応プログラムにとっては、実に厄介な事態と言えるでしょう。無効化すべき「侵害されたアカウント」は存在しません。アイデンティティのテレメトリは正確であるがゆえに、何の助けにもなりません。問われるべきは「認証情報が盗まれたかどうか」ではなく、「エージェントは何を指示され、何にアクセスできる状態にあり、誰かが気づくまでにそのうちどこまでを実行してしまったのか」なのです。

本フレームワークは、こうした問いに答えるための仕様です。24件のプレイブック、3種類のJSONスキーマ、実行可能なリファレンス実装2件、ライセンスはApache 2.0、作者は1名。その内容は採用件数から想像される以上に優れており、しかも特定の興味深い地点で歩みを止めています。

実際に提供されるもの

NIST SP 800-61 Rev. 3に準拠し、NIST CSF 2.0、NIST AI RMF、およびOWASP Top 10 for Agentic Applicationsとも相互参照された、3つの成果物が用意されています。

AI部品表(AI Bill of Materials) — 本番稼働中のエージェントごとに1つ作成するYAMLファイルで、サービスIDやスコープ、ツール、書き込み対象、メモリ設定、参照元情報を記録します。一貫して重視されているのは、設計文書上の「あるべき姿」ではなく、実際にデプロイされたエージェントが「実際に何にアクセスできるか」です。メールとCRM、ERPに接続されたエージェントは、モデルそのものを検討する以前の時点で、すでに3つの独立した被害範囲を抱えています。そしてこのマップは、静かな火曜日の午後に作っておく方が、深夜2時に慌てて作るよりもはるかにコストが低く済みます。

封じ込めの段階(コンテインメント・ラダー)は、M0からM5まで用意されており、単一のキルスイッチに取って代わるものです。中でも重要なのはM1の段階です。「すべての書き込み系ツールがエージェントのツールセットから取り除かれる」 一方、読み取り・照会系ツールは稼働したままにされます。これこそが、業務プロセスの内部に組み込まれたエージェントに対して本当に必要とされる封じ込めの形です。というのも、セッションを丸ごと破棄しすべての認証情報をローテーションしてしまうと、何が起きたのかを再構築するために必要な状態そのものまで失われてしまうからです。

最低限の証拠セットは、6つのクラスにまたがって定義されています——プロンプトと応答、ツール呼び出しの記録、検索(リトリーバル)の履歴、メモリの状態、設定の状態、そしてアイデンティティまたは下流の監査ログです。冒頭で挙げたケースでは、異常なプロセスツリーも不審な認証イベントも発生しないため、意図的にエンドポイントのテレメトリよりも広い範囲がカバーされています。

ここまでの内容は、SOCに対して新しい規律の発明を求めるものではありません。指揮系統、証拠の取り扱い、復旧プロセスはいずれも従来のまま維持されます。これこそがこのフレームワークの最良の判断であり、時間をかけて読む価値がある理由です。

検証ツールが証明すること

scripts/validate.py はわずか279行のスクリプトです。AI-BOMおよび権限マトリクスのファイルに対してJSONスキーマ検証と鮮度(古さ)のチェックを行いますが、サブプロセスの呼び出しやネットワークアクセスは一切行わず、記述対象のシステムを実際に動かすようなことはしません。

これは見た目以上に有用な仕組みです。封じ込めテストの日付が古くなっていれば、それはビルド上の指摘事項として扱われます。これができる制御フレームワークは、実はそう多くありません。ただし、ここには2つの留保事項があり、いずれも実態以上に良く見えたり悪く見えたりしがちな点なので注意が必要です。

鮮度チェックが実際にビルドを失敗させるのは、strictモードの場合のみです。 デフォルトでは、検証ツールは STALE-WARN を出力しつつ終了コード0で終了します。--strict を指定して初めて、これらはエラー扱いになります。このフラグを付けずにCIへ組み込んだチームは、パイプライン側では強制されない警告を受け取るだけになってしまいます。

そして、ビルドが通ったからといって、それは「制御が申告された」ことを意味するにすぎず、「制御が機能する」ことを意味するわけではありません。 検証ツールが確認するのは、その組織がキルスイッチを備えていると文書上申告し、それを最後にテストした日付を記録していることだけです。そのスイッチが実際に機能するかどうかは、いかなるスキーマチェックの及ぶ範囲でもありません。この区別こそがこのフレームワーク全体のテーマであり、それを測定できる唯一の場所において曖昧にしないことには、大きな意味があります。

自動化が止まる地点

アクチュエーション(実行制御)層は、一見して分かる以上に作り込まれています。schemas/kill-switch-api.md には19KBのキルスイッチAPI契約が用意されており、M1への言及は十数回に及びます。また、reference-impls/kill_switch_demo/ には実行可能なデモがあり、合成的なツールレジストリに対してM0からM4までの契約を実装しています——なお、制御された再有効化にあたるM5は明示的に対象外とされています。もう一つのリファレンス実装である evidence_exporter は、6つの証拠クラスそれぞれに対応するアダプターのスタブを提供します。エージェントを封じ込め段階間で移行させるためのインターフェースは、明確に仕様化されデモンストレーションもされているのです。

一方で仕様化されていないのは、「いつ」その移行を行うべきかという点です。

キルスイッチの概要ドキュメントは、この点について率直です。その文言は、じっくり読む価値があります。

10分以内というTier-1 SOCの起動所要時間は、インシデントコマンダーの指示を受け取れる有人セキュリティオペレーションセンターの存在を前提としています。24時間365日稼働する完全自律型エージェントで、時間外にSOCが有人体制でない場合(かつエージェントの所有者がループ内で唯一の人間である場合)、M3/M4の起動経路には、本v0.33.0仕様がまだ定義していない自動化が必要になります。

つまり、文書化された起動経路は有人SOCの存在を前提としているのです。M3やM4へのエスカレーション経路は、10分以内に連絡が取れるインシデントコマンダー(人間)の存在を前提としており、その前提が成り立たない場合には、仕様書自身がその旨を明記した上で立ち止まっています。どのような信号で、どの閾値で、どの範囲に対してどのモードへ移行すべきかというポリシーは、一切示されていません。

この抜け穴は、まさにエージェントの自律性が最も高く、対応チームの人員が最も少ない場面に存在しています。 24時間体制のSOCを持つ組織は、そもそも自動トリガーを最も必要としない組織であり、この仕様が前提とする運用モデルとぴったり一致します。一方、夜間にエージェントを無人稼働させている2人体制のチームこそ、自動トリガーを最も必要としているにもかかわらず、そこにあるのは「認識済みの空白」だけなのです。

同じページ内にある、もう一つの小さな指摘です。このページ自体はv0.33.0を名乗っていますが、現行リリースはv0.35.0であり、7月9日以降、リポジトリへの更新は一切プッシュされていません。安全管理を扱うページ上のバージョンのずれは、最もコストの高い種類のずれです。

過去の記事アーカイブが語ること

Darknetは2016年に FIDO を紹介しています。これはNetflixが構築した、マルウェア検知の評価・スコアリングを行う自動インシデント対応のオーケストレーション層です。当時のFIDO自身の機能一覧には、こう記されていました。「エンフォースメント(強制対応)——現在作業中(アカウント無効化、パスワードリセット、NIC切断など)」。相関分析とスコアリングの部分は構築済みでしたが、それに基づいて実際に行動を起こす部分は未完成のままだったのです。ケース管理の半分を担う FIR が登場したのは、その1年後でした。

それから10年が経ち、AI IR Overlayは反対側からまったく同じ境界線に行き着いています。FIDOが未完成のまま残した「エンフォースメント」の部分——つまり封じ込めの契約と、それを実際に動かして見せるデモンストレーション——は提供されている一方で、自律的な判断そのものは採用する側に委ねられているのです。

この連続性こそが、本稿の核心的な発見です。10年の隔たりを持つ2つのプロジェクトが、まったく異なる問題に取り組みながらも、いずれも「何かが行動を起こすべきほど深刻な事態であると、機械自身が独力で判断しなければならない」地点で立ち止まっています。インターフェースは扱いやすい部分です。しかしトリガー(引き金)はそうではありません。そしてそれを明示的に名指しすることこそが、欠けているピースを曖昧にせず、可視化し続けるということなのです。

攻撃側の視点から見ても、これは「影響(インパクト)」の具体的な定義として活用できます。当サイトではこれまで、エージェントの攻撃対象領域を検証するツールとして PyRIT や mcp-scanner を取り上げてきました。プロンプトインジェクションを見つけること自体は、比較的容易な半分にすぎません。攻撃対象となったエージェントを読み取り専用モードに移行させられない、サービス全体を停止させずにリスクの高いツール1つだけを無効化できない、事後に検索履歴やツール呼び出し履歴をエクスポートできない——これらもまた、それ自体が重大な発見事項なのです。

今日からチームが活用できること

このフレームワークは、実証済みの運用上の封じ込め手段としてではなく、計画立案・机上演習(テーブルトップ)用のフレームワークとして扱うべきです。成熟度を裏付ける証拠はまだ乏しく、プロジェクト自身もそれを隠していません。コントリビューターは1名、コミット数は479件、スター数は1、フォークはゼロ、issueの起票・クローズもゼロ、文書化された本番インシデントの実績もありません。リポジトリに収録されているエンドツーエンドのウォークスルーも、あくまで合成データによるものであり、その旨が明記されています。

したがって、演習は実施すべきですが、その成熟度レベルをそのまま上位に報告することは避けるべきでしょう。まずは本番稼働中のエージェントを1つ選び、実際に何へ書き込みができるのかを洗い出し、読み取り専用モードへの移行を試み、直近1時間分の6クラスの証拠をエクスポートできるかを試してみてください。この3つのうちどれか一つでも失敗すれば、それは実システムにおける本物のギャップです。

そしてその上で、この仕様書自身が未解決のまま残している問いを投げかけてみてください。もし深夜3時にそのエージェントが誤動作を起こし、誰も見ていなかったとしたら、何がM3への移行を発動させるのでしょうか。現時点で得られる答えは「まだ叩き起こされていない誰か(人間)」であり、AI IR Overlayはその人間をどう置き換えるかについては、まだ何も書き記していません。

仕様書はこちらで読むことができます: https://github.com/jacobideji/aiiroverlay