Google AI脅威防御、マシンスピードで動く攻撃者に対峙
Googleは、偵察、コーディング、認証情報の窃取に数時間を要していた作業を、一つの自動化ワークフローへ圧縮する、運用段階のAI攻撃の第一波を記録した。9月16日のセキュリティ更新で同社は、複数の攻撃段階でエージェントを利用する敵対者に対し、Google AI threat defenseを提示している。
中心的な対立は、もはや人間のアナリストと高速化したフィッシング文面作成者との競争ではない。Googleによれば、攻撃者はモデル、クラウドインフラ、盗まれたアカウント、従来型のハッキングツールを結び付け、計画と調整を行えるシステムに組み込んでいる。Mandiantによるある調査では、エージェント対応の認証情報窃取キャンペーンが6時間未満で完了した。
Googleの回答は、複数のモデルを内部テレメトリー、クラウドコンテキスト、自動調査、ソフトウェア修復と組み合わせるものだ。同社は、防御側が自らのコード、アイデンティティ、構成、実行時システムを理解しているため優位性を保てると主張する。ただし、その優位性が成立するのは、組織がこれらのデータソースを接続でき、自動化された防御措置を信頼できる場合に限られる。
この留保は重要だ。Googleは、脅威診断と提案する解決策の双方を支える証拠の多くを提供している。NISTとMITREの独立したフレームワークは、より広いリスクモデルを裏付けるものの、個々の製品に関する主張をすべて検証するものではない。
その結果、企業セキュリティにとって重大な試練が生じている。攻撃者は意図から実行までの遅延を縮めている。防御側は、接続されたAIシステムが、ネットワーク内に不透明で特権的な層をさらに作り出すことなく、自らの遅延を短縮できるかを判断しなければならない。
Google AI脅威防御は、脅威モデルにおける3つの変化から始まる
Googleの更新は、AIをソフトウェアサプライチェーンのリスク、新たな攻撃対象領域、そして攻撃者の運用を加速する要素として捉えている。
Google Threat IntelligenceのバイスプレジデントであるSandra Joyceは、これら3つの構造的変化を軸に同社の評価を整理した。この主張は、Google Cloudが9月に公開したCloud CISO Perspectivesで示されている。
最初の変化はソフトウェア開発の段階から始まる。AIコーディングアシスタントは、パッケージの推奨、構成ファイルの生成、リポジトリの編集、ツールの起動を行える。こうした能力は、汚染された依存関係や悪意ある指示が信頼されたワークフローに入り込む機会を増やす。
Google Threat Intelligence Group、すなわちGTIGは、AI支援コーディングの慣行を、2025年から2026年初頭にかけて観測された大規模なソフトウェアサプライチェーン侵害と結び付けている。同組織は、攻撃者が開発者、パッケージレジストリ、AIアシスタント、自動スキャナーを一体として狙っていると説明する。
TeamPCPとも呼ばれるUNC6780は、そのパターンを示す例だ。Googleによれば、この金銭目的のグループは、AIツールとオープンソース開発の手法に関わる6種類以上の技術を用いた。
報告された手法には、乗っ取られたAIツールキット、汚染されたパッケージ、プロンプトインジェクション、AIスキャナーへの干渉を意図した指示が含まれる。一部の悪性ファイルは、コーディングアシスタントや開発環境で使われるプロジェクトディレクトリ内に隠されていた。
この配置は重要である。AIアシスタントはリポジトリ内の指示を正当なプロジェクトコンテキストとして解釈する可能性がある。そのため開発者は、未知のバイナリを意図的に実行しなくても、悪意ある挙動を引き継ぐおそれがある。
Googleによれば、UNC6780は開発者アカウントも侵害し、Model Context Protocolリソースのトロイの木馬化されたバージョンを公開した。Model Context Protocol、すなわちMCPは、AIアプリケーションをツールや外部データへ接続できるようにする。
別の手法では、悪性コードが継続的インテグレーションシステムからトークンを取得しようとした。有効なトークンがあれば、侵害されたパッケージを自動チェックに対して信頼できるものに見せかけられる可能性がある。
2つ目の構造的変化は、AIシステムそのものに関わる。モデル、プロンプト、エージェントへの指示、ソースコード、認証情報、コンピューティングクォータは、価値の高い標的となった。
Googleによると、Mandiantは2026年第2四半期に複数のデータ窃取型恐喝作戦を調査した。攻撃者は、独自モデル、プロンプト、スキル、ソースコード、関連研究を盗み出した。
これらの事案は、最先端AI研究所にとどまらない組織に影響を及ぼした。Googleは北米と欧州のテクノロジー、医療、メディア、エンターテインメント分野で被害者を特定している。
同社はまた、盗まれたAIアカウントへの継続的な需要も報告している。地下市場の販売者は、一部の消費者向けアカウントを定価より最大99％低い価格で宣伝していた。
こうした認証情報には複数の用途がある。攻撃者は本人確認を回避し、帰属を曖昧にし、制限された機能にアクセスし、あるいは推論コストを被害者に転嫁できる。
Googleは、この悪用の一形態をLLMJackingと呼ぶ。攻撃者がクラウドアクセスを盗み、無許可のAIワークロードを展開することで、被害者がインフラ消費の責任を負うことになる。
3つ目の変化は、運用テンポに関するものだ。最新のAI threat trackerでは、敵対者が単発のプロンプトからエージェント型ワークフローへ移行していると説明されている。
エージェント型AIとは、行動を選択し、ツールを使い、結果を評価し、人間による監督を抑えながら目標に向けて継続できるソフトウェアを指す。この自律性は、従来の攻撃段階の間にあった停止時間を取り除く可能性がある。
これらの分類はいずれも、完全に新しいものではない。パッケージ汚染、認証情報窃取、クラウド悪用、自動スキャンは、生成AI以前から存在していた。
変化したのは、それらの統合だ。モデルは自然言語の目標をスクリプトに変換し、失敗した手順のトラブルシューティングを行い、ツールを選択し、再利用可能なファイルに運用指示を保存できる。
この統合が、記事の中心的な緊張を生み出している。Googleは、既知の手法からマシンスピードの攻撃が生まれていると見ている一方、多くのセキュリティチームは依然として、分断されたキューを通じてそれらの手法を調査している。
6時間の認証情報窃取キャンペーンが示す、セキュリティチームへの圧力
最も重要な進展は新たなハッキング手法そのものではなく、計画、実行、規模拡大の間にあった時間が失われつつあることだ。
2026年第2四半期、Mandiantは、侵害されたクラウドインフラ内で稼働していた自律型マルチエージェントフレームワークに関わる侵入を調査した。Googleはこの活動を、金銭目的とみられる攻撃者に帰属させている。
攻撃者はAIコーディングチャットボット、プロンプト、準備済みのエージェント指示を利用した。これらの要素が連携し、6時間未満で大規模な認証情報収集を計画、構築、実行した。
Googleによると、このフレームワークは脆弱性スキャン、運用エラーの解消、IPローテーションを、限られた人間の介入で管理した。最終的には数千件の第三者認証情報を侵害した。
被害者のクラウド環境から実行することには、別の利点もあった。攻撃トラフィックは明らかに敵対的なサーバーではなく、正規のインフラから発信された。
6時間という数値は慎重に解釈すべきだ。これは調査された1件のキャンペーンに基づくものであり、業界全体の中央値ではない。Googleは、普遍的な加速率を確立できるほどの比較可能な事例を公表していない。
それでも、この事例は既存のセキュリティ運用が圧力を受ける理由を示している。人間のアナリストは、アイデンティティ、エンドポイント、コード、クラウドのイベントを各ツールが個別に検知した後、静的なアラートを処理することが多い。
自律型の攻撃フレームワークは、こうした組織上の境界を尊重しない。認証情報を試し、公開されたサービスを発見し、スクリプトを修正し、別々のチケットを起票せずに処理を継続できる。
Googleはまた、自動化された偵察に関連する、公開状態のコマンド・アンド・コントロール環境も特定した。そのダッシュボードは、収集された2万3,800件超のシークレットを整理・検証するために設計されていた。
このシステムには、エージェント構成ファイルと再利用可能なナレッジ文書が含まれていたとされる。その構造は、攻撃者が指示と蓄積されたコンテキストを運用インフラとして扱っていることを示唆する。
別のスパイ活動の例も、このパターンを補強する。Googleは、中国と関連するグループが、複数のAIモデルへタスクを振り分けるツールであるCC Switchを試験していることを確認した。
この攻撃者は、Claude、Codex、Geminiを切り替えていたと報告されている。エクスプロイト用スクリプト、誘導文面の作成、エラー修正にそれぞれ異なるモデルを選んだ。
これは、1人の犯罪者が1つのチャットボットを使うというイメージからの顕著な転換だ。新たに現れつつあるモデルは、複数の専門コンポーネントを持つ協調的なソフトウェアパイプラインに近い。
そのため防御側は、二方向から圧力を受けている。自らのAI資産を守ると同時に、従来型の攻撃を連携させるためにAIを使う敵対者へ対応しなければならない。
開発者は、アシスタントが現在ではリポジトリ、エディタ、ターミナル、ビルドシステム内で動作するため、最初にその圧力を感じる。悪意ある依存関係は、独立したセキュリティレビューが始まる前に本番環境へ到達し得る。
セキュリティ運用チームは次の遅延に直面する。不審な挙動が現れた後、アイデンティティ、クラウドリソース、ソフトウェアアーティファクト、モデル、データの関係を再構築しなければならない。
企業の購入担当者も、ガバナンスの問題に直面する。エージェントは複数のシステムに正当なアクセス権を持ち得るため、有害な行動を認可済みの自動化と見分けにくくなる。
これが、Googleが開発者向けガードレールをスペルチェッカーになぞらえる理由だ。同社は、疑わしいパッケージや指示を即座に警告できるよう、チェック機能をエディタとエージェントのワークフロー内で動作させたいとしている。
この比喩は有用だが、不完全でもある。スペル修正がコードを実行したり、アクセス権を変更したり、本番インフラに影響を及ぼしたりすることはほとんどない。
また、セキュリティ上の検出結果は、エディタが持たないコンテキストにも依存する。あるコードパターンは単独では安全でも、公開されたワークロードや特権アイデンティティと接続されると危険になり得る。
したがって求められる対応は、単にスキャナーを追加することより広範だ。組織には、開発活動と稼働中のインフラを結ぶ関係性に加え、エージェントがアクセス・実行できる範囲を管理するポリシーが必要になる。
この要件は、Googleの戦略の背後にある競争上の問いを提起する。接続された防御システムは、自らの自動化に過度な信頼を集中させずに、十分な速さで対応できるのだろうか。
対決の構図は、攻撃者の自動化と防御側のコンテキスト
Googleの主張の中心は、攻撃者にはスピードがある一方、防御側はスピードと優れた内部コンテキストを組み合わせることで勝てる、というものだ。
攻撃者は多くの場合、標的環境の外部から活動を始める。公開サービスを探索し、盗まれた認証情報を試し、アーキテクチャを推測し、有用な侵入経路を探す。
防御側はすでに、はるかに多くの情報を把握している。どのアイデンティティが特権を持つか、どのサービスがインターネットに公開されているか、どのデータストアが機密情報を含むかを確認できる。
また、どのコードがワークロードを生成し、どの構成がそれを管理しているかも把握している。理論上、こうした関係性により、防御モデルは実際の事業リスクを生む攻撃経路を優先できる。
Googleの戦略は、この理論を接続されたセキュリティグラフへ変換することに依存している。セキュリティグラフは、コード、クラウドリソース、データ、モデル、脆弱性、アイデンティティ間の関係をマッピングする。
Wizの買収後、GoogleはWiz Security Graphを、より広範なAI Threat Defenseアーキテクチャにおけるコンテキスト層として位置付けている。このフレームワークには、Gemini、Mandiantのインテリジェンス、CodeMender、Google Security Operationsも組み込まれている。
Googleは、このアーキテクチャによって有害な攻撃経路を特定し、リスクに優先順位を付け、活動を調査し、修復を支援できるとしている。これは独立して確立された成果というより、意欲的な製品統合に関する主張である。
このアーキテクチャは、より広い業界の変化も反映している。セキュリティプラットフォームは、単に生成するアラートの数ではなく、シグナルをどれほど効果的に結び付けられるかで競争を強めている。
脆弱なパッケージは、隔離されたテストプロジェクトに存在する場合とでは意味合いが異なる。同じパッケージでも、本番シークレットにアクセスできるインターネット公開サービス内にあれば、緊急性を帯びる。
アイデンティティはさらに別の層を加える。低深刻度の設定問題であっても、エージェントが広範な権限を持ち、外部ツールを呼び出せる場合には重大な問題になり得る。
データリネージも重要だ。情報がどこで生まれ、システムがそれをどのように変換し、どのモデルやアプリケーションが利用したかを記録する。
Googleは、こうした関係性が防御のあらゆる段階に反映されるべきだと主張する。コード分析は実行時の露出を考慮すべきであり、クラウド監視は弱点を発生源まで追跡すべきである。
このアプローチは、孤立したセキュリティ制御を販売するベンダーに圧力をかける。単体のスキャナーは欠陥を検出できても、実際の影響を順位付けするために必要な文脈を欠く可能性がある。
また、所有権が断片化された企業にも圧力をかける。開発、クラウド、アイデンティティ、セキュリティ運用、AIガバナンスの各チームは、しばしば別々のインベントリを維持している。
それらのインベントリが不完全であれば、統合プラットフォームも信頼できる関係性を推論できない。したがって、Google AI threat defenseの品質は、顧客自身が完了しなければならない作業にも一部依存する。
組織には、正確な所有権情報、アイデンティティ境界、ソフトウェアインベントリ、データ分類が必要である。そうでなければ、グラフは膨大なテレメトリーを接続できても、その背後にあるビジネス上の意味を捉えられない。
この依存関係により、社内知識はセキュリティ資産となる。エンジニアリングチームには、エージェントが特定の権限を持つ理由、どのリポジトリが本番環境に供給されるか、各ワークフローの所有者は誰かを説明する、アクセスしやすい記録が必要となる。
検索可能なナレッジベースは、その文書化レイヤーを支援できる。ただし、セキュリティテレメトリー、アクセス制御、インシデント対応を置き換えるものではない。
したがって決定的な競争は、Googleと特定の競合企業との対決ではない。攻撃者の自動化と、防御側の文脈理解との競争である。
Googleの主張が成功するのは、企業の文脈情報が完全で、最新であり、防御システムで利用可能なときだ。組織データが断片化したまま、あるいは権限が運用上の必要性を超える場合には、その主張は弱まる。
GoogleがAIサイバーセキュリティに複数モデルを用いる理由
Googleは、単一の最先端モデルがあらゆる脆弱性、悪意ある指示、ロジック上の欠陥を確実に検出できるという考えを退けている。
同社は、意図的なマルチモデル型セキュリティアプローチを説明している。Geminiを商用モデルおよびオープンソースモデルと併用し、その検出結果を比較する。
Googleによれば、このプロセスは誤検知を減らし、複雑な欠陥を発見し、単一のモデルが見逃す修復策を生成できる。これは単一モデル型セキュリティの現実的な弱点に対処する主張だ。
すべてのモデルには固有の盲点がある。学習データ、ポリシーフィルター、コンテキストの制限、システム指示、ツールへのアクセスが、検出できるものを形作る。
攻撃者はこうした境界を探ることができる。Googleは、LLMベースのスキャナーに安全上の拒否反応を起こさせようとしたとみられる、極端な文言を含む悪意あるJavaScriptコメントを観測した。
悪意あるペイロードは、そうした指示の下に置かれていた。スキャナーが分析全体を拒否すれば、攻撃者はモデルの安全性に関する挙動を防御回避の手法として利用できる。
Googleは、Geminiの安全対策がその内容に反応したと報告している。また、得られたインテリジェンスが分類器の強化と、関連アカウントおよびインフラの妨害に役立ったとしている。
マルチモデル設計は、単一の拒否ポリシーへの依存を低減できる。一つのモデルがタスクを拒否したりパターンを見落としたりしても、別のモデルが疑わしい挙動を識別できる可能性がある。
クロスバリデーションは、真の弱点と、もっともらしいが誤った検出結果を区別する助けにもなる。モデルは依然として、実行可能なコードと一致しない自信に満ちた説明を生成しがちである。
しかし、モデルを追加しても、信頼できる合意が自動的に生まれるわけではない。複数のモデルが学習ソース、共通アーキテクチャ、あるいは類似の評価失敗を共有する可能性がある。
オーケストレーション自体も攻撃対象領域をもたらす。システムは、どのモデルにデータを渡すか、各モデルがどのツールを呼び出せるか、結果の衝突が本番アクションにどう影響するかを決めなければならない。
コストとレイテンシも重要である。複数モデルによる繰り返し分析はより多くの計算資源を消費し、時間に敏感な意思決定を遅らせる可能性がある。
Googleが提案する答えは、文脈に基づく優先順位付けだ。高コストな分析は、公開済みまたは特権を持つシステムに接続されたコードや資産に集中させられる。
これにより二部構成の仕組みが生まれる。複数モデルが検出範囲を広げ、セキュリティグラフが実際の運用上の影響を持つ検出結果へ注意を絞り込む。
CodeMenderは修復側を担う。Googleはこれを、ソフトウェア脆弱性を見つけて修正するAIエージェントと説明しており、防御作業の一部を検出からソースコード変更へ移すものだ。
自動パッチ適用は、特に繰り返し発生する脆弱性パターンについて、露出時間を短縮できる可能性がある。ただし、コード変更には厳格なテスト、レビュー、ロールバック制御が必要だ。
一つの弱点を取り除くパッチが、アプリケーションの挙動を変えたり、別の障害を生んだりする可能性がある。そのため、高い権限を持つ修復エージェントには、その技術的能力から想定される範囲より狭い権限が必要となる。
ここで独立したガイダンスが有用になる。NISTが策定中のCyber AI Profileは、この分野をAIシステムの保護、AIを活用した防御の実施、AIを活用した攻撃の阻止に分けている。
これらのカテゴリーはGoogleの脅威モデルと密接に一致する。また、AIセキュリティ製品を完全なガバナンスプログラムとして扱うことを組織が避ける助けにもなる。
MITREは、AI向けの敵対的脅威フレームワークであるATLASを、エージェント型システムと大規模言語モデルを対象に拡張している。2026年のATLAS拡張は、ベンダー横断で共有可能な手法と緩和策の必要性を反映している。
共有フレームワークが重要なのは、顧客が防御上の主張を検証するための移植可能な方法を必要としているためだ。プロバイダーの内部ベンチマークでは、別の組織の権限やワークフローのもとでシステムがどう機能するかを明らかにできない。
したがって、マルチモデル型セキュリティは優位性の証明ではなく、仕組みである。その価値は、多様な失敗特性、制御されたツールアクセス、測定可能な成果、安全な修復に依存する。
Google AI threat defenseは、この仕組みのためのもっともらしいアーキテクチャを示している。それでも顧客には、本番環境の条件下でどれほど一貫して機能するかを示す証拠が必要だ。
証拠が裏付けるのは緊急性であり、自律型サイバー戦争ではない
Googleのテレメトリーは意味のある自動化を示しているが、攻撃者が大規模に完全自律型のエンドツーエンド侵入を実行していることは示していない。
この区別こそが、この記事における本質的な懐疑的視点である。機械速度の攻撃に関する見出しは、自律システムがすでに熟練したオペレーターに取って代わったかのような印象を与えかねない。
Googleの詳細な報告は、より慎重なものだ。GTIGによれば、敵対者はAIを偵察、エクスプロイト開発、ソーシャルエンジニアリング、トラブルシューティング、認証情報の収集に組み込んでいる。
同グループはまた、野外の標的に対してゼロデイ悪用を実施する完全自律型パイプラインを、まだ観測していないとしている。
むしろ証拠は、段階的な運用成熟を示している。攻撃者は、特に脆弱性が公開された後、既存の商用モデルやオープンウェイトモデルを使って、よく知られた作業を加速している。
ある事例では、パッチ適用済みのFirefox脆弱性を標的とするAI生成アーティファクトが確認された。Googleは、診断用プローブから、より完全な実行チェーンへ進展するスクリプトを発見した。
これらのアーティファクトは、ベンダーがパッチを発行してから約1か月後に現れた。この例が示唆するのは、既知の脆弱性に対する反復の高速化であり、未知の欠陥の自律的発見が確認されたわけではない。
別の事例では、自動化されたペネトレーションテストフレームワークの試みがあった。GTIGによれば、当該アクターは探索と実行が可能なエージェントの構築を目指していた。
Googleは関連資産を無効化しており、報告書はこの活動を試みとして記述している。成功した自律型侵害として提示すべきではない。
6時間に及ぶ認証情報キャンペーンは、Mandiantが運用上の利用を観測したため、より強い証拠となる。それでも、攻撃者はプロンプト、チャットボット、指示、侵害済みインフラを提供していた。
このシステムは人間の関与を減らしたが、公開された証拠は完全な独立性を立証していない。したがって、「機械速度」のような表現は、無制限の自律性ではなくワークフロー圧縮を指すべきである。
Googleの可視性にも境界がある。同社の報告は、Mandiantの調査、Geminiの不正利用シグナル、脅威アクター追跡、Googleプラットフォームの防御に基づいている。
これは重要なデータセットだが、すべてのモデルプロバイダー、プライベートデプロイメント、クラウド、被害環境を網羅しているわけではない。
侵害されたハードウェア上で動作するオープンウェイトモデルは、商用APIの監視を回避できる。Googleは、その理由から被害者のインフラ内部にローカルモデルを展開した中国関連アクターを挙げている。
妨害に関する主張を評価する際、カバレッジの隙間は重要になる。Googleアカウントを無効化すれば一つの活動を中断できるかもしれないが、別の活動をローカルツールや競合サービスへ移行させる可能性もある。
防御の自動化にも並行する不確実性がある。Googleは、豊富な内部文脈により、防御側は攻撃者より迅速かつ正確になるとしている。
その方向性は妥当だが、正確性は誤検知、見逃し、調査時間、安全でない修復と照らして測定されなければならない。同社はこの発表で、比較可能な本番指標を公開していない。
NISTの研究は、さらに別の注意を促す。2026年6月の継続的監視に関する研究は、固定的なガードレールが、適応する敵対的プロンプトに対して普遍的に信頼でき続けることはできないと論じている。
この知見はGoogleの継続的フィードバックアプローチを支持する。同時に、どの分類器、モデルアンサンブル、ポリシーレイヤーも恒久的に安全なものとして扱うべきではないことを意味する。
防御エージェントが広範な権限を受け取る場合、そのリスクは特に高い。観測ツールの誤った結論はノイズを生む。修復エージェントによる同じ誤りは、本番システムを変更し得る。
組織は段階的な自律性を求めるべきだ。低リスクのアクションは自動実行できる一方、破壊的なアクションやアイデンティティを変更するアクションにはレビューが必要である。
また、エージェントの認証情報を分離し、ツール呼び出しを記録し、ロールバック手順をテストし、人間による調査のための証拠を保存すべきだ。監査可能性を伴わない自動化は、不確実性を速く移動させるだけである。
Googleの更新は、緊急の準備を裏付けている。自律型サイバー戦争が到来した、あるいは一つの統合プラットフォームが問題を解決したという主張を正当化するものではない。
GoogleのAI Threat Defenseの主張を検証する三つのシグナル
次の試金石は、Googleが印象的なインシデント報告を、独立して測定可能な防御成果へ転換できるかどうかである。
第一のシグナルは、AI Threat Defenseの導入に関する運用上の証拠だ。顧客は、調査時間、誤検知、露出期間、再発インシデントが文書化された形で減少しているかを確認すべきである。
アーキテクチャ図だけでは、これらの問いには答えられない。ケーススタディには、明確な開始条件、評価期間、どのアクションが人間の管理下に残ったかの説明が必要だ。
異なる環境にまたがる証拠は、Googleの主張をより強固にする。十分に計測された単一のクラウド環境での結果は、断片化されたマルチクラウド組織については、ほとんど明らかにしない。
弱い、あるいは選択的な指標では、統合されたコンテキストが非対称的な優位性を生むという主張は揺らぐ。購入者は、所有権情報の欠落やテレメトリーの不完全さをプラットフォームがどう扱うかも確認すべきだ。
2つ目のシグナルは、攻撃者による自律型マルチエージェント・パイプラインの利用がさらに進むかどうかだ。Googleの次回の脅威レポートでは、実験、支援された作戦、成功したエンドツーエンドのキャンペーンを区別すべきである。
再現可能な6時間のキャンペーンが増加すれば、マシン速度で進行するという診断はより強固になる。これまで未知だった脆弱性の自律的な悪用が確認されれば、事態の重大性ははるかに増す。
対照的に、既知の脆弱性、人間が提供するプレイブック、盗まれたインフラへの依存が続くなら、より限定的な結論を支持することになる。AIは依然として重要だが、主として既存の攻撃手法を加速させる役割にとどまる。
アナリストは、攻撃者がモデル間で作業をどのように分担しているかを追跡すべきだ。CC Switchの事例は、敵対者が単一のプロバイダーに固執するのではなく、タスクごとにツールを選ぶことを示唆している。
このようなモデルの多様性は、プロバイダー単位での妨害を複雑にする。また、複数のモデルファミリーと拒否応答の挙動にまたがる防御テストの必要性も裏付ける。
3つ目のシグナルは、共有標準がエージェント型セキュリティ向けの検証可能な統制を生み出すかどうかである。NISTのCyber AI ProfileとMITRE ATLASは、この問題についてベンダー中立の共通言語を組織に提供する。
有意義な進展には、ツール権限、モデルのインベントリ、プロンプトインジェクション、データリネージ、インシデントログ、自律的な修復に関する具体的な統制が含まれる。これらの統制は、観測可能な証拠に対応付けられるべきだ。
その採用が進めば、AI防御には接続された継続的な運用が必要だというGoogleのより広範な主張が強化される。また、成功の定義をGoogle独自の製品カテゴリーだけに委ねることも防げる。
業界のガイダンスが抽象的なまま、エージェントが本番環境の権限を得ていくなら、この論旨は弱まる。企業はその場合、一貫したテストや監査の手法なしに、より高速な自動化に直面することになる。
セキュリティリーダーは、完璧な標準を待つべきではない。AI資産を棚卸しし、エージェントの権限を絞り、コードをランタイムの露出情報と結び付け、今すぐインシデント対応ワークフローをテストできる。
開発者は、リポジトリの指示やAI設定ファイルを、実行可能なリスクとして扱うべきだ。セキュリティチームは、未承認のモデルワークロードや異常な認証情報の利用について、クラウドリソースを監視すべきである。
経営層は、率直な問いを投げかけるべきだ。組織は、自動化された防御者が安全に行動できるだけの信頼できるコンテキストを十分に持っているだろうか。
Google AI threat defenseは、モデル、脅威インテリジェンス、コード修復、セキュリティ運用、クラウドグラフを結び付けることで、一つの答えを提示している。同社の9月のレポートは、異例なほど具体的なインシデントを通じてその主張を示している。
証拠が示すのは、AI支援型の攻撃がより組織化され、より高速化していることだ。自律性が人間の攻撃者を不要にすることや、自律的な防御を保証することまでは示していない。
今後3カ月で、より多くのキャンペーンが6時間というパターンを繰り返すか、顧客が測定可能な成果を公表するか、標準が特権を持つエージェントに追い付くかが明らかになるはずだ。
それまでは、組織はGoogleのレポートを警告であると同時に設計上の課題として扱うべきだ。防御側がすでに保有するコンテキストを接続し、エージェントに可能な行為を制限し、主張されるあらゆる速度上の優位性を測定することが重要である。
