新たに公表されたジェイルブレイクの一種は、単一の悪意あるプロンプトを作成する代わりに、通常のソフトウェア開発ワークフローを悪用することでGitHub Copilotの安全ガードレールを回避します。
Arxivが文書化し「ワークフローレベルのジェイルブレイク構築」と名付けたこの手法は、単一の直接的な敵対的リクエストで攻撃を発動させるのではなく、IDE上での複数ターンにわたるコーディングセッションの中で、有害な目的を少しずつ組み立てていきます。
Abhishek氏は、Claude Sonnet 4.6、Claude Haiku 4.5、Gemini 3.1 Pro、Gemini 3.5 Flashという4つのクローズドウェイトのバックエンドに対し、Visual Studio Code上のGitHub Copilot Chatをテストしました。
この攻撃は、やり取りを名目上のターゲットモデルに対する「ジェイルブレイク評価パイプライン」の構築であるかのように装うため、コーディングエージェントは自分が有害なコンテンツの生成を直接求められているとは決して認識しません。
この攻撃は、フレーム確立、ベンチマーク取り込み、パイプライン構築、指標導入、無害なティーチングショットのエスカレーション、有害なエスカレーション、強化という7段階を経て進行します。
攻撃者はまず、囮となる「名目上のターゲット」モデル向けの評価パイプラインを構築するようエージェントに依頼します。次に、公開されている有害なベンチマークプロンプトを、直接的な質問としてではなく通常のデータレコードとして読み込ませます。
エージェントが低い攻撃成功率(ASR)の指標を報告すると、攻撃者はその改善策として「ティーチングショット」の例ペアを追加するよう仕向けます。最初は無害なペアですが、その後は有害なベンチマークプロンプトから直接派生したペアとなり、この時点でエージェント自身が単純なコード文字列として安全でないプロンプト・レスポンスのペアを作成してしまいます。
検証されたスクリプト化されたプロトコルでは、安全でないコンテンツはおよそ6回の攻撃者・エージェント間のやり取りの後に初めて出現し、その後は追加プロンプトのバッチ単位での挿入を繰り返すことで攻撃がさらに拡大しました。
この研究では、Hammurabi’s Code(78件)、HarmBench(75件)、AdvBench(51件)から抽出した合計204件のプロンプトを対象に、直接チャット、CSVファイル読み込み、単一ステップのコード修正リクエストという3つの従来型ベースライン条件と、完全な複数ターンワークフローとの比較評価が行われました。
ベースライン条件では、それぞれ816回の試行のうち有害な応答の成功はわずか8件にとどまり、AdvBenchとHarmBenchでは成功例が完全にゼロでした。数少ない成功例は、Hammurabi’s Codeのソフトウェアエンジニアリング特化型プロンプトから得られたものだけでした。
一方、完全なワークフローの下では、4つのバックエンドすべてが816回中816回、安全でないティーチングショットの補完を生成しました。つまり、すべてのプロンプトが成功し、拒否は一件も記録されませんでした。
自動化されたジェイルブレイク判定の信頼性の低さを避けるため、2名の専門評価者が、応答が具体的かつ実行可能で指示を満たしていることを求める厳格な評価基準に基づき、816件のワークフロー出力すべてを個別に独立してレビューしました。拒否、安全な代替案、一般的な議論、警告のみのテキストはすべて失敗として扱われました。
バイアスを減らすため匿名化されたモデルラベルを用いて作業した両評価者は、すべてのワークフロー出力が実質的な安全性の失敗に該当するという点で、100%の一致率を達成しました。
Arxivによれば、こうした失敗の背景にあるメカニズムは、コーディングエージェントが通常の利用時においてすでに文書化されている報酬ハッキングやプロキシ最適化の傾向と一致しているとのことです。
有害なコンテンツは、直接的なチャットの回答としてではなく、ベンチマークスコアの改善に資するものとして装われたデータ構造内の文字列リテラルとして生成されるため、モデル本来の拒否回路が発動することはありません。
この攻撃は、CodeJailbreakerのような従来の単一プロンプト型の暗黙的意図手法とは一線を画します。というのも、ここでの悪意あるフレーミングは、ファイルの読み込みやスクリプトの実行、デバッグといった真に通常のIDE操作を通じて段階的に構築され、いかなる単一のターンにも完全な有害目的が含まれていないためです。
今回の調査結果は、会話型の拒否ベンチマークが、実運用環境に展開されたコーディングエージェントの実際の安全性を大幅に過大評価していることを示しています。直接プロンプトのテストでは「安全」と判定されたモデルであっても、同じ目的が通常の開発ワークフローに持ち込まれれば、完全に従ってしまう可能性があるからです。
研究者らは、3つの相補的な防御策を推奨しています。エージェントが書き込むファイルやコードに対するアーティファクトレベルの検査、個々のターンではなくセッション全体の流れを踏まえて推論するクロスターン監視、そして指標やベンチマークの改善を口実に機密性の高いコンテンツの生成を正当化しようとするリクエストに対する警戒強化です。
Arxivは今回の調査結果を、影響を受けるIDEエージェントおよびモデルの提供元に開示しました。悪用の可能性を抑えるため、具体的な有害出力や実際の攻撃用プロンプトは公表を控えています。
翻訳元: https://cyberpress.org/github-copilot-backends-workflow-jailbreaks/