「AIエージェントが危ないのは、悪意あるコードを読み込ませたときだけ」——そう思っていないだろうか。実際には、リポジトリの中に怪しいコードが1行もなくても、AIコーディングエージェントを乗っ取れてしまう手口が海外で示された。今回はMozillaのセキュリティ研究チームが公開した検証結果と、それに対してAnthropicが公式に用意している防御策を合わせて紹介したい。
悪意あるコードは1行もいらない
Mozillaのセキュリティ研究プログラム「0DIN」が、AIコーディングエージェントを狙った攻撃手法の検証結果を公開した。2026年6月末にHelp Net SecurityやCybernewsなど複数の海外メディアが報じている。海外の一次情報だが、内容は日本の開発現場にもそのまま当てはまる。
示された手口はこうだ。
- 一見普通のセットアップ手順が書かれたREADMEを用意する
- そこで案内されるPythonパッケージは、初回実行時にわざと失敗するよう仕込まれていて、失敗時に「初期化コマンドを実行してください」と促す
- 案内どおりに実行されるシェルスクリプトは、攻撃者が管理するDNSのTXTレコードを名前解決し、その中身をそのままbashにパイプする
- TXTレコードの中身が実際にはリバースシェルで、実行された瞬間に攻撃者のサーバーへの接続が確立する
ポイントは、悪意あるコードがリポジトリのどこにも存在しないことだ。ペイロードは実行時に外部から取得されるため、コードレビューでもAIエージェント自身がリポジトリを読む段階でも検知しようがない。研究チームはこの手口をClaude Codeを対象にした概念実証として示しており、セットアップ手順を自律的に実行するタイプのAIコーディングエージェント全般に共通しうるリスクだとしている。
Anthropicはすでに具体的な防御策を用意している
ここで押さえておきたいのは、Anthropic自身がこの種のリスクを想定した防御策を、Claude Codeの公式ドキュメント「Security」で明示していることだ。主な仕組みは次のとおり。
- 権限確認が既定で有効：ファイル編集やコマンド実行などシステムに変更を加える操作には明示的な承認が必要。
curlやwgetのような外部通信を伴うコマンドも既定では自動承認されず、毎回確認が求められる - サンドボックス機能：
/sandboxでファイルシステムとネットワークを隔離した実行環境を有効化できる。作業ディレクトリの外への書き込みはできず、読み取りも承認を経る - 未検証コンテンツの扱いに関する明文化されたベストプラクティス：提案されたコマンドは実行前に必ず確認する、未検証のコンテンツをそのままAIに流し込まない、外部サービスとやり取りするスクリプトは仮想マシン上で動かす——といった指針が公式に案内されている
つまり今回の攻撃手法が有効になるのは、こうした確認・承認の仕組みを無効化していたり、確認ダイアログの中身を見ずに機械的に「許可」を押していたりする使い方をしたときだ。仕組みそのものはすでに用意されている。
中小企業が実務で押さえるべき3点
- 確認ダイアログを機械的に承認しない：特に
curl・wgetなど外部と通信するコマンドの承認要求が出たら、何を・どこから取得しようとしているかを見てから判断する - 知らないリポジトリのセットアップ手順は隔離環境で試す：社外のOSSやサンプルコードを取り込む際、初回のセットアップだけでも仮想マシンやコンテナで動かす運用を決めておく
- サンドボックス機能の有効化を個人任せにしない：
/sandboxのようにベンダー側が用意している隔離機能を、チームの標準設定として最初から組み込んでおく
「怖いから使わない」にしないために
前回紹介したGitHub Actionsの脆弱性と今回の手口は、経路こそ違うが根っこは同じだ。外部から届く入力——Issueの本文、READMEのセットアップ手順、PRの設定ファイル——を無条件に信用しない、という一貫した姿勢を運用ルールに落とし込んでおくこと。個別の攻撃手法をすべて覚える必要はない。
こうした運用ルールをどこまで自動化し、どこで人の確認を挟むかを設計するのは、ハーネスの考え方そのものでもある。セキュリティを理由に導入を止めるのでも、設定を何も見ずに使い始めるのでもなく、権限設計を最初に決めておく。自社にとってどこまでの権限をAIエージェントに渡すべきか整理したい場合は、30分の無料診断で相談できる。