7月1日、Jeff Burtが「Mozilla Shows the Danger of Indirect Prompt Injections in AI Coding Agents」と題した記事を公開した。この記事では、MozillaのセキュリティチームがAIコーディングエージェントを標的とした間接プロンプトインジェクション攻撃のPoC（概念実証）を公開し、開発者のシステムが完全に乗っ取られうる危険性を示したことについて詳しく紹介されている。
「見た目は無害なリポジトリ」が攻撃の起点になる
Mozillaのセキュリティリサーチチーム「0DIN」の研究者Andre HallとMiller Engelbrechtは、悪意あるコードを一切含まないGitHubリポジトリを使って、AnthropicのAIコーディングエージェント「Claude Code」を操作し、開発者のマシンを掌握できることをPoCで実証した。
ポイントは攻撃ペイロードがリポジトリに存在しないことだ。ペイロードはDNS TXTレコードから実行時に取得される。コードスキャナーも、人間のコードレビューも、エージェント自身も、実行前にそれを「見る」機会がない。
「どんなスキャナーも検知できず、人間のレビュアーも見つけられず、エージェント自身も実行前に確認する機会がない」——Hall & Engelbrecht
これが間接プロンプトインジェクション（Indirect Prompt Injection）の本質だ。ユーザーの入力から直接悪意ある命令を注入するのではなく、エージェントが処理する外部コンテンツ（リポジトリのREADME、エラーメッセージ、ドキュメントなど）に命令を埋め込む手法である。直接のプロンプトインジェクションと異なり、ユーザーや開発者が命令の存在に気づきにくい点が特徴だ。
3ステップで完全侵害が成立する仕組み
研究者が示したPoCは3段階で構成されており、「それぞれ単体では無害に見える」点が巧妙だ。
- セットアップ手順の提示：一見通常のリポジトリが、普通のセットアップ指示を提示する。
- 初期化コマンドの実行誘導：初回起動で意図的に失敗するPythonパッケージが、開発者に初期化コマンドの実行を促す。「よくあるパターン」に見せることで疑念を持たせない。
- シェルスクリプトの呼び出し：初期化コマンドがシェルスクリプトを呼び出す。スクリプトは「クラウドプラットフォームの定型的なブートストラップ処理」に見えるが、実際には攻撃者が制御している。設定値はDNS TXTレコードから取得され、その内容が直接
bashにパイプされる。
Claude Codeの視点では「エラーを修正した」だけだ。しかし結果としてリバースシェル（攻撃者がネットワーク越しにリモートからシェルを操作できる状態。攻撃者側からの接続確立のため、ファイアウォールをすり抜けやすい）が確立される。
「Claude Codeがシェルを開こうと決めたわけではない。エラーを修正しようとしただけだ。リバースシェルは、Claude Codeが実際に評価したものから3段階の間接参照の先にある」——Hall & Engelbrecht
奪われるものの範囲
リバースシェルが確立された攻撃者は、開発者ユーザーの権限でシステムを自由に操作できる。具体的に研究者が示した取得可能な情報は以下のとおりだ。
- 環境変数に格納された認証情報
- Anthropic APIキー
- AWSキー
- GitHubトークン
さらに、シェルが閉じる前にSSHキーの設置やバックドアのインストールによってPersistence（永続的な侵害）も確立される。Persistenceとは、攻撃者がセッション終了後もシステムへの侵害状態を維持し続けることを指す。SSHキーの埋め込みやスタートアップスクリプトへの仕込みが代表的な手法だ。
また研究者は、攻撃の波及範囲についても言及している。「求人票、チュートリアル、Slackのメッセージにリポジトリのリンクが1つ貼られるだけで、Claude Codeでそれを開いたすべての開発者が被害を受ける」。
AIコーディングエージェントが本質的に抱えるリスク
この問題の根本はアーキテクチャにある。元記事によれば、LLMアーキテクチャの根本的な弱点は、命令とデータの境界を強制できないことにあると指摘されている。ローカルで動作するAIもクラウドAIも、この脆弱性に対しては同等のリスクを抱える。
Claude Codeのようなエージェントは、プライベートデータ（環境変数、認証情報、APIキー、ローカル設定ファイル）へのアクセス権を持ちつつ、リポジトリやエラーメッセージといった信頼できないコンテンツを日常的に処理する。この組み合わせが、間接プロンプトインジェクションを特に危険な攻撃ベクターにしている。
開発者・組織が取れる対策
研究者は開発者向けの対策として以下を挙げている。
- 見慣れないリポジトリのセットアップ手順やスクリプトは、エージェントの推奨に関わらず、信頼できないコードとして扱う。
- エージェントはセットアップコマンドが「実際に何を実行するか」を明示すべきであり、呼び出されるスクリプトの内容や実行時に取得される外部リソースも含めて表示する必要がある。
これらに加え、組織レベルでは以下のような対策も有効と考えられる。
- 最小権限の原則：AIエージェントに付与する権限を業務上必要な最小限に絞る。APIキーや認証情報を環境変数で無制限に渡さず、スコープを絞ったトークンを使用する（※編集部の考察）
- サンドボックス実行：見慣れないリポジトリをAIエージェントで扱う際は、コンテナや仮想マシンなど隔離された環境で実行する（※編集部の考察）
- ネットワーク通信の監視：エージェントが起動するプロセスによる外部通信を監視・制限し、DNS TXTレコード取得のような想定外の通信を検知できる体制を整える（※編集部の考察）
詳細はMozilla Shows the Danger of Indirect Prompt Injections in AI Coding Agentsを参照していただきたい。
