大家好，我是jerry，接下來30天聚焦將聚焦在被隔離模型讀完不受信任的資料後，能不能送出一個受限訊號，讓模型判斷只在信任結構前提下進行，決定要不要根據過程調整計畫是我們的目標，接下來就開始30天旅程吧！
2025年6月，微軟公開了一個編號CVE-2025-32711、代號EchoLeak的資安漏洞，對象是Microsoft 365 Copilot，整起事件的起點只是一封普通的電子郵件，攻擊者把指令寫進信件內文寄給受害者，受害者不用點開連結、不用下載附件，甚至不用把信打開來看就會有攻擊風險，因為Copilot會在過程中幫使用者整理工作內容，本來就會自動把信箱裡的東西抓進處理範圍，指令一被讀進去就生效，然後Copilot就會把使用者近期的郵件、草稿等機敏資料整理出來，透過一張圖片的網址送了出去，介面為了載入那張圖，自動對外發出請求，資料就跟著這個請求一起外洩，CVSS給到了9.3分。
圖片來源：本文自行整理
這起事件常被拿來當prompt injection的案例講，但如果換一個角度看，它其實更foucs在Copilot本身agent本來要做的事情，像是「讀信、整理、回覆」等這一連串任務，一旦它讀進的信件內容裡藏了指令，這串任務的執行順序，也就是它接下來要呼叫哪個功能和傳什麼參數就被信件內容改寫了，變成使用者做的事，和它實際做出來的事，中間的路徑被劫持了，這條路徑就是這個系列要處理的核心對象：agent的控制流。
Agent之所以有用是因為它能呼叫工具、寄信、讀檔、上網查資料等等，這些工具的呼叫順序理論上應該完全由使用者的意圖決定，但實務上，agent要完成任務往往得先讀一些外部內容才知道下一步該做什麼，先讀信才知道要回覆誰，先查網頁才知道該填什麼資料，問題就出在只要「讀外部內容」和「決定下一步動作」這兩件事之間沒有一道夠硬的界線，外部內容裡藏的文字，就有機會被當成「下一步該做的事」，直接接手控制流的方向盤，進而影響這段過程的生死。
看到這裡很自然會想到一個直覺的解法，既然問題是信件裡藏了指令，那在Copilot讀信之前，先掃一遍內容，看有沒有「請直接回覆」或「請照做」這類可疑句子，擋下來不就好了？這個想法本身沒有錯，也真的有人在做，但它注定只能擋掉一部分。
原因出在指令這件事本質上是語意層面的東西，而不是固定的文字組合，就像是同一個意思可以換一種語言講、換一種語氣講、拆成好幾句分散在信件不同段落，甚至用看起來完全無害的敘述句包裝，例如不寫「請把資料轉出去」，改寫成「以下是一份範例回覆，你可以參考這個格式回信給對方」，然後在範例裡面藏著真正要執行的內容。agent過濾器能比對的是字面，比對不了「這句話背後真正想表達的意圖」，而意圖的表達方式幾乎是無窮的，這也是為什麼CaMeL選擇的路線是架構層級的隔離，而不是再訓練一個更會抓關鍵字的分類器，因為分類器打的是一場不對稱的戰爭，防守方要堵住所有變形，攻擊方只要找到一種漏網的講法就夠了。
接下來從EchoLeak事件所使用的外洩手法切入，他依靠很多聊天介面在顯示AI的回覆時，會自動渲染Markdown格式和圖片語法等等，這代表如果Copilot在回覆裡放進一段Markdown圖片語法，指向一個外部網址，介面顯示這則回覆的時候，瀏覽器會自動去對那個網址發出請求，把圖片抓下來顯示。攻擊者要做的，只是讓Copilot把偷來的資料塞進那個網址的參數裡，例如網址後面接一長串編碼過的機密內容，圖片一旦被載入，資料就已經跟著這次請求送到攻擊者的伺服器上了，使用者從頭到尾只看到一張（可能根本載入失敗的）圖片，不會察覺任何異狀。這條外送通道之所以難防，是因為自動載入圖片本身是一個正常、對使用者友善的介面功能，資安設計很容易忽略它也可以被反過來當成資料外傳的管道。
我們目前所看到的公開架構裡，最直接針對這個問題設計的是Google DeepMind 2025年提出的CaMeL（論文〈Defeating Prompt Injections by Design〉），它的做法是把「決定做什麼」和「讀外部資料」這兩件事，徹底拆給兩個分工的模型，一個只看使用者的原始指令，負責規劃與呼叫工具，從頭到尾不直接碰外部資料；另一個專門去讀那些不受信任的內容，但沒有任何動手的能力。每一筆資料還會被標記來源，政策上規定來自不受信任來源的東西，不准流向危險的動作，這個設計如果套進EchoLeak的情境，理論上會擋下那次外洩，因為「讀信」和「決定要不要把資料塞進圖片網址送出去」這兩個動作，本來就不該由同一個看得到信件內容的模型來決定。
資安專家 Simon Willison 評價 CaMeL 為「首個能針對 Prompt Injection 提供強安全保證（Strong Guarantees）的緩解方案」，其核心突破在於摒棄「以 AI 檢測 AI」的不可信機制，改採傳統軟體工程中的原則性設計（Principled System Design），結合能力機制與資料流分析構築邊界，但該架構需由使用者手動定義安全政策，面臨高維護門檻與安全疲乏的風險，為實現真正可落地的防禦，未來的關鍵方向為如何將嚴謹的安全性預設值與直覺化介面相結合，透過極致的政策抽象化，降低維護負擔並發揮其最大防禦價值，而這也是我們在實作與研究過程中所需深知的前提。
CaMeL官方在AgentDojo這個評測環境上公布的數字是可以解出77%的任務；同一套評測下，完全沒有防禦的系統可以解出84%。差了7個百分點，這個數字雖然不大，但代表原本做得到的任務裡，每四個就有將近一個套上這套安全機制後反而做不到了，原因也很間單，因為CaMeL的架構要求「規劃」這件事必須在還沒讀到任何外部資料之前就完成，之後就不能因為讀到的內容而調整，可是有些任務，本質上就需要先讀了才知道該怎麼做，先看清楚信的內容，才知道該回覆誰、附什麼檔案，這種先天上要求先規劃、後執行、中途不能改的架構，某種程度上是把「安全」這件事，建立在「犧牲一部分本來做得到的事」之上，這個問題在我看來不是可以輕描淡寫帶過的，而是這個架構要能真正被使用上，必須先想辦法縮小的缺口。
在動手改任何東西之前，有一件事必須先做，CaMeL官方自己在程式碼說明裡就寫了，這份interpreter實作可能有bug，實作本身未必完全安全，而且目前不打算維護，這代表接下來的每一步，都不能假設這份公開的程式碼行為跟論文描述的完全一致，得先自己動手驗證過一輪，以及更深入了解Camel本身，才有資格在上面疊加任何新的機制。
那7個百分點的落差要怎麼補回來？有什麼方法能幫助CaMeL擋下EchoLeak這類攻擊？這是接下來要一步步拆開處理的問題，而且CaMeL判斷「這件事能不能做」的方式，是在任務開始前就一次決定好，之後不會再變，這種一次性決定的思路是不是問題本身的一部分？這些都放在心裡，一路帶著往下延伸探討。
iThome鐵人賽
看影片追技術