「全ての攻撃者がAIを使用」GoogleのGTIG報告｜6時間で数千件の認証情報侵害・エージェント型攻撃への移行と企業の防御策【2026年9月最新】

2026年9月9日（米国時間）、Googleの脅威インテリジェンス組織 GTIG（Google Threat Intelligence Group） が、レポート「GTIG AI Threat Tracker: From Prompting to Autonomy – The Evolution of Adversarial AI（プロンプティングから自律へ：敵対的AIの進化）」を公開しました。中核となる観測は、攻撃者がクラウド基盤を侵害してから、AIエージェントによる大規模な認証情報収集キャンペーンを計画・構築・実行し終えるまでを6時間未満で完了させたという事例です。

ただし、広く引用されている「全ての攻撃者がAIを使用している」という表現はレポート本文の結論ではなく、GTIGチーフアナリストのJohn Hultquist氏の発言です。また、完全に自律した攻撃パイプラインは実環境ではまだ観測されていません。この2点を混同したまま社内に共有すると、判断を誤ります。

この記事でわかること

• GTIGレポート2026年9月版が何を報告したのか（公式ブログ原文ベース）
• 「6時間で数千件」のインシデントを段階ごとに分解した中身
• 「全ての攻撃者がAIを使用」という表現の正確な出典と、レポート本文との温度差
• 名指しされた脅威アクター（中国・ロシア・イラン・北朝鮮・金銭目的）とAIの用途
• .claude/ .cursor/ やMCPサーバなど、AI開発環境が直接狙われている手口
• LLMJacking（クラウドAI基盤の乗っ取り）の気づき方
• Google側の防御プロダクトと、日本企業が今週着手できるチェックリスト
• レポートを読むうえで断定してはいけない5つの点

誰向けの記事か

• 情報システム部門・セキュリティ担当・CISO配下で、経営層への報告材料を探している人
• Claude Code・Cursor・Copilot・MCPなどAI開発ツールを業務で使っている開発組織
• クラウド上で生成AI基盤を運用している、または運用を検討している企業

なお、本レポートの公式日本語版は2026年9月11日時点で未公開です（過去回は日本語版あり）。本記事の引用は英語原文に基づく訳で、用語は過去回の公式日本語訳（「AI 脅威トラッカー」「脅威アクター」「エージェント型AI」）に揃えています。

3行でわかる今回のGTIGレポート

1. 何が変わったか：攻撃者のAI利用が「プロンプトを打って文面やコードを作らせる」段階から、エージェントにスキャン・認証情報収集・トラブルシューティングまで任せるワークフローへ移った。GTIGはこれを「プロンプティングから自律へ」と表現しています。
2. 具体的な観測：2026年Q2、金銭目的とみられる攻撃者が被害組織のクラウド基盤を侵害し、自律型マルチエージェントの攻撃フレームワークを展開して、6時間未満で数千件のサードパーティ認証情報を侵害。使われたのは特殊なサイバー兵器ではなく、市販のAIコーディングチャットボットとMarkdown形式の指示ファイルでした。
3. 企業にとっての意味：防御側が前提にしてきた「数日〜数週間の対応ウィンドウ」が数時間単位に圧縮された。一方で完全自律の攻撃はまだ観測されていないため、恐怖ではなく「検知・対応の時間前提の見直し」と「AI開発環境の棚卸し」という実務に落とすのが正しい受け取り方です。

業界全体としての危機感の表明については、AIサイバー攻撃で100社超が共同声明にまとめています。今回のGTIGレポートは、その警告を裏づける実測データ側の資料という位置づけになります。

GTIG AI Threat Tracker 2026年9月版とは何か

画像出典: Google Cloud Blog「From Prompting to Autonomy」

このレポートは、GoogleがMandiantのインシデントレスポンス実績・脅威アクター追跡・Geminiのプラットフォーム防御データを統合して定期発行している、敵対的AI利用の観測記録です。

出典: Google Cloud Blog（Threat Intelligence）

レポートが挙げた5つの潮流

Google Cloud Blogは、今回の観測を5つの潮流に整理しています。

注目すべきは3番と4番です。AIが特定の工程だけを助けるのではなく、攻撃の全工程に薄く広く効いているという整理になっています。

過去3回との比較｜1年で何が変わったか

GTIGのAI脅威トラッカーは2025年11月が初版で、今回が4回目です。回次を並べると、攻撃側のAI利用がどう成熟したかが見えます。

わずか10カ月で「文面作成の補助」から「攻撃フレームワークの自律運用」まで来ています。日本語圏では2026年2月版の内容（モデル蒸留・モデル抽出）を解説した記事がまだ検索上位に残っていますが、攻撃者の実態はすでに2段階先へ進んでいる点に注意してください。

「全ての攻撃者がAIを使用」は誰の、どういう発言か

この表現はレポート本文の結論ではなく、GTIGチーフアナリストの発言です。引用元をたどると、性質がまったく違います。

• 発言者：John Hultquist（GTIG チーフアナリスト）
• 発言内容："At this point, we can assume that all threat actors are using AI in some capacity and their operations have benefited."（現時点では、全ての脅威アクターが何らかの形でAIを使用しており、その活動が恩恵を受けていると想定してよい）
• 併せての発言："Criminals, like the ones who conducted a mass exploitation campaign in just six hours, will gravitate to attacks that are faster than we can respond to."（わずか6時間で大規模攻撃を行ったような犯罪者は、我々が対応できる速度を上回る攻撃に引き寄せられていく）

一方、レポート本文の表現はもっと慎重です。原文は "GTIG continues to observe the widespread adoption and incorporation of AI technologies by threat actors with wide-ranging motivations across multiple geographic portfolios."（多様な動機を持つ脅威アクターによるAI技術の広範な採用と組み込みを、GTIGは引き続き観測している）となっており、「全て」とは書いていません。

つまり正確には、「全数調査でAI使用が確認された」のではなく、「防御側の運用前提としては全アクターがAIを使っていると想定すべき段階に来た」というアナリストの判断です。この違いは実務上も意味があります。前者なら「AI利用の痕跡があるかどうか」で攻撃を分類できますが、後者はAIの痕跡の有無で攻撃者を選別する運用そのものが成立しないことを意味するからです。社内報告では「Googleが全攻撃者のAI使用を証明した」と書かず、「Googleの主席アナリストが、全アクターのAI利用を前提に防御設計せよと述べた」と書くのが正確です。

6時間で数千件｜エージェント型侵害インシデントの5段階

今回のレポートで最も具体的な観測が、この2026年Q2のインシデントです。Google Cloud Blogの原文は "In Q2 2026, GTIG observed threat actors compromise a cloud resource, then plan, build, and execute an agent-enabled mass credential harvesting campaign in under six hours."（2026年Q2、GTIGは脅威アクターがクラウドリソースを侵害し、エージェント対応の大規模認証情報収集キャンペーンを計画・構築・実行するまでを6時間未満で完了させたのを観測した）と記述しています。

公式記述の範囲で、流れを段階に分けると次のようになります。

結果として、数千件のサードパーティ認証情報が侵害され、所要時間は6時間未満でした。

なぜ「6時間」が防御側にとって重大なのか

問題は速度そのものよりも、その速度を出すのに特別なリソースが要らなかった点です。

• 使われたのは特殊なサイバー兵器ではなく、一般に入手できるAIコーディングチャットボットとMarkdownの指示ファイルでした。Googleは、本来なら「より大規模でリソースの厚いグループに関連する規模と速度」で、少人数が活動できたと表現しています。
• 攻撃工程からhuman-in-the-loop（人間の介在）のレイテンシがほぼ消えたため、従来「攻撃者が次の手を考えている時間」に依存していた検知・封じ込めの猶予がなくなりました。
• 攻撃トラフィックが被害者自身の正規クラウドIPから出るため、外形的には自社の正常な通信に見えるという厄介さがあります。

注意点：このインシデントで使われたAIコーディングチャットボットの製品名は、公式に特定されていません。 原文は "an AI coding chatbot" とだけ記載しています。特定のツール名を挙げて「◯◯が悪用された」と書いている記事があれば、それは推測です。個別ツールの悪用が公式に確認された事例としては、Claude Codeを悪用した恐喝AIエージェント事件のように、提供元自身が調査結果を公表しているケースを参照してください。

まだ「AIが単独で攻撃を完遂している」わけではない

レポートおよび報道は、現時点での限界も明示しています。

1. 完全自律の攻撃パイプラインは、実環境でまだ観測されていない。エージェント化は進行中ですが、「AIが人間の関与なしに攻撃を最初から最後まで完遂した」段階ではありません。今回の6時間インシデントも、人間が目標設定と指示書の作成を行ったエージェント型ワークフローです。
2. フロンティアモデルのコアセキュリティロジックを突破する画期的な手法を、脅威アクターはまだ獲得していない（2026年前半のGTIG観測）。そのため攻撃者は、統合ライブラリへの悪性コード埋め込みやトロイの木馬化した設定ファイルの配布といった、従来型のサプライチェーン戦術に回帰しています。
3. レポート自身が、能力として実験段階・未展開に留まる事例も併記しています。

「AIが自律的にサイバー攻撃を完遂した」という要約は誤りです。正確には「人手を大幅に削減したエージェント型ワークフローが実運用に入った」であり、防御側が備えるべきなのもこの範囲です。AIエージェントが想定外の動きをするリスクの整理は英AISIによるAIエージェント暴走インシデントの報告、エージェント同士が協調してしまう挙動はAIエージェントが社内に「秘密の掲示板」を構築した事例も参考になります。

名指しされた脅威アクター｜国家系と金銭目的が同じ方向へ収束

レポートは複数の脅威アクターを実名（追跡名）で挙げています。読みどころは個々のアクターよりも、帰属も動機も違うグループが、独立に同じ方向＝エージェント化へ収束しているという構図です。

UNC6508が侵害した環境の中にローカルLLMを構築していた点は、防御実務に直結します。商用API側のログや利用監視でAI悪用を検知する発想は、ローカルモデルには効きません。「AI利用の検知」を外部APIの通信監視だけに頼る設計は、すでに前提が崩れつつあります。

開発現場が直接狙われている｜AI設定ファイルとMCPのサプライチェーン

日本語の報道でほぼ触れられていないのがここです。AIコーディングツールを使っている開発組織は、今回のレポートの直接の当事者にあたります。

出典: Model Context Protocol 公式サイト

DUSTMAKER｜開発ノイズに紛れるマルウェア

DUSTMAKERは、クロスプラットフォームのJavaScript型マルウェアで、CI/CD環境に最適化されています。手口は次の通りです。

特に重い意味を持つのが下2つです。署名（SLSA attestation）が付いていても安全とは限らないという前提に切り替える必要があり、これはAIコーディングエージェントの自動信頼チェックがそのまま素通りしてしまうことを意味します。また、LLMベースのスキャナ自体が攻撃対象になるため、AIレビューを最終防波堤に置く設計は危険です。実際にAIレビューをすり抜けた事例として、GitHub Copilot AIレビューをすり抜けた脆弱性によるSnowflake社内Jira侵害があります。間接プロンプトインジェクションの具体的な突破手口はClaude Code Auto Modeが間接プロンプトインジェクションで突破された事例にまとめています。

AIコーディングツールの設定ファイルが名指しで狙われている

情報窃取型マルウェアACRSTEALERのコントローラが、AI開発ツールの設定ファイルを名指しで標的にしていたことが報告されています。

このほか、SANDCLOCK（Python製の認証情報スティーラー／2026年3〜4月）、SOMBERMEME（開発者経由で配布されるバックドア）、Shai-Hulud（侵害後の永続C2フレームワーク）、Phalanx（自律ペネトレーションテスト用のオープンソースフレームワーク）などが挙げられています。中でもReconと呼ばれる偵察・認証情報管理の自動化フレームワークは、AGENTS.md や KNOWLEDGE.md といったエージェント設定ファイルとメモリモジュールを備え、23,800件超の窃取シークレットを単一のC2サーバのダッシュボードで管理していました。攻撃側が自分たちの運用にも、防御側と同じエージェント設計思想を持ち込んでいる形です。

開発者が今日確認できることは明快です。自分の開発マシンとリポジトリで、AIツールの設定ファイルにAPIキーが平文で残っていないか、.claude/ .cursor/ .vscode/ 配下に身に覚えのないファイルがないかを見てください。ローカル環境の権限とサンドボックス設計はClaude Codeのセキュリティと安全な使い方、AI支援開発全体のリスク整理はAIコーディングのセキュリティリスクにまとめています。

MCPサーバとパッケージのトロイの木馬化

金銭目的のUNC6780（TeamPCP／Altered Spider）は、オープンソースのサプライチェーンを直接侵害していました。

• 正規開発者のアカウントを侵害する
• 正規MCPサーバのトロイの木馬化フォークを公開する（例：tiktoken_mcp）
• 公式組織のGitHubリポジトリに悪性コードを注入する（例：azure-functions-mcp-extension）
• MCPツールにバックドアを仕込み、ダウンロード時に自動でペイロードが取り込まれるようにする
• 窃取データは直接販売するか、ランサム／恐喝グループへ引き渡す（LAPSUS系の恐喝アクターへのハンドオフの痕跡あり）

MCPは、AIエージェントに外部ツールやデータソースを接続するための仕組みです（仕組みと対応ツールはMCPとはを参照）。接続先が増えるほど、そのままAIエージェントの攻撃面が増える構造になっているため、社内で使っているMCPサーバについて「誰が公開しているのか」「どのリポジトリのフォークなのか」「直近の更新は誰がしたのか」を一度洗い出す価値があります。

LLMJacking｜クラウド請求の異常が最初の兆候になる

LLMJackingは、侵害したクラウド環境で生成AIの計算資源を勝手に使う攻撃です。データを盗むだけでなく、被害者の請求でAIを動かす点が特徴で、GTIGは不正アカウント市場の拡大と併せて報告しています。

地下市場の動向として挙げられているのは次の点です。

• AIアカウントの売買が前年比で増加し、ClaudeとGeminiの認証情報の需要が高い
• Cursor ProやDevinなど自律型IDEのアカウント価格は、2026年に2倍超へ上昇
• 主な入手経路は情報窃取型マルウェア（LUMMAC.V2 / STEALC.V2 / VIDAR / ACRSTEALER など）

2026年4月に観測されたクラウド乗っ取りの流れは、そのまま自社の監査項目に転用できます。

実務上の要点は、クラウドの請求額とクォータ申請が、最も早く気づける異常シグナルになりうることです。セキュリティ製品のアラートより先に、経理側が「今月のクラウド費用が跳ねている」と気づくケースがあります。請求異常の一次窓口をセキュリティ側にエスカレーションする経路を作っておくだけで、検知が数日早まる可能性があります。

社内で把握できていないAI利用（シャドーAI）が、この文脈で最初に潰すべき穴のひとつです。実態把握の手順はシャドーAIの企業リスク、国内での実例はRIZAPが顧客の個人情報を私用生成AIにアップロードした事例を参照してください。

モデル蒸留攻撃｜1回のキャンペーンで1億プロンプト超

レポートはモデル蒸留（Distillation）に対する攻撃圧力も報告しています。1回のキャンペーンで1億プロンプトを超える協調的な大量クエリが定常的に観測されており、標的はGeminiの視覚理解・音声理解・画像生成・動画生成といった主力能力です。手口は、数千件の窃取済み認証情報と不正アカウントにクエリをローテーションさせるというもので、LLMJackingや不正アカウント市場と地続きになっています。

Google側は、Gemini由来の蒸留モデルを識別し、来歴（provenance）を追跡する技術を開発し、無許可の"student"モデルの性能を劣化させるリアルタイム防御を実装したとしています。

一般企業にとっては直接の当事者性は薄いテーマですが、自社でファインチューニングモデルやRAG基盤を運用している場合、「APIキーが漏れる＝推論コストを盗まれる」だけでなく「学習資産そのものを抜かれる」という文脈が加わる点は押さえておく価値があります。生成AI利用全般のリスク整理は生成AIのセキュリティリスクにまとめています。

Google側の対応と防御プロダクト

出典: Google Cloud Security 公式サイト

GTIGは観測だけでなく、プラットフォーム側の対処も併記しています。

プラットフォーム対策

• 悪用されたアセット・アカウントの無効化
• 脅威監視の知見をセーフティ分類器とガードレールに直接フィードバックする継続的なモデルハードニング
• DeepMindによる分類器の強化（モデル自体が該当する攻撃支援を拒否するよう改善）
• 2026年6月、中国拠点のサイバー犯罪サービス「Outsider Enterprise」を停止
• Gemini悪用に対するGoogle初の法的措置。プラットフォーム提供者が自社AIの不正利用に対して取れる手段の先例となる動きです

防御側プロダクト

出典: Google Cloud Blog（AI Threat Defense） / Google DeepMind 公式 / SAIF 公式サイト

一般企業がすぐ使えるのは、現時点ではSAIFの自己評価ツールだけと考えるのが現実的です。AITDは価格未公表でパートナー経由、Gemini 3.8 Flash Cyberは限定アクセスプログラム経由で、いずれも「申し込めば明日から使える」ものではありません。防御側AIの提供枠組みは各社が並行して進めており、OpenAI Daybreak（サイバーセキュリティ連合）やAnthropic Project Glasswingも同様に審査・承認が前提です。防御側AIの全体像はサイバーセキュリティ業界のAI活用事例を参照してください。

なお、攻撃側AIの能力水準を把握しておきたい場合はGPT-Redとは（自動レッドチームAI）が参考になります。

GTIGが業界レベルで提言していること

• オープンソースAIに対する、強制力のある業界横断の安全ベースラインの確立
• 無検閲（uncensored）派生モデルを制限するための、プラットフォーム横断のポリシー協調
• Gemini Enterpriseのような隔離された安全な環境でのオープンソースモデル運用

日本企業が今週やること｜実務チェックリスト

レポートを読んで終わりにしないための項目を、着手コストが低い順に並べます。すべてGTIGが今回報告した手口に直接対応しています。

1. クラウドとIDの棚卸し（LLMJacking対策）

2. AI開発環境の監査（開発組織向け）

• AIツール設定ファイルの平文APIキーをなくす。Clineの secrets.json、Continue AIの config.yaml を含め、リポジトリとローカルの両方を対象にする
• .claude/ .cursor/ .vscode/ 配下に身に覚えのないファイル・自動実行設定がないかを確認する。ワークスペースを開いた瞬間に走るタスクの定義は特に重点的に
• MCPサーバ・IDE拡張のサプライチェーン確認。公開者、フォーク元、直近の更新履歴、スター数の急変を確認し、社内で使ってよいものをリスト化する
• CI/CDのOIDCトークン権限を最小化する。あわせてワークフローログの削除を検知対象に加える（DUSTMAKERはログ削除を行う）
• 署名が付いていても安全とは限らないという前提をチームで共有する。SLSA Build Level 3の有効な署名付きで汚染パッケージが公開された事例がある以上、署名検証は必要条件であって十分条件ではありません
• LLMベースのセキュリティスキャナを最終防波堤にしない。スキャナ自体がプロンプトインジェクションで無力化される手口が確認されています
• 社内のAIエージェントに与えている権限（書き込み・削除・外部送信）を用途ごとに見直す。設計の全体像はAIエージェントのセキュリティ対策ガイドにまとめています

3. 検知・対応の「時間前提」を見直す

• インシデント対応計画が想定している初動時間を「数日」から「数時間」に置き換えて成立するかを机上で検証する
• 認証情報のローテーション周期を短縮し、シークレット管理を集約する（数千件規模の認証情報が6時間で抜かれる前提に合わせる）
• IPレピュテーションに依存した検知の限界を認識する。攻撃トラフィックが被害者自身の正規クラウドIPから出るケースがある以上、送信元評価だけでは弾けません
• 自社環境内に外部APIを経由しないローカルLLMが動いていないかを確認する。API通信の監視だけではAI悪用を検知できないケースがあります
• SAIFのリスク自己評価（saif.google）を一度実施し、AIエージェント固有のリスク項目で自社の抜けを洗い出す

このリストは、AIサイバー攻撃の共同声明が一般企業に求めた項目（最小権限・パッチSLA短縮・AI生成コードのレビュー）とほぼ重なります。別施策として立てず、1本の棚卸しでまとめて処理するのが効率的です。

今すぐ優先度を上げるべき企業／当面は基本対策で足りる企業

今すぐ優先度を上げるべき企業

• クラウド上で生成AI基盤（Vertex AI／Gemini／Bedrock等）を運用している組織。今回のインシデントもLLMJackingも、クラウドAI基盤が起点です
• Claude Code・Cursor・Cline・Continue・Copilotなどを開発フローに組み込んでいる開発組織。設定ファイル・CI/CD・MCPが名指しで狙われています
• MCPサーバやIDE拡張を社内で自作・導入している組織。フォークの出所確認が未整備なら最優先
• 外部公開のAPIエンドポイントやCloud Runサービスを持ち、公開範囲の棚卸しを1年以上していない組織
• 認証情報が漏えいした際の影響範囲が広い、SaaSを多数連携させている組織（UNC6240のようなSaaSからのデータ窃取・恐喝の対象になりやすい）

当面は基本対策の完了を優先すればよい企業

• クラウドAI基盤を自社で運用しておらず、生成AIの利用がブラウザ版のチャットツールに限定されている組織。優先すべきは多要素認証と、シャドーAIの実態把握です
• 開発機能を持たず、AIコーディングツールを社内で使っていない組織。今回の開発者向けの手口は該当しません
• 多要素認証の全面適用と管理者権限の棚卸しがまだ完了していない組織。この段階で防御用AIツールの検討に進むのは投資効率が悪く、順序が逆です

判断の分かれ目は企業規模ではなく、AIに実行権限とクラウド資源を与えているかどうかです。AIエージェントの基本的な仕組みから確認したい場合はAIエージェントとは、生成AI全体の前提整理は生成AIとはを参照してください。

このレポートを読むときに断定してはいけない5点

社内共有や外部発信で誤りやすい箇所を、あらかじめ整理しておきます。

このほか、現時点で未確認の項目として、公式日本語版の公開時期、Google AI Threat Defenseの価格、Gemini 3.8 Flash Cyberの一般提供時期、UNC6780が侵害したパッケージの完全な一覧があります。日本国内での同種インシデントの有無や、JPCERT/CC・IPAの関連注意喚起についても、本記事執筆時点では確認できていません。

よくある質問

Q. 自社が「6時間インシデント」と同種の攻撃を受けたかどうかは、どう確認すればいいですか。

完全な確認方法はありませんが、優先度の高い確認先はクラウドの監査ログです。具体的には、①想定外のAIサービス・GPUインスタンスの有効化、②allUsers で公開されたリソースの発生、③サービスアカウントの新規作成と鍵エクスポート、④クォータ増申請と請求額の急増、の4点です。攻撃トラフィックが自社の正規IPから出る手口があるため、外向き通信の送信元評価だけでは判断できません。

Q. 「AIコーディングツールを社内で禁止すべき」ということですか。

レポートはそう主張していません。狙われているのはツールそのものの脆弱性というより、設定ファイルに平文で置かれた認証情報と、レビューされていない自動実行設定です。禁止よりも、APIキーの管理方法・プロジェクト配下の隠しディレクトリの監査・CI/CDの権限最小化を先に整えるほうが効果が大きいと考えられます。

Q. MCPサーバは使わないほうが安全ですか。

正規MCPサーバのトロイの木馬化フォークや、公式リポジトリへの悪性コード注入が確認されているため、導入前の出所確認が必須という理解が適切です。公開者・フォーク元・更新履歴を確認し、社内で使ってよいMCPサーバをリスト化して運用するのが現実的な落としどころです。

Q. SLSA署名が付いたパッケージなら信頼できますか。

今回のレポートでは、GitHub ActionsランナーのメモリからOIDCトークンを抽出し、信頼された発行者として有効なSLSA Build Level 3の署名付きで汚染パッケージを公開した事例が報告されています。署名検証は必要ですが、それだけで安全とは判断できません。

Q. 中小企業がまず1つだけやるなら何ですか。

クラウド請求額の異常監視のしきい値設定と、経理からセキュリティへのエスカレーション経路の明文化です。追加費用がほぼかからず、LLMJackingの初期兆候を捉えられる可能性があります。開発組織であれば、AIツール設定ファイルの平文APIキー排除を優先してください。

Q. 公式の日本語版レポートはありますか。

2026年9月11日時点では未公開です。過去回（2026年2月版・5月版）は日本語版が公開されているため、後日公開される可能性があります。正確な文言は英語原文で確認してください。

Q. Gemini 3.8 Flash CyberやGoogle AI Threat Defenseは自社でも導入できますか。

Gemini 3.8 Flash Cyberは政府・信頼できるパートナー向けの限定アクセスプログラム「Google Fairwind」経由での提供で、一般提供の有無・時期は現時点で未確認です。Google AI Threat Defenseは公開価格が未公表で、パートナー経由の問い合わせが前提になります。「無償または即時に使える」と想定した計画は立てないほうが安全です。

まとめ

2026年9月9日公開のGTIGレポートが示したのは、攻撃者のAI利用が「文面やコードを作らせる補助」から「エージェントに攻撃工程を任せるワークフロー」へ移ったという事実です。象徴的なのが、クラウド侵害からエージェント基盤の構築、数千件の認証情報収集までを6時間未満で終えたインシデントで、使われたのは市販のAIコーディングチャットボットとMarkdownの指示ファイルでした。

同時に、冷静に線を引くべき点もあります。「全ての攻撃者がAIを使用」はレポートの結論ではなくチーフアナリストの判断であり、完全自律の攻撃パイプラインは実環境でまだ観測されていません。 使われたツールの製品名も公表されていません。

それでも、防御側がやることは明確です。クラウド請求とクォータ増申請の異常監視、allUsers 公開リソースとサービスアカウント鍵の棚卸し、AIツール設定ファイルの平文APIキー排除、.claude/ .cursor/ 配下と自動実行設定の確認、MCPサーバの出所確認、CI/CDのOIDC権限最小化、そして「数日」を前提にしたインシデント対応計画の見直し——どれも今週から着手できて、効果が具体的です。

まずは、自社のクラウド請求アラートが設定されているか、そしてAI開発ツールの設定ファイルにAPIキーが平文で残っていないか、この2つを今日確認してください。防御用AIプロダクトの検討は、その後の話です。