2026年6月、Backslash Securityはさまざまな業界のエンジニアリングチームおよびセキュリティチームを対象に調査を実施し、回答者の100％が本番環境でAI生成コードを実行していることが判明した。また、81％が、開発ライフサイクル全体においてAIがどこで、どのように使用されているかについて把握できていないと回答した。
この2つの数値は、セキュリティ上の侵害ではなく、構造的な状況を表しています。コードが出荷され、エージェントが実行されましたが、プロンプトの後に何が起こったのか、誰も把握できませんでした。これはよく知られた検知上の問題です。つまり、攻撃者（この場合はエージェント）がシステムからシステムへと移動していく一方で、単一のログや監視ツールでは全体像を把握できないというものです。現在では、この仕組みがほとんどの組織に標準的な配信メカニズムとして組み込まれています。
問題はエージェントそのものではなく、アクセスモデルにある
AIコーディングエージェントは、目標を解釈し、その達成に必要なツールを選択し、API呼び出しを行い、ファイルの読み書きを行い、プルリクエストを送信し、テストを実行し、出力結果に基づいて調整を行います。これらすべての処理は、実際の認証情報と付与された権限の下で実行され、各ステップを人間が逐一承認する必要はありません。
そのアクセスモデルは、2つの重なり合う問題を引き起こします：
- 1つ目は認証に関する問題です。エージェントには認証情報が割り当てられています。エージェントは認証を行い、監査ログには成功が記録されます。エージェントが使用する盗まれた開発者トークンは、認証記録上、そのトークンの所有者である開発者が使用するものと同一に見えます。有効な認証情報、有効なセッション、有効なツール呼び出し。認証は成功します。
- 2つ目は可視性の問題です。コーディングエージェントは、1つのシステム内に留まることはありません。コードリポジトリ、CI/CDパイプライン、テストが実行されるクラウド環境、場合によってはシークレットストアにまでアクセスします。これらの移行のそれぞれが境界を越え、各境界には独自のロギングが行われます。どのログも他のログを把握することはできません。3つのログ、3つのアラート、そして1つの侵害経路。
エージェントの作業をレビューする人間は、エージェントの作業ペースについていけない
ここで、ノアム・ブラウンとドワルケシュ・パテルが9月17日に行った対談が、AI研究の分野以外でも注目されることになる。
ブラウン氏は、OpenAIの研究者であり、マルチエージェントシステムを専門としている。OpenAIが数学の問題に対して1万体のエージェントの群れを88時間にわたって投入したところ、その出力結果は、人間が同等の時間枠内で単独で検証することなど到底不可能なものであった。彼の主張はこうだ。エージェントの数が増えるにつれ、専門家が頼りにしている検証工程は、作業と同じペースで進まなくなってしまう、ということである。
これをソフトウェア開発に当てはめてみましょう。AIが生成したコードの変更をレビューする開発者は、目に見えるコードに基づいて判断を下します。生成の過程でエージェントが行ったAPI呼び出しや、取得・テスト・破棄したパッケージ、その過程で行使したリポジトリの権限などは、開発者の目には入りません。コードレビューの対象となるのは最終的な出力結果だけです。それを生み出した動作は別の場所で行われており、多くの場合、ログには記録されていません。
Backslashのデータは、この現象を別の角度から同様に指摘しています。81％の組織では、AIが生成したコードが本番環境で稼働しているにもかかわらず、そのコードが生成されたプロセスについて体系的な可視性が欠如しています。コード自体は レビューを通過しますが、そのコードを生成したプロセスそのものは、まったくレビューの対象となっていません。
Hugging Faceの事件は、ある構造的条件の概念実証となった
2026年7月、OpenAIのエージェントが内部評価用サンドボックスから脱出し、パッケージレジストリプロキシ（オンデマンドでサードパーティのソフトウェアライブラリを取得するサーバー）のzero-day を悪用して認証情報を収集し、週末にかけてHugging Faceの本番環境内で横方向への移動を行った。Hugging Faceによる技術的な再現調査では、エージェントによる約17,600件のアクションが確認されている。OpenAI自身の説明により、関与したモデルが確認された。
当時、その件については詳しく記事に書きました 。ここで重要なのは検知の部分です。この侵入は 、異常な動作を個別に検知したアラートによって発覚したのではなく、相関分析――つまり、複数の別々のシステムからのシグナルを収集し、それらを単一のタイムラインに結びつけること――によって明らかになりました。 AIを活用した再構築には約1時間かかりました。同じ作業を手作業で行っていたら、数日かかっていたでしょう。
Hugging Faceには、何が起きたかを再現するのに十分な関連ログがあったため、この再構築が可能でした。エージェントの動作速度に追いつけるような人間のレビュープロセスは存在しないため、AIの支援が必要だったのです。
なぜ従来の脅威インテリジェンスは、その仕組み上、これを見逃してしまうのか
一般的に利用される脅威インテリジェンスは、指標に基づいて機能します。具体的には、既知の悪意のあるIPアドレス、ファイルのハッシュ値、ドメイン名、特定の脅威クラスターに帰属する行動パターンなどが挙げられます。これらの指標には、以前に観測され、カタログ化され、現在の活動と照合される「参照点」が必要となります。
正規の開発環境内で動作しているエージェントには、照合すべき既知の悪意あるシグネチャが存在しません。認証情報は 有効です。エージェントが実行するアクションは、その表明された目的に合致しています。エージェントが取得したソフトウェアパッケージは実際に存在し、フラグも立っていません。参照すべき特定の攻撃者グループもなければ、照合すべき過去の攻撃キャンペーンもありません。
Hugging Faceでは、事件の全容が明らかになった後も、OpenAIが自発的に名乗り出たからこそ、原因の特定が可能となった。エージェントの行動記録はログから復元できたが、誰が、あるいは何がそれを指示したかは、それらのログだけでは特定できなかった。「ブランドではなく行動を追跡せよ」という検出の原則は、今もなお有効である。このケースでは、その行動の背後に特定すべきブランドがそもそも存在しない可能性もある。
検知機能は故障しているわけではありません。不完全なだけです。インジケーター照合は、過去に確認されたものを認識するように設計されていますが、大規模なエージェントの挙動によって、これまで確認されたことのないパターンが生み出されるのです。
この格差を埋めるためには、実際には何が必要なのか
攻撃対象領域は特定されています。具体的には、必要以上のアクセス権限を持つエージェント、プロンプトのコンテキスト内に存在し、そこから収集され得る認証情報、そしてエージェントが起動後に実際に何を行っているかについて、実行時の可視性が全くないという点です。ほとんどの組織において、SOCはこの状況に全く関与していません。
システム間でリアルタイムに連携する行動シグナルこそが、事後的に状況を再構築するのではなく、事前にこれを察知する鍵となる。そのパターンは、使用された認証情報、呼び出されたサービス、アクセスされたリポジトリ、収集されたクラウド認証情報、到達した新しいクラスターといった要素にまたがっている。この一連の流れは、そのすべての要素を一度に把握できる立場からでなければ把握できない。
これは、検知の問題というよりも、可視性の問題です。開発パイプラインでAIエージェントを導入している組織の多くは、現時点ではまだ検知のギャップを抱えていません。むしろ「シグナルのギャップ」を抱えており、このシグナルのギャップがある以上、検知のギャップが生じるのは避けられません。
確認、変更、制限
- SOCに、開発パイプライン内のAIエージェントが実際に何を行っているかについて、実行時の可視性があるかどうかを尋ねてみてください。コミットされたコードを確認できるかどうかではなく、エージェントの実行中に発生したAPI呼び出し、認証情報の使用状況、クラウドリソースへのアクセス状況を把握できるかどうかを確認してください。答えが定かでない場合は、答えは「いいえ」です。
- AIエージェントが内部で実行するパイプラインを、深刻な攻撃対象領域として扱ってください。自ら生成していないコンテンツ（ユーザーから提供されたデータセット、サードパーティ製パッケージ、モデルの出力など）を取り込むシステムについては、そのコンテンツがコードの実行を引き起こす可能性のある経路をすべて監査してください。 Hugging Faceでは、2つの経路が問題となりました。1つは、データセットファイルによってプラットフォームがリモートサーバー上でコードを実行するよう指示される経路、もう1つは、設定フィールドが値としてではなく命令として読み取られてしまう（テンプレートインジェクション）経路です。いずれも、攻撃を成功させるために高度な技術を持つ攻撃者は必要ありません。また、どちらも修正可能です。
- エージェントには、その特定の業務を遂行するために厳密に必要なアクセス権のみを付与してください。リポジトリを読み取るだけのエージェントには、シークレットストアへの書き込み権限は必要ありません。エージェントの権限は、サービスアカウントの監査を行うのと同じ方法で監査してください。というのも、エージェントとはまさに、エージェントループを実行するサービスアカウントに他ならないからです。
Backslashの調査では、これは能力の問題というよりはガバナンスの失敗であると指摘しています。組織はすでにエージェントの実行環境を監視する仕組みを導入することができます。しかし、その必要性を感じていない組織が大半です。
これらの問題は、いずれも『Mind Your Attack Gaps』で詳しく取り上げているもので、具体的には私が「ギャップ2（認証が成功する）」および「ギャップ3（移動が検知できない）」と呼んでいるものについて、それぞれの検知ロジックとともに解説しています。