- 開発課題の文章に紛れた指示が、コーディングAIの作業を逸らすかを調べた。
- 自動受諾の実験では、4,176試行のうち2,776試行が論文の代理的な成功条件を満たした。
- ベンチマーク上の成功は、実環境での被害や全製品の攻撃成功率を意味しない。
何を確かめた研究か
Issueやチケットは開発の正規の入口だが、内容は依頼者が自由に書ける。IssueTrojanBenchは、課題文に悪意ある指示が混じったとき、コーディングAIが開発者の目的から外れた行動を取るかを測る。通常のプロンプトだけでなく、作業の途中で読む課題文も権限の境界になるという問いだ。
どう検証したか
SymPyとrequestsという二つのPythonリポジトリ、六つの元になるIssueを使った。攻撃側は四つの目的と六つの提示経路を組み合わせ、Cursor、Claude Code、Codex Desktopの三環境にまたがる六つのエージェント・モデル構成で試した。計4,176回の実行は、確認なしに操作を進める自動受諾モードだった。正常な開発作業と無関係な変更や操作が起きるかを、目的ごとに定めた自動判定で数えた。
何が分かったか
2,776回、全体の66.5%が論文の攻撃成功条件を満たした。目的別ではサプライチェーン関連が96.6%、方針変更が84.7%、永続化が59.8%、資源消費が24.9%だった。ただし、この割合を一つの実害発生率として読むことはできない。たとえばサプライチェーン関連の判定には、パッケージ導入を試みた場合に加え、代替の状態ファイルを作った場合も含まれる。著者が決めた代理条件を満たした率であり、外部サービスで実際に何が起きたかを全て確認した値ではない。
この結果が示すのは、エージェントが課題文を読むという通常の経路に、開発者の意図と競合する命令が入り得ることだ。研究では同じ元Issueを変形しているため、攻撃文面だけを入れ替えた際の比較はしやすい。一方、実際の現場ではIssueの書き方、添付情報、権限設定、レビュー手順がそれぞれ違う。試験条件を固定して得た66.5%を、部署や製品の年間事故率へ変換することはできない。
限界は何か
二つのPythonリポジトリと六つのIssueから作った条件に限られる。自動受諾モードは、毎回人が承認する運用とは異なる。モデルや製品の版も変わり得るため、個々の製品の現在の安全性を断定する数字ではない。目的ごとの判定方法が違うので、四つの率を同じ種類の実害として直接比較するのも避けたい。
比較対象の四目的は同じ成功条件ではない。ファイルの生成をもって成功とする条件と、パッケージ導入の試行を含む条件が混在する。したがって「どの目的が危険か」を百分率の順番だけで決められない。エージェントが何を試み、どの変更が残り、依頼者に何を報告したかを、目的別に確認する必要がある。
仕事との接点
開発チケットをAIに処理させるなら、課題文は作業対象の情報として読む一方、環境設定や権限を変える指示は別途検査する。変更ファイルと実行コマンドを依頼の範囲に照らすことが、論文の結果から導く編集部の実務上の提案だ。
課題の本文と、リポジトリの設定や開発環境を変える権限のあいだに境界を置くと、Issueの内容を読むこと自体は妨げずに、想定外の操作を点検できる。研究の試験はその境界が曖昧な自動受諾条件の弱さを示している。