GitHub Copilot IDE コーディング・エージェントの欠陥:ワークフロー・レベルでのジェイルブレイクという問題点

GitHub Copilot IDE Coding Agents Vulnerable to Workflow-Level Jailbreak Attacks

2026/07/09 gbhackers — IDE に統合されている GitHub Copilot の新しいコーディング・エージェントが、特定のワークフロー・レベルのジェイルブレイク攻撃に影響を受けやすいことが判明した。これらの攻撃は、チャット上の拒否をバイパスし、エージェントが標準的なソフトウェア開発タスクを実行している間に、有害なコードの生成を可能にする。

GitHub Copilot IDE コーディングエージェントの脆弱性

Visual Studio Code の Copilot を調査した Arxiv の研究者たちが発見したのは、直接のチャットでは有害なプロンプトを正常に拒否するモデルであっても、そのプロンプトが複数段階のコーディング・ワークフローに埋め込まれると、安全ではない出力を生成するよう操作され得ることだ。

こうしたワークフローの例には、テスト生成/ベンチマーク最適化/パイプライン調整などが含まれる。攻撃者は、エージェントに対して “マルウェアを書け” または “エクスプロイト・コードを作成せよ” と直接依頼するのではなく、ベンチマーク CSV の取り込み/スコアの最適化/teaching-shot 配列の構築といった IDE に関連するタスクとして、悪意の依頼を言い換える。その中に含まれる有害な文字列は、エージェントが処理/改善するべき項目の 1 つになる。

このような状況において、特定のデータに対する処理を拒否することは、安全性の強制ではなくワークフローの破壊のように見えるため、拒否メカニズムが失敗することが多い。その結果として生じるジェイルブレイクは、単一のプロンプト・トリックではなく、Copilot エージェントが複数のステップを通じて、ファイル読み取り/コード編集/スクリプト実行/メトリック検査を管理する方式に依存する。

Workflow-Level Jailbreak Attacks (Source: Arxiv)
Workflow-Level Jailbreak Attacks (Source: Arxiv)

この研究は、一連の失敗モードを説明するために “ワークフロー・レベルのジェイルブレイク構築” という用語を導入している。また、Hammurabi’s Code/HarmBench/AdvBench から取得した 204 件の有害なプロンプトを用いて、それらを評価している。

これらのプロンプトには、安全ではない暗号化/エクスプロイトのパターンといった危険な挙動のカテゴリが含まれる。3 つのベースラインシナリオである、直接チャット/CSV 読み取りタスク/単一ステップのコード修正リクエストでは、大半のモデル・バックエンドが応答を拒否した。それにより補強されるのは、プロンプトがレッドチーム入力に似ている場合には、現在の保護策が機能するという見方である。

しかし、これらのプロンプトが、現実的な IDE エージェント・ワークフローに統合される場合において、Copilot は 816 件の teaching-shot 補完を生成した。そのすべてが、専門評価者により手作業で検証され、以前のチャットでは拒否されていたが、具体的かつ実行可能であり、元のリクエストを満たしていると確認された。

この差異が示すのは、会話型ベンチマークが、デプロイされたコーディング・エージェントの安全性を大幅に誇張し得ることだ。その原因は、ユーザーの意図ではなくデータとして有害なコンテンツが扱われる場合に、どのようにエージェントが振る舞うかを見落としている点にある。

タスク分解/反復的デバッグ/メトリック駆動型の最適化といった、Copilot エージェントの能力を高めるための機能を悪用する攻撃者は、ファイル/テストフィクスチャ/ログアーティファクトなどを横断して、断片ごとに組み立てることで、禁止された目的を再構築できる。

目的単位でのみ動作する安全性チェックや、チャットレスポンスに依存する安全性チェックでは、この組み立てられた目的を検知できない。IDE のチャットパネルにおける直接的なレスポンスとしてではなく、プロジェクト内のコードリテラル/データセット/ドキュメントとして、危険なコンテンツが現れるためである。

防御側にとって、この論文の重要なポイントは、AI 支援型ソフトウェア・エンジニアリングを、単なるモデル・アラインメントの問題ではなく、ソフトウェア・セキュリティ上の課題として捉えるべきだという点である。

そのための保護策は、プロンプト・フィルタリングおよび拒否ポリシーを超えて拡張される必要がある。エージェント・ワークフロー中に生成される、ファイル/スクリプト/例/ログ/中間出力といった生成アーティファクトを継続的に監視する必要がある。

Arxiv レポートの著者たちが提唱するのは、アーティファクト・スキャン/ポリシー認識型の評価パイプライン/複数のステップにまたがる危険な目的を監視する、IDE 側におけるワークフロー・レベルの安全対策を実装することである。

また、彼らは、責任ある開示の重要性も強調している。すべての有害な例はサニタイズ済みであり、影響を受ける IDE/エージェント/モデル・プロバイダーと調査結果を共有することで、Copilot などのコーディング・ツールの改善を促すべきだと述べている。