AIセキュリティにおける「隠蔽による安全」は死んだ。防御側はより困難な課題に直面している

AIエージェントが放置された欠陥を見つけ、エクスプロイト開発を加速させ、主として専門的な複雑さによって守られてきたシステムに到達したことで、2026年に「隠蔽による安全」は崩壊した。

差し迫った証拠は、忘れ去られたWindowsコンポーネント、広く検証されてきたオープンソースライブラリ、そして不可欠なサービスを稼働させる産業用コントローラーにまたがる。これらのシステムは技術的には異なるが、静かな共通の防御を備えていた。攻撃者には、希少な専門知識、相当な忍耐、あるいは調査に値するだけの経済的動機が必要だった。

AIによる脆弱性発見は、その前提を変える。モデルは未知のコードを解釈し、独自プロトコルを説明し、テストハーネスを生成し、反復的な偵察を自動化できる。その結果は新たなセキュリティ原則ではない。組織が従来の原則への対応を先延ばしにできた摩擦が取り除かれたということだ。

これは防御側にとって厳しい逆転を生む。弱点の発見はより安く、より速くなっている一方で、パッチの検証、開示の調整、運用システムのテスト、欠陥のある開発慣行の変更は、依然として頑なに人間中心のプロセスであり続けている。

もはや問題は、隠された弱点が表面化するかどうかではない。自動化された発見によって放置されたすべてのシステムが経済的に狙える標的となる前に、防御側がそれを生む条件を修正できるかどうかだ。

AIによって「隠蔽による安全」の経済的な堀は失われた

AIは隠蔽による安全を論破したのではない。組織が隠蔽が機能していると思い込むことを可能にしていた労働力不足を取り除いたのだ。

隠蔽による安全とは、アーキテクチャ、インターフェース、または弱点が発見しにくい状態にとどまることに依存する設計や運用上の前提を指す。それは健全な主要統制とは見なされてこなかった。それでも、未知のシステムを調査するために希少な専門家と数週間に及ぶ集中的な作業が必要だった時代には、隠蔽は実用的な保護を提供していた。

その保護は、経済的な堀のように機能した。攻撃者が既知のソフトウェアを狙う方が収益性が高いため、脆弱なコンポーネントが手つかずで残ることがあった。文書が限られているため、独自プロトコルは外部者を遠ざけることができた。古いサブシステムは、その存在を覚えている研究者がほとんどいないため、精査を免れることがあった。

9月13日に公開された元のセキュリティ分析は、その均衡がどう変化したかを示している。ベンダーと独立系研究者は現在、AIエージェントを用いて、目立たず、古く、徹底的にレビューされてきたソフトウェアを調査している。攻撃者も関連する能力を利用し、修正の分析とエクスプロイト開発を進めている。

FBIサイバー部門の副部長であるBrett Leathermanは、コミュニティが10年間調査してきたオープンソースコンポーネントから、モデルが重大な脆弱性を発見したと説明した。これらのライブラリの一部は、ウェブインフラの相当な割合で稼働しているとされる。

これは、AIがあらゆるシステムを独力で理解したり、確実に動作するエクスプロイトを生み出したりすることを意味しない。調査者がゼロから始めずに未知の領域へ踏み込めることを意味する。モデルはコードを要約し、文書を翻訳し、有力な信頼境界を特定し、仮説を検証するスクリプトを生成できる。

エージェント型AIシステムは、その支援を一連のタスクにわたって拡張する。エージェントはファイルを調査し、ツールを実行し、結果をレビューし、アプローチを修正し、定められた目的に達するまで継続できる。人間のオペレーターは依然として目標を設定し、インフラを提供するが、機械が反復作業の多くを吸収する。

これが、AIによる脆弱性発見がクローズドソフトウェアとオープンソフトウェアの双方に圧力をかける理由である。公開コードは直接分析を容易にするが、クローズドソフトウェアであっても、バイナリ、ファームウェア、ネットワーク上の挙動、文書、パッチ、設定成果物を露出している。モデルは、リバースエンジニアリングの経済性を変える速度で、こうした断片を関連付けられる。

Trend MicroのZero Day Initiativeを率いるDustin Childsは、Microsoftが記録的な規模で実施した9月のパッチリリースで対処された、忘れ去られた技術を指摘した。影響を受けたコンポーネントには、Telnetクライアント、Windows RNDIS、NFS Portmapper、Link Layer Topology Discoveryが含まれていた。

その古さは、かつての取引を示す点で重要だ。レガシーコンポーネントは、それを調査する関心や背景知識を持つ人が少ない場合、専門家の継続的な注意を受けずに生き残ることができた。AIは、まさにそうした放置領域へ、好奇心を持つ研究者や攻撃者を低コストで導く。

隠蔽は依然として不便さを加える。文書化されていないプロトコルはエージェントの進行を遅らせることがあり、独自デバイスは利用可能な証拠を制限し得る。しかし、不便さは認可、隔離、認証、メモリ安全性ではない。粘り強い自動調査を阻止できるものとして信頼することはできない。

したがって、その堀は隠された知識から検証可能な統制へと移った。システムには、強固なアイデンティティ境界、最小限の露出、安全なデフォルト、テスト済みのセグメンテーション、そして内部構造が知られても安全性を維持できる設計が必要だ。

これは、Kerckhoffsの原則として知られる確立されたセキュリティ原則を、暗号技術の範囲を超えて適用したものだ。暗号鍵のように適切に管理された秘密を除き、敵対者がシステムの仕組みを理解していても、そのシステムは安全であり続けるべきである。

AIは、この原則を運用上急務のものにする。システムの挙動が理解可能になるために、文書が整然と公開されている必要はもはやない。十分に散在した証拠があれば、エージェントに実用的な地図を与えられるようになった。

最初の圧力点は忘れ去られたソフトウェアだ

最大の圧力にさらされるシステムは、必ずしも最新でも最も価値が高いものでもない。誰も詳しく見ないことに安全性を依存していたシステムだ。

従来の脆弱性研究には、コストの高い段階がある。研究者はコードベースを学び、その実行環境を再現し、前提を理解し、意味のある弱点と無害な異常を分けなければならない。こうした手順には、疑わしいコードを見つけること自体よりも多くの時間が必要になることが多い。

AIはその複数を圧縮できる。ハーネスを作成し、データフローを追跡し、関連実装を比較し、未知のプログラミングパターンを説明できる。また、タスクが反復的になってもスキャンを継続できる。人間の注意力には限りがあるため、これは重要である。

もちろん、有用な結果が保証されるわけではない。モデルは偽陽性を生み、文脈を誤解し、ときに技術的説明を捏造する。それでも、低コストの支援により、オペレーターはより多くの標的を検証し、同じ量の専門家の時間を費やすことなく非生産的な経路を断念できる。

この探索範囲の拡大は、どのソフトウェアが攻撃対象として魅力的になるかを変える。古いライブラリ、ニッチなエンタープライズ製品、デバイスファームウェア、文書化が不十分な社内サービスの保守担当者は、攻撃者が他へ注力すると想定できなくなる。隠蔽による割引は縮小している。

同じ圧力は、展開を待つ既知の脆弱性にも当てはまる。ベンダーが修正を公開すると、攻撃者はパッチ適用済みバージョンと未適用バージョンを比較できる。このパッチ差分解析と呼ばれるプロセスは、どのコードが変更されたかを明らかにし、調査者が根本的な弱点を再構築する助けとなる。

AIは、変更を解釈し、トリガーとなる入力を提案し、テストコードを生成することで、パッチ差分解析を高速化する。迅速なエクスプロイト開発に関するAnthropicの研究は、組織がすべて修正を導入する前に、モデルが最近開示された脆弱性を分析し、悪用を支援し得ることを検討した。

これによりパッチギャップ、すなわち修正が利用可能になってからユーザーが実際に受け取るまでの期間が縮まる。このギャップは常に危険だった。自動分析により、その内部の一時間一時間が攻撃者にとってより価値あるものになる。

Chromiumベースのエクスプロイトキットに関わる最近のキャンペーンは、その運用上のリスクを示した。報道によれば、スパイ活動グループは、アップストリームプロジェクトがパッチを公開してから、下流の安定版リリースがすべてのユーザーに届くまでの間に、脆弱性を利用した。AIがこのキャンペーンのあらゆる部分に必ずしも関与していたわけではないが、そのタイミングを有効にする手法を強化する。

このモデルにおいて、オープンソースだけが特別に破綻するわけではない。公開レビューは防御側にも同じコードへのアクセスを与え、広範な協力を可能にする。より深い問題は、実行の非対称性にある。攻撃者は多くの可能性を試せる一方、保守担当者は報告を検証し、リグレッションを回避し、リリースを調整し、ユーザーを支援しなければならない。

クローズドソフトウェアも、公開可視性が低い形で関連する問題に直面する。AI支援を受けた研究者は、それでもバイナリ、インターフェース、エラー時の挙動、更新パッケージ、モバイルアプリケーション、デバイスファームウェアを調査できる。ベンダーは、ソースコードを非公開にしておけば持続的な技術的謎を維持できるとは考えられない。

このため、保守担当者は増大する受け付けの問題に直面する。AI生成の報告が増えても、自動的に確認済み脆弱性が増えるわけではない。一部の提出は、重複、不完全な主張、または十分な検証なしに生成されたもっともらしいエラーとなる。

この洪水は、本物の弱点を修復するために必要な専門家の時間を消費しかねない。広く展開されているコンポーネントの保守担当者が数人しかいない場合もあるため、小規模なオープンソースプロジェクトは特に脆弱だ。自動化された発見は、そのレビュー能力とは独立して拡大できる。

したがって、組織は報告件数以上を測定しなければならない。有用な指標には、再現までの時間、深刻度を判断するまでの時間、重複発見の割合、パッチ検証時間、脆弱性クラス別の再発状況が含まれる。

これらの指標は、セキュリティの改善と単なる活動を区別する。開発プロセスに繰り返し発生するインジェクションの欠陥を残したまま、低リスクの報告を数百件処理するチームは、速く走っていても将来の露出を減らしてはいない。

産業システムは専門性という障壁を失う

オペレーショナルテクノロジーは、隠蔽の崩壊が通常のソフトウェア保守を超える結果をもたらす理由を示している。

オペレーショナルテクノロジー、すなわちOTは、水処理、製造ライン、燃料配送、電気設備といった物理プロセスを制御する。産業制御システムは、多くの場合、長寿命のハードウェア、独自プロトコル、専門的なエンジニアリングソフトウェア、厳格な可用性要件を組み合わせている。

この環境は歴史的に、多くの攻撃者を遠ざけてきた。プログラマブルロジックコントローラー、すなわちPLCを理解するには、産業プロセスとデバイス固有の通信に関する知識が必要だった。仮説の検証は、物理的な運用を中断させるリスクも伴い得る。

Google Threat Intelligence GroupのチーフアナリストであるJohn Hultquistは、専門知識が産業システムを取り巻く実用的な保護の大部分を提供してきたと論じた。AIは、その知識を取得、整理、適用しやすくする。

リスクは8月に具体化した。米国の5機関は、インターネットに公開されたSiemens S7 Series PLCに対し、攻撃者がAI支援スクリプトを使用していると警告した。影響を受けた環境には、水道、製造、エネルギー、化学、農業、商業施設が含まれていた。

連邦脅威警告によると、オペレーターは公開されている産業オートメーションライブラリとAIコーディングアシスタントを組み合わせた。そのツールは正規の監視ソフトウェアを模倣し、PLCのメモリ、設定データ、ラダーロジックとやり取りした。

ラダーロジックは、産業制御の挙動を定義するために使われるグラフィカルなプログラミング言語である。許可されていない変更は、画面上の情報を変えるだけでなく、実際の設備に影響を及ぼす可能性がある。

報告された活動により、これらのコントローラーで使用されるS7commプロトコルを扱うために必要な専門知識が低下した。AIは、公開情報を用いてオペレーターがスクリプトを生成または変更する助けとなり得る。ただし、隔離されたコントローラーに到達可能性を与えたわけでも、適切に構成されたすべてのセキュリティ対策を回避したわけでもない。

攻撃を可能にする条件は、依然として露出だった。攻撃者は、インターネットに接続されているPLC、古いソフトウェアを実行しているPLC、またはデフォルト認証情報で保護されているPLCを探していたとされる。脆弱なセグメンテーションは、その後、生成されたスクリプトに重要機能への経路を与えた。

この区別は重要である。インシデントを「AI攻撃」と呼ぶと、組織がすでに実装方法を知っている対策から注意をそらしかねない。インターネットからの直接アクセスを除去し、デフォルト認証情報を変更し、サポート対象デバイスにパッチを適用し、エンジニアリングネットワークを分離することは、依然として不可欠だ。

セキュリティを秘匿性に依存させる手法の失敗は、組織が未知であることを隔離されていることと取り違えたときに最も明白になる。珍しいプロトコルはアクセスを防がない。独自のエンジニアリングインターフェースは、その利用者を認証しない。文書化されていないコマンドも、事例を比較して応答を試すよう訓練されたモデルを止めることはできない。

同時に、防御側は産業環境に対し、消費者向けノートPCと同じようにパッチを適用することはできない。工場では、保守作業が数か月先まで予定されていることがある。ベンダーは変更の認証を必要とする場合がある。古いコントローラーは何十年も稼働し続けることがあり、その交換には大規模な物理作業が必要となることもある。

可用性は、テストにおけるジレンマも生む。防御措置の不具合は、生産を中断させたり機器を損傷させたりする可能性がある。攻撃者には混乱を避ける理由が少ない一方、運用者はあらゆる変更を安全性と運用上の制約に照らして検証しなければならない。

この非対称性は、検知の改善だけでは不十分である理由を説明している。所有者には、正確な資産インベントリ、制御されたリモートアクセス、ネットワーク監視、強制された通信経路が必要だ。非エンジニアリング用ワークステーションからPLCへのあらゆるトラフィックを特定し、承認済みの変更時間帯以外の書き込みを調査すべきである。

一方向にしか情報の移動を許可しないデータダイオードは、テレメトリーを外部へ送信する必要はあるものの、コマンドを戻す必要がない環境を保護できる。強力なセグメンテーションは、侵害されたワークステーションや生成されたスクリプトの影響を限定できる。

これらは、システムを隠そうとする試みではなく、アーキテクチャ上の制御である。攻撃者が機器を理解していることを前提とし、それでも実用的な経路を与えない。

この教訓はエンタープライズソフトウェアにも及ぶ。内部APIが文書化されていない、あるいは管理パネルが予測困難なアドレスを使用しているというだけで、システムが安全であり続けるべきではない。AIは着実に、そうした不便を短時間の調査作業へと変えている。

AIによる脆弱性発見は修復を上回る速度で進んでいる

セキュリティにおける中核的なトレードオフは、もはや発見と無知の対立ではない。機械速度の発見と、人間の制約を受ける修復の対立である。

Luta Securityの創業者兼CEOであるKatie Moussourisは、真のボトルネックはトリアージ、優先順位付け、修復だと指摘した。組織が何が重要かを判断できず、原因を排除できないのであれば、さらなる弱点を見つけても価値は限定的である。

ここで、AIによる脆弱性発見を楽観視する見方は不完全になる。もっともらしい発見を10倍生み出すモデルでも、レビューキューに信頼できる証拠、再現可能なテスト、明確な責任分担がなければ、セキュリティを悪化させかねない。

防御側は、すべての報告について複数の問いに答えなければならない。その挙動は実在するのか。攻撃者はそれに到達できるのか。どの権限が必要か。悪用は重要な信頼境界を越えるのか。提案された修復は期待される挙動を壊さないか。

AI生成パッチは、それに対応する加速策のように見える。モデルは脆弱なコードを調査し、変更を提案し、テストを生成できる。しかし現在の証拠は、パッチ作成が依然として不審な挙動の発見よりはるかに信頼性が低いことを示している。

1Passwordの研究チームは、2つの最先端モデルを用い、最近開示された6件の脆弱性に対して生成された6,080件のパッチを評価した。そのうち、アプリケーションの挙動を実質的に変えることなく脆弱性を完全に解決したのは26.0％にすぎなかった。

さらに20.1％は脆弱性を修正したものの、アプリケーションの動作を変化させた。より深刻なのは、53.9％が弱点の解決に失敗したか、別の脆弱性を導入したか、あるいはその両方だったことである。これはパッチ検証研究で報告されている。

これらの結果は、すべてのモデル、言語、脆弱性に共通する失敗率を示すものではない。研究者らは意図的に、大幅な修復を必要とする最近の複雑な欠陥を選定した。より単純な欠陥や、より強力なテストスイートでは、異なる結果になり得る。

それでもこの研究は、中心的な不均衡を明らかにしている。説得力のあるコード変更を生成することは、それがすべての重要なセキュリティ特性と機能特性を保持すると証明することより容易である。

提案された修復の一部は、根本原因に対処せず、既知の概念実証用入力だけを限定的に遮断していた。このパターンは、基本テストには合格する一方で、代替入力に対して依然脆弱なパッチを生み出しかねない。

AI生成パッチは、それを評価する環境の弱点も引き継ぐ。不完全なテストスイートは、確認していない挙動を検証できない。モデルは、可視化されたテストに合格することを最適化する可能性がある。たとえそれらのテストがセキュリティ契約のごく一部しか表していなくてもだ。

100を超えるモデルと80件のプログラミングタスクを対象とした別の研究では、平均セキュアコード率は56％とされた。この結果は脆弱性修復ではなく生成コードを調査したものだが、独立した検証の必要性を改めて裏付けている。

組織は、これらの数値をAIが防御業務を支援できない証拠として受け取るべきではない。モデルは変更案の下書き、回帰テストの生成、不慣れな関数の説明、代替修正案の比較を行える。専門家が最終決定権を保持するなら、こうした用途はエンジニアリングの負担を減らせる。

危険は、速度が主要な成功指標になったときに始まる。十分な検証なしに迅速に展開されたパッチは、元の欠陥を残したり、新たな欠陥を生み出したり、アクセスルールを気付かれないまま変更したりする可能性がある。

したがって、防御の自動化は実行に根差したものでなければならない。つまり、提案された変更をコンパイルして実行し、セキュリティ特性をテストし、挙動を比較し、定義済みの不変条件に違反するパッチを拒否することを意味する。不変条件とは、許容されるあらゆる実装で常に真でなければならない条件である。

テストが運用コンテキストのすべてを捉えることはないため、影響の大きいシステムでは人間によるレビューが依然として必要である。エンジニアは、なぜ弱点が存在したのか、どの前提が崩れたのか、関連コードにも同じパターンが存在するかを理解しなければならない。

これはパッチを生成するより遅い。しかし、脆弱性報告を持続的なリスク低減へと変えるのは、この作業である。

発見件数を増やしても壊れたセキュリティプロセスは修復できない

AIへの対応としてパッチキューを増やすだけの組織は、欠陥を生んだプロセスを量では是正できないため、行き詰まり続ける。

脆弱性プログラムは、生産性が高く見える一方で、リスクが増え続けることがある。チームは重要度の高い発見件数、対応完了までの時間、総パッチ数を数える。これらの数字は収集しやすい。活動は示すが、ソフトウェアがより安全になっているかを必ずしも示さない。

Moussourisは、組織は個別の発見と修復にリソースを無限に追加しても勝てないと警告した。持続可能な対応とは、パターンを特定し、繰り返される脆弱性の類型を生み出すシステムを変えることである。

AI支援レビューで数十件のインジェクションの欠陥が見つかったと仮定しよう。各事例の修復は重要だが、より大きな機会は開発の早い段階にある。チームは、より安全なテンプレート、一元化された入力処理、フレームワークの保護機能、同じ欠陥の再発を防ぐテストを導入できる。

これは、発見事項を処置することと、セキュリティ制御を改善することの違いである。前者は当面の露出を減らす。後者は露出が発生する将来の割合を変える。

組織は、脆弱性データをコード所有権、アーキテクチャ上の意思決定、開発標準に結び付けるべきである。あるサービスが繰り返し認可の失敗を生むなら、リーダーシップはチケットの迅速な完了を称賛するのではなく、そのアクセスモデルを検討する必要がある。

同じ考え方はインフラにも当てはまる。公開された管理インターフェースに関する発見が繰り返される場合、それは資産管理またはネットワークガバナンスの失敗を示唆する。デプロイメントパターンを正さずに1台のサーバーだけを修正しても、根底にある仕組みは残る。

AIセキュリティを秘匿性に依存させない成熟した対応は、率直なインベントリから始まる。チームは、どのコンポーネントが展開されているか、誰が保守しているか、どのインターフェースに到達可能か、サポート終了時に何が起こるかを把握する必要がある。

ソフトウェア部品表は依存関係の特定に役立つが、インベントリはパッケージ名を超えて広がらなければならない。組織には、ファームウェアのバージョン、デバイスモデル、クラウドサービス、内部API、継承された権限、運用技術資産も必要である。

ナレッジシステムは、別の形の秘匿性リスクを生む。AIアシスタントは、従業員が技術的にはアクセス権を持つものの、手作業ではめったに見つけられなかった文書、メッセージ、文字起こし、メモを表面化させることができる。

これは必ずしもAIによる認可回避ではない。常に広すぎた権限が露出したものかもしれない。AIは、その権限の範囲内で機密情報を探すために必要な労力を減らす。

エンタープライズ検索または検索拡張システムを導入するチームは、広範な展開の前に、コンテンツ所有権、保持、アクセス継承、インデックス作成の境界を検討すべきである。適切に設計されたAIナレッジベースは、インデックス化されたすべての情報を同等に利用可能と扱うのではなく、ソースの権限を保持すべきである。

これには慎重なログ記録も必要である。セキュリティチームには、エージェントが何にアクセスしたか、どのツールを呼び出したか、どの変更を提案したか、誰が重要なアクションを承認したかを示す記録が必要だ。その証拠がなければ、自動化されたワークフローは、置き換えるレガシーシステムよりも調査が困難になる。

プロセス改革には、AI生成の脆弱性報告に対する厳格な受付要件も含めるべきである。提出内容は、影響を受けるバージョンを特定し、信頼境界を説明し、再現手順を示し、観測された挙動とモデルが生成した推測を分けなければならない。

その後、保守担当者は自動化を使って重複をクラスタリングし、環境の詳細を確認し、実証された影響を持つ発見事項に優先順位を付けられる。目的はAI支援研究を拒否することではない。主張の量に見合う証拠を求めることである。

調達チームにも役割がある。購入者はベンダーに対し、エージェント生成パッチをどのようにテストするか、レガシーコンポーネントをどう管理するか、協調的開示をどう扱うか、繰り返される脆弱性の類型をどう測定するかを尋ねるべきである。「セキュリティにAIを使う」という約束は、これらの詳細がなければほとんど保証にならない。

懐疑的な見方も依然として重要である。現在のモデルには一貫性がなく、印象的なデモはしばしば厳選された環境を用いている。AIによる発見の一部は大規模な人間の修正を必要とし、完全自律型の悪用は支援付きスクリプティングや偵察ほど一般的ではない。

しかし、一貫性のなさは従来の堀を取り戻すものではない。攻撃者は、すべての試行を成功させる必要はない。安価な並列試行は、成功率が低くても、特に多数の類似した標的に対しては運用上の価値を持ち得る。

防御側は、この経済性を前提に計画しなければならない。到達可能なコード、バイナリ、構成、パッチは自動化された精査を受けると想定すべきである。防御側の優位性は、精査が失敗することを期待するのではなく、より安全な設計と、より迅速で検証済みの対応から得られなければならない。

防御側が追いつけるかを示す3つのシグナル

次の段階を決めるのは、パッチ検証、重要インフラの露出、そして組織が件数を数えるのではなく繰り返される欠陥を防げるかどうかである。

AIが生成したパッチの信頼性を測定することが、最初の兆候となる。今後の評価では、最近開示された脆弱性を対象にし、現実的なアプリケーションの挙動を維持し、再現可能な手法を公表すべきだ。完全な修正の割合が上昇すれば、現在の発見から対処までの隔たりは縮まるだろう。

重要なのは、パッチがコンパイルできるかどうかではない。研究者は、それが根本原因を解消しているか、新たな弱点を生んでいないか、期待される挙動を維持しているかを検証しなければならない。独立した評価を経ても成立する改善は、監督下にある防御的自動化の有効性をより強く裏付けるだろう。

失敗率が現在の水準付近にとどまるなら、より慎重な結論が妥当となる。AIは発見件数を増やし続ける一方で、専門家による検証は引き続き制約要因となるだろう。

2つ目の兆候は、産業用コントローラーやその他のレガシーシステムの露出状況である。政府機関や運用事業者は、インターネットからアクセス可能なPLCが減少しているか、デフォルト認証情報が使われなくなっているか、組織が未承認の産業プロトコルトラフィックを検知しているかを追跡すべきだ。

露出したコントローラーに対するAI支援攻撃が再び発生すれば、中核的な判断はより強く裏付けられる。攻撃者が、弱いアーキテクチャで依然として守られているシステムに対し、公開情報を繰り返し実用的な攻撃ツールへ転換していることを示すからだ。

露出が持続的に減少すれば、最も警戒すべき予測は弱まる。秘匿性が回復するわけではないが、基本的な隔離と資産管理によって、エージェントから実用的な攻撃経路を奪えることを示すだろう。

3つ目の兆候は、セキュリティ組織が進捗をどのように測定するかだ。検出件数と修正完了までの中央値だけに注目するチームは、自動化された報告が増えるにつれて苦戦する。繰り返し発生する欠陥クラス、露出資産、根本原因、検証済みの修正を追跡するチームは、将来の需要を減らせる。

ベンダーや大規模なソフトウェアプロジェクトが、こうしたより深い指標を公表するかに注目したい。インジェクション、認可、メモリ安全性、設定に関する欠陥が減少している証拠があれば、プロセス変更が機能していることを示唆する。

開示件数が記録を更新し続ける一方で、同じ欠陥クラスが再び現れるなら、防御側はMoussourisが「トレッドミル」と表現した状態にとどまる。発見の高速化によってより多くのリスクは明らかになるが、それを生み出す仕組み自体は変わらない。

実務的な対応は今すぐ始めるべきだ。忘れられたシステムを棚卸しし、不必要な露出を取り除き、権限境界をテストし、すべての自動化されたセキュリティ上の主張に証拠を求める。エージェントは研究者やエンジニアの支援に活用しつつ、重大な修正は再現可能なテストと責任あるレビューの下に置くべきだ。

セキュリティ・バイ・オブスキュリティに依存するAI対策は、すでに負け筋となっている。従来の防御は、希少な好奇心と専門的な労働力に依存しており、その両方がソフトウェアサービスとして利用可能になりつつあるためだ。

より難しい課題は、詳細が理解可能になった後でも安全であり続けるシステムを構築することである。隠れた依存関係、継承された権限、露出したコントローラーのうち、あなたの組織が今日、AIエージェントに調査されたくないものはどれだろうか。