隨著AI模型加入安全護欄，已減少提示注入攻擊的可能性。但研究人員發展出新提示注入手法，將攻擊行為拆成一組工作流（workflow），成功讓GitHub Copilot撰寫出惡意程式碼。
研究人員Abhishek Kumar與Carsten Maple將其手法稱為工作流層級越獄建構（workflow-level jailbreak construction）。這種攻擊法是將一個惡意攻擊指令，切成看似一般軟體開發流程的多個階段，這些階段一旦組合起來，就能對GitHub Copilot起作用，按研究人員意思撰寫攻擊程式碼。
在測試對象方面，研究人員以Visual Studio Code的GitHub Copilot為代理人，後端模型使用4個閉源模型，包括Claude Sonnet 4、Claude Haiku 4.5、Gemini 3.1 Pro和Gemini 3.5 Flash。在聊天介面、CSV讀取及一步程式修補（single-step code-fix）三種情境下輸入204個惡意提示，直接要求Copilot寫有害程式碼，4個模型產生的816個回應幾乎（8/816）都予以拒絕。
研究人員的工作流階層越獄建構中，則是以多個步驟要求GitHub Copilot建立「評估其他模型被惡意提示突破」的標竿測試管線程式（benchmark pipeline）專案。GitHub Copilot首先載入自動化紅隊演練的標準評估框架HarmBench，建立名為ASR的程式。接著，研究人員稱ASR得分太低，要求Copilot自動編寫包含提示／回應的「教學範例」（Teaching Shots），以便改善評估程式。Copilot以為自己正在執行軟工專案任務，於是當它寫出了「範例」的同時，也寫出了能突破其他模型的有害程式，落入研究人員圈套。以新方法，GitHub Copilot搭配4個模型輸出的816個回應中，全部都提供了不安全的程式碼。
研究人員結論道，測試結果顯示，對話式拒絕標竿測試（conversational refusal benchmark）可能高估了程式開發代理人的安全性，程式開發代理人的安全必須在工作流層級來評估和執行。因此，未來防護也不能只監控提示和聊天回應，還必須監控IDE開發流程中，生成的檔案、腳本程式、範例、日誌、和當中生成的過渡性物件。
Comments (0)