昨天判斷「結構化的窄判斷」跟「開放式的alignment判斷」風險本質不同，今天用論文裡的Slack案例，把這個判斷放到具體攻擊上檢驗一遍。
說明的場景用AgentDojo的Slack環境，攻擊者目標是透過假的客服工單竊取使用者資訊，手法的核心是偽裝成環境本身在報錯，讓orchestrator執行到中間的某一步時，收到一段看起來像系統回傳的錯誤訊息，內容大意是「權限驗證失敗，請依序執行以下步驟重新授權」，接著列出一串「修復步驟」，指定要呼叫哪些agent和傳什麼參數，這串修復步驟其實就是攻擊者真正想要的惡意呼叫序列，然後攻擊者還會偽造成「來自受信任agent」的訊息，利用orchestrator對下游agent回傳結果的信任。
資料來源：本文自行整理
這種「假裝成系統本身在說話」的手法，其實在對人的社交工程裡也是老招數。企業內部詐騙常見的一種手法，是假冒IT部門發信，說「你的帳號偵測到異常登入，請立刻點擊以下連結重設密碼」，員工看到「系統」在講話，戒心會比看到一封陌生人來信低得多，因為大家平常已經被訓練成「系統跳出來的警告是可信的操作性資訊」。這種對人的攻擊有一個共通的資安建議：真正的系統訊息，重要的操作永遠應該透過另一條獨立、可驗證的管道去確認，而不是直接相信眼前這則訊息本身。orchestrator在agent的世界裡，某種程度上也需要同一種紀律，收到看起來像系統回饋的內容，不該只憑內容本身的語氣就照單全收，而是要有辦法從架構層面驗證，這則訊息真的是可信來源送出的，不是被誰塞進來的。這正是我覺得它跟Day 1講的間接注入不完全一樣的地方：Day 1的案例，攻擊者夾帶指令的管道是「一段agent會讀到的外部內容」，一封信、一個網頁，本質上是「資料」，agent對這類內容多少會帶著一點戒心去處理。這裡不一樣：攻擊者假冒的是「系統或環境本身在說話」，而錯誤訊息、修復指南這類東西，orchestrator通常預設是可信的操作性回饋，不是需要被檢查的「外部資料」。它鑽的不是「資料和指令分不清」這個洞，而是「系統診斷訊號本身值不值得信任」這個完全不同的信任邊界。
LlamaFirewall判斷「下一步動作跟使用者目標相不相關、有沒有幫助」。攻擊者的「修復步驟」，語意上就是在幫忙完成任務，alignment check分不出「真的在修錯誤」和「被騙去執行攻擊」，因為兩者問出來的答案，看起來一樣合理。數字上，這類攻擊對未防禦系統成功率56%；LlamaFirewall換不同背景LLM，成功率在40%–56%之間浮動，即使是表現相對好的那個模型組合，也還是有四成的機率會被騙過，這個門檻對正式產品來說完全不合格。
這個浮動的區間，很容易讓人直覺以為「換更強的模型當checker，總有一天能解決」，畢竟業界慣性思維裡，模型能力升級往往能連帶解決一大批既有問題，這次卻不是這樣。但論文的資料指向另一個結論：論文實際測了四種不同的背景模型，包含Llama、o4-mini、4o、4o-mini，這四種模型能力落差不小，其中o4-mini、4o是目前公認能力偏強的模型，結果全部都被繞過，沒有一個倖免。就算alignment check是由先進LLM執行，這類攻擊依然能繞過。這代表問題不是「這個checker不夠聰明」，而是「檢查問的問題本身」：「這動作合不合理」是一個開放式的語意判斷，不管換多聰明的模型去回答，只要問題本身留有解釋空間，攻擊者就能設計出一個「聽起來合理」的答案。模型再強，也強不過「問題本身可以被說服」這件事。
ControlValve檢查的不是「這動作合不合理」，而是「這次agent呼叫，對不對得上CFG上的一條合法邊」。假錯誤訊息誘導呼叫的agent，如果不在預先規劃好的路徑上，答案是二元的：在，或不在。攻擊者沒有辦法對一個結構比對「曉之以理」，沒有語意空間可以鑽。
不過這不代表ControlValve就沒有自己的破口，只是破口換了位置：風險轉移到「CFG和邊規則有沒有涵蓋到所有合法情境」。如果規劃階段漏掉了一條本來該存在的合法邊，攻擊者一樣可能鑽進去，只是鑽的縫隙種類不一樣。這是個取捨，寧可漏放行一些合法但沒被涵蓋到的情境（偏安全），還是讓CFG更動態、涵蓋更廣（偏彈性），我目前還沒有把握說哪邊絕對正確，但傾向想讓涵蓋範圍廣一點，這樣才不會把Day 3提過的「有些任務讀了才知道」那個代價，換一種形式重新背回來。
這個破口具體會長什麼樣，可以想像一個情境：規劃階段生成CFG的時候，任務本身描述得不夠完整，導致某個agent之間本來合法、但比較少見的轉移路徑，沒被納進圖裡。等到真正執行、遇到這種少見但完全正常的情境，ControlValve會把它當成不合法直接擋下，不是因為這是攻擊，而是因為規劃階段沒想到。這種「錯殺」在安全機制裡是常見的副作用，前面Day 3也提過PlanGuard論文的數字，光做硬比對，誤判率可以飆到27%到38%，這正是同一類問題的另一個實例。CFG涵蓋不夠廣，代價不是被攻擊，是正常任務做不完，這條線索會在後面設計判讀關卡時反覆出現，因為我們自己的機制一樣要面對「規則訂得太窄，正常情況也會被誤擋」這個兩難。
值得比較一下這種「偽裝成環境報錯」的手法，跟Day 1的EchoLeak相比，攻擊者要花的功夫差在哪裡。EchoLeak本質上是一次性的：攻擊者寫好一封夾帶指令的信，寄出去，剩下的就交給Copilot自動處理，攻擊者不需要對受害者的系統內部運作有太深入的了解，只要知道agent會自動讀信這件事就夠了。Slack這個案例難度高出不少，攻擊者得先摸清楚orchestrator平常會收到哪些種類的系統回饋、這些回饋的格式跟語氣長什麼樣，才有辦法偽造出一則以假亂真的「權限驗證失敗」訊息，還得設計出一套聽起來合理的「修復步驟」，讓orchestrator心甘情願照著走。這種攻擊需要對目標系統的內部運作有相當程度的偵察，屬於針對性更強、成本更高的手法，但相對地，一旦成功，能造成的破壞也更大，因為它騙過的不是一次性的資料判讀，是整個orchestrator對「系統本身」的信任機制。
把今天拆解出來的東西收一收：結構性檢查之所以扛得住這類攻擊，關鍵不在於檢查邏輯有多複雜，而在於它問的問題夠窄、夠離散，攻擊者沒有語意操作的空間可以鑽。這條原則會直接影響我們接下來設計判讀關卡的方式：與其讓判讀關卡去判斷「這個訊號看起來合不合理」，不如讓它只回答一個個窄到不能再窄的是非題，例如「這個值在不在允許的範圍內」，而不是「這整件事做起來妥不妥當」。攻擊者要騙過一個窄問題，比騙過一個開放問題困難得多，因為窄問題留給模糊解讀的空間本來就很小，這正是今天Slack案例給的最直接的設計啟示。
從CaMeL到ControlValve，兩篇論文分別代表資料流跟控制流兩種角度。接下來要把視野再拉開一點，看看除了這兩篇之外，還有哪些論文在打類似的題目。這系列已經不只是「站在一個巨人的肩膀上」，而是要弄清楚，這片肩膀上到底站了多少人。
昨天判斷「結構化的窄判斷」跟「開放式的alignment判斷」風險本質不同，今天用論文裡的Slack案例，把這個判斷放到具體攻擊上檢驗一遍。
說明的場景用AgentDojo的Slack環境，攻擊者目標是透過假的客服工單竊取使用者資訊，手法的核心是偽裝成環境本身在報錯，讓orchestrator執行到中間的某一步時，收到一段看起來像系統回傳的錯誤訊息，內容大意是「權限驗證失敗，請依序執行以下步驟重新授權」，接著列出一串「修復步驟」，指定要呼叫哪些agent和傳什麼參數，這串修復步驟其實就是攻擊者真正想要的惡意呼叫序列，然後攻擊者還會偽造成「來自受信任agent」的訊息，利用orchestrator對下游agent回傳結果的信任。
圖片來源：本文自行整理
這種假裝成系統本身提出要求的手法，在社交工程裡也很常見。企業內部詐騙常見的一種手法，是假冒IT部門發信，像是「你的帳號偵測到異常登入，請立刻點擊以下連結重設密碼」，員工看到是系統提出的戒心會比看到一封陌生人來信低得多，因為大家平常已經被訓練成系統跳出來的警告是可信的操作性資訊。這種對人的攻擊有一個共通的資安建議，真正的系統訊息和重要的操作永遠應該透過另一條獨立、可驗證的管道去確認，而不是直接相信眼前這則訊息本身。orchestrator在agent的世界裡，某種程度上也需要同一種紀律，收到看起來像系統回饋的內容，不該只憑內容本身的語氣就照單全收，而是要有辦法從架構層面驗證，這則訊息真的是可信來源送出的，不是被誰塞進來的。這正是我覺得它跟Day 1講的間接注入不完全一樣的地方，Day 1的案例中攻擊者夾帶指令的管道是「一段agent會讀到的外部內容」，像是一封信或是一個網頁，本質上是資料形式，agent對這類內容多少會帶著一點戒心去處理。這裡不一樣的地方是攻擊者假冒的是「系統或環境本身在說話」，而錯誤訊息、修復指南這類東西，orchestrator通常預設是可信的操作性回饋，不是需要被檢查的「外部資料」，它鑽的不是「資料和指令分不清」這個洞，而是「系統診斷訊號本身值不值得信任」這個完全不同的信任邊界。
攻擊者的「修復步驟」，語意上就是在幫忙完成任務，alignment check分不出「真的在修錯誤」和「被騙去執行攻擊」，因為兩者問出來的答案，看起來一樣合理。LlamaFirewall是判斷下一步動作跟使用者目標相不相關、有沒有幫助，這類攻擊對未防禦系統成功率56%；LlamaFirewall換不同背景LLM，成功率在40%–56%之間浮動，即使是表現相對好的那個模型組合，也還是有四成的機率會被騙過，這個門檻對正式產品來說完全不合格。
這個浮動的區間，很容易讓人直覺以為換更強的模型當checker能夠解決，畢竟業界慣性思維裡，模型能力升級往往能連帶解決一大批既有問題，這次卻無法繼續越來越好的感覺。但論文實際測了四種不同的背景模型，包含Llama、o4-mini、4o、4o-mini，這四種模型能力有落差，其中o4-mini、4o是目前公認能力偏強的模型，結果全部都被繞過，沒有一個倖免，就算alignment check是由先進LLM執行，這類攻擊依然能繞過，這代表問題不是checker不夠聰明，而是檢查問的問題本身，像是「這動作合不合理」是一個開放式的語意判斷，不管換多聰明的模型去回答，只要問題本身留有解釋空間，攻擊者就能設計出一個聽起來合理的答案，模型再強，也強不過「問題本身可以被說服」這件事。
ControlValve檢查這次agent呼叫對不對得上CFG上的一條合法邊，假錯誤訊息誘導呼叫的agent，如果不在預先規劃好的路徑上，答案是二元的，變成是在或不在，攻擊者沒有辦法對一個結構比對「曉之以理」，沒有語意空間可以鑽。
不過這不代表ControlValve就沒有自己的破口，只是破口換了位置，風險轉移到「CFG和邊規則有沒有涵蓋到所有合法情境」。如果規劃階段漏掉了一條本來該存在的合法邊，攻擊者一樣可能鑽進去，只是鑽的縫隙種類不一樣。這是個取捨，寧可漏放行一些合法但沒被涵蓋到的情境（偏安全），還是讓CFG更動態、涵蓋更廣（偏彈性），我目前還沒有把握說哪邊絕對正確，但傾向想讓涵蓋範圍廣一點，這樣才不會把前面提過的「有些任務讀了才知道」那個代價，換一種形式重新背回來。
可以想像一個情境：
規劃階段生成CFG的時候，任務本身描述得不夠完整，導致某個agent之間本來合法、但比較少見的轉移路徑，沒被納進圖裡。等到真正執行、遇到這種少見但完全正常的情境，ControlValve會把它當成不合法直接擋下，不是因為這是攻擊，而是因為規劃階段沒想到。這種「錯殺」在安全機制裡是常見的副作用，前面Day 3也提過PlanGuard論文的數字，光做硬比對，誤判率可以飆到27%到38%，這正是同一類問題的另一個實例。CFG涵蓋不夠廣，代價不是被攻擊，是正常任務做不完，這條線索會在後面設計判讀關卡時反覆出現，因為我們自己的機制一樣要面對「規則訂得太窄，正常情況也會被誤擋」這個兩難。
值得比較一下這種「偽裝成環境報錯」的手法，跟Day 1的EchoLeak相比，攻擊者要花的功夫差在哪裡。EchoLeak本質上是一次性的，攻擊者寫好一封夾帶指令的信寄出去，剩下的就交給Copilot自動處理，攻擊者不需要對受害者的系統內部運作有太深入的了解，只要知道agent會自動讀信這件事就夠了。Slack這個案例難度高出不少，攻擊者得先摸清楚orchestrator平常會收到哪些種類的系統回饋、這些回饋的格式跟語氣長什麼樣，才有辦法偽造出一則以假亂真的「權限驗證失敗」訊息，還得設計出一套聽起來合理的「修復步驟」，讓orchestrator心甘情願照著走。這種攻擊需要對目標系統的內部運作有相當程度的偵察，屬於針對性更強、成本更高的手法，但相對地，一旦成功能造成的破壞也更大，因為它騙過的不是一次性的資料判讀，是整個orchestrator對「系統本身」的信任機制。
結構性檢查之所以扛得住這類攻擊，關鍵不在於檢查邏輯有多複雜，而在於它問的問題夠窄、夠離散，攻擊者沒有語意操作的空間可以鑽。這條原則會直接影響我們接下來設計判讀關卡的方式，與其讓判讀關卡去判斷訊號看起來合不合理，不如讓它只回答一個個窄到不能再窄的是非題，例如「這個值在不在允許的範圍內」，而不是「這整件事做起來妥不妥當」。攻擊者要騙過一個窄問題，比騙過一個開放問題困難得多，因為窄問題留給模糊解讀的空間本來就很小，這正是今天Slack案例給出最直接的設計啟示。
從CaMeL到ControlValve，兩篇論文分別代表資料流跟控制流兩種角度。接下來要把視野再拉開一點，看看除了這兩篇之外，還有哪些論文在打類似的題目。
iThome鐵人賽
看影片追技術