Agent Data Injection：AIエージェントの防御を回避する新しい攻撃クラス
ソウル国立大学とインディアナ大学、ウィスコンシン大学の研究者らがAgent Data Injection（ADI）を提案した。エージェントの信頼できるデータ構造に悪意のあるデータを注入し、Claude Code、Codex、Gemini CLIで任意クリック攻撃とリモートコード実行を達成し、既存の防御を回避する新しいタイプの攻撃だ。
この記事はAIにより一次情報源から生成されました。
AIエージェントのセキュリティ研究はこれまで主に一種類の攻撃に焦点を当ててきた。インストラクションインジェクション、つまり攻撃者がエージェントが処理する信頼できないデータに偽の指示を注入し、それを正規のユーザー命令として扱わせようとするものだ。コミュニティはそのような試みを検出・ブロックするための一連の防御を開発してきた。しかしソウル国立大学とインディアナ大学、ウィスコンシン大学の研究者らは2026年7月6日に公開した論文で、それらの防御を文字通り回避する攻撃クラスを記録している――まったく異なる原理で動作するものだ。
Agent Data Injectionとは何か、なぜこれまで見えなかったのか？
Agent Data Injection（ADI）はプロンプトを標的にしない。代わりに、悪意のあるコンテンツはエージェントが信頼できるデータとして扱う構造――リソース識別子やデータソースのようなメタデータ、またはツール応答やツールコール構造のために使用されるフォーマット――に注入される。エージェントはこれらの構造を、信頼できないテキストにアクセスすべき懐疑心と同じ度合いでは検証しない。
違いは根本的だ。インストラクションインジェクションは自然言語で攻撃を偽装しようとする――攻撃者は正当な指示のように見えるテキストを書く。ADIはそれをしない。攻撃はエージェントが正常な操作プロトコルの一部だと仮定する構造化データにコード化されている。既存の防御は指示的なコンテンツが存在すべきでない場所を探していた。ADIはその形と場所を変える。
3つの攻撃クラス：任意クリックからサプライチェーン侵害まで
研究者らは、それぞれ異なる目的とメカニズムを持つ3つの別個のADI攻撃クラスを特定している。
任意クリック攻撃はユーザーインターフェースを自律的にナビゲートしてユーザーの代わりにアクションを実行するウェブエージェントを標的にする。ウェブコンテンツに埋め込まれた悪意のあるメタデータ――偽の要素識別子やブラウザAPIの操作されたレスポンスなど――はエージェントが不正な要素をクリックするよう誘導し、潜在的に購入を有効化したり取引を確認したり機密データを開示したりする。
リモートコード実行（RCE）攻撃はコードを書き、分析し、実行するコーディングエージェントを標的にする。ADIはファイルシステムやデバッガーなどのツールからエージェントが受け取る情報であるツールコールレスポンスのフォーマットを操作し、エージェントがユーザーの環境で攻撃者のコードを実行するよう誘導する。
サプライチェーン攻撃は同じメカニズムを使用して開発プロセスを侵害する。攻撃者はコーディングエージェントがダウンロードして統合するパッケージ、ライブラリ、開発依存関係に関する正当なデータに見せかけた悪意のあるコードを注入する。
脆弱な商業エージェント：Claude Code、Codex、Gemini CLI
研究者らは実験的なシステムだけでなく、ユーザーが利用可能な実際の商業製品をテストした。
任意クリック攻撃には：Claude in Chrome、Antigravity、Nanobrowserがエージェントの処理するウェブコンテンツに埋め込まれた悪意のあるメタデータへの脆弱性を示した。
RCEとサプライチェーン攻撃には：市場をリードする3つのコーディングエージェントであるClaude Code、Codex、Gemini CLIがツール応答フォーマットの操作への脆弱性を示した。
影響を受けるシステムの広さは偶然ではない。著者らが指摘する通り、ADIはこれらのエージェントすべてに共通する根本的な設計上の欠陥を標的にしており、その中の一つの実装固有のバグではない。
エージェント設計における根本的なセキュリティの欠陥
著者らが特定する根本原因は明確だ。現在のエージェントは信頼できるデータと信頼できないデータを分離していない。これは実装の端っこのケースではない――それは現代のエージェントシステムの設計において一貫して見過ごされている根本的なセキュリティ原則だ。
ソフトウェアエンジニアリングとの比較は有用だ。SQLインジェクション攻撃は数十年間にわたり、アプリケーションがSQLコードをユーザーデータから分離していないという事実を悪用してきた。解決策（パラメータ化クエリ、プリペアドステートメント）はアーキテクチャの変更を必要とし、フィルタリングの変更だけではなかった。著者らはADIについて類似の考え方を示唆している。データ内の指示的なコンテンツを探すフィルターを追加するだけでは十分ではない。エージェントランタイムのレベルでアーキテクチャ的な分離が必要だ。
ADIは既存のIPIの防御を回避する。それらの防御は攻撃が指示の形で来ることを前提としているからだ――正当に見える構造化データの形ではなく。エージェントがソースと整合性の検証なしにすべての構造化データを信頼する限り、そのギャップは開いたままだ。
論文は19ページ、19図、7表を含み、arXiv（2607.05120）で利用可能だ。著者はWoohyuk Choi、Juhee Kim、Taehyun Kang、Jihyeon Jeong、Luyi Xing、Byoungyoung Leeだ。
よくある質問
- ADIはよく知られたインストラクションインジェクション攻撃とどう違いますか？
- インストラクションインジェクションはエージェントが不正な指示を受け取るよう自然言語プロンプトを操作する。ADIはメタデータ、リソース識別子、ツール応答フォーマットなど、信頼できるデータ構造を装った悪意のあるデータを注入し、プロンプト自体ではなく構造化データへのエージェントの信頼メカニズムを利用する。
- どの実際の商業エージェントがADI攻撃に対して脆弱でしたか？
- 研究者らはClaude in Chrome、Antigravity、Nanobrowserへの任意クリック攻撃と、Claude Code、Codex、Gemini CLIへのリモートコード実行およびサプライチェーン攻撃を実証した。これらはすべて研究時点でユーザーが利用可能な実際の商業製品だ。
- ADI脆弱性の根本原因は何で、どのように解決しますか？
- 根本原因はエージェントのアーキテクチャにおける信頼できるデータと信頼できないデータの分離の欠如だ。著者らはこれが現在のエージェントが適用していない根本的なセキュリティ原則であり、その解決には新しいフィルターを追加するだけでなく、アーキテクチャレベルの変更が必要だと強調している。