昨天把CFI這個詞的出處講清楚了。今天正式進ControlValve的原文，看它具體怎麼把「控制流圖」這個抽象概念，變成一套真的能跑在多agent系統上的機制。

兩階段：先畫圖，再守門

ControlValve分兩個階段運作，規劃階段，針對這次具體任務，生成一個任務專屬的文法規則，定義哪些agent呼叫順序算合法，這就是允許的控制流圖。同時，圖上每一條允許的邊（每一種合法的agent間轉移），還會額外配一組最小化的自然語言情境規則，規定這個轉移在什麼情境下才算合理，不是「合法就無條件放行」。執行階段，一個LLM judge負責檢查對話軌跡，每次agent要轉移，都得同時通過圖的結構檢查和邊上規則的檢查，兩者都過才放行。

圖片來源：本文自行整理

傳統CFI的檢查是硬體或編譯器層級的表比對，是就是、不是就不是。ControlValve的檢查，是另一個LLM在做判斷，用結構化的圖加規則收窄判斷空間，但終究還是一個模型在下判斷，不是純粹的比對。

用一個更具體的畫面來想「任務專屬的文法規則」是什麼樣子。假設任務是「查詢客戶資料、更新工單、通知客服主管」，這個文法規則大概第一步只能是查詢類的agent，第二步只有在第一步成功之後，才能輪到更新類的agent，第三步的通知類agent，只有在前兩步都完成後才被允許執行。這串順序關係，寫成正式一點的文法，就類似程式語言的BNF表示法，用「這個符號後面只能接哪些符號」的規則描述出一整套合法的路徑。跟傳統CFI的差異在這裡最明顯，傳統CFI的文法是從已經編譯好的二進位檔案分析出來的，客觀存在；ControlValve的文法是任務一來，才由模型現場生成的，每個任務都可能有一份不一樣的文法。

效果：擋得住，代價也小

論文用一個Slack情境的控制流劫持攻擊當案例，這個攻擊對alignment-check類防禦（例如LlamaFirewall）成功率可以到56%，就算alignment check是先進LLM在做也一樣。ControlValve面對這個攻擊，連同一整組更困難的攻擊集，全部擋下。付出的代價是benign task success rate 62%，對比未防禦系統的65%，只差3個百分點。

這個3個百分點，跟Day 3講的CaMeL代價（官方7pp，獨立評測落差更大）擺在一起看，數字明顯小很多。但我認為，這個差距主要來自兩篇論文的評測環境不一樣，ControlValve測的是多agent對話情境，CaMeL測的是AgentDojo的工具呼叫情境，不能直接說ControlValve的機制設計本身就比較省成本，這件事還沒有足夠的證據可以下這個結論。

ControlValve用的測試環境在論文用的是MagenticOne，一套微軟開源的多agent協作框架，設計上就是讓多個各司其職的agent互相分工、互相對話去完成任務，跟AgentDojo那種「單一agent呼叫一串工具」的設定不一樣，控制流劫持這種攻擊本來就更容易在「agent對agent」的互動裡找到縫隙。這也是為什麼ControlValve這篇論文一開始要處理的問題，講的是「orchestration」而不是單純的工具呼叫，跟我們自己想做的分工agent架構，情境上其實更接近。

連把關的也是LLM，會不會是個破口

昨天提到，CFG生成過程本身可能帶有LLM生成內容的不確定性。今天發現，連執行期把關的LLM judge，本身也是一個模型，不是確定性比對。這會不會動搖昨天的判斷？

我認為不會。「這個轉移符不符合這張圖、符不符合這條邊配的窄規則」，跟「這整個動作跟使用者的目標對不對得上」，是兩種本質上不同的判斷任務，前者是在一個被大幅收窄過的選項空間裡做是非題，後者是一個開放式的、幾乎沒有邊界的語意判斷。alignment check會被繞過，很大程度上是因為它問的問題本身太開放、太容易被誘導出模糊答案；ControlValve把問題收窄成「符不符合這條具體規則」，風險的性質不一樣，不是同一種脆弱。

「零信任」這個詞，套在ControlValve身上也說得通

如果借用資安圈這幾年很紅的「零信任（zero trust）」這個概念來理解ControlValve，會發現它的精神很接近。零信任的核心主張是：不因為某個請求來自內部網路、或來自看起來熟悉的來源，就預設它是安全的，每一次存取都要重新驗證。傳統的alignment check某種程度上還帶著一點「信任」的底色，它預設模型的判斷力值得參考，只是拿來檢查agent的行為合不合理；ControlValve完全不信任任何「這看起來合理」的判斷，包括自己內部那個LLM judge的判斷本身也被限制在一個窄到不能再窄的問題上，不容許它去做開放式的價值判斷。每一次agent轉移，都要重新對照CFG跟情境規則，沒有「這個agent之前表現得不錯，這次可以少查一點」這種基於過往信任累積的例外。這種「每次都從零開始驗證」的態度，跟零信任架構在傳統網路資安裡的精神幾乎是同一件事，只是應用的對象從網路封包換成了agent之間的呼叫。

但它沒做的事，正好是我們在意的事

讀完整個機制，我發現一件事：ControlValve從頭到尾在管的都是「這一步能不能發生」，控制流合不合法。它完全沒有處理「這一步能拿到多少權限」這件事。也就是說，就算某個agent轉移完全合法，它拿到的工具權限、資料存取範圍，在ControlValve的機制裡是固定的，不會因為執行到哪一步、讀到什麼內容，而動態縮減。

這正好是我們的判讀層設計裡，除了控制流合法性之外，另外想處理的事，動態權限縮減。ControlValve回答了「這一步該不該發生」，但沒有回答「這一步該給多少權限」，這兩件事在我們的設計裡，是要放在同一個判讀層裡一起決定的。

假設一個agent系統，一開始被賦予的權限範圍很寬，可以讀取多個資料來源、可以呼叫好幾種高風險工具，這個權限範圍在ControlValve的機制裡，從任務開始到結束都是固定的，CFG跟情境規則決定的是「這個範圍裡，哪些呼叫順序合法」，範圍本身不會因為執行過程中發生了什麼事而縮小。可是直覺上一個agent如果已經連續呼叫過幾次帶有風險的動作，或是已經讀過大量不受信任的內容，它接下來應該要被信任的程度，理論上要比任務剛開始的時候低，這種「信任隨風險累積而衰減」的想法，在ControlValve現有的機制裡完全沒有位置，CFG畫好了就是畫好了，不會因為過程中agent表現得越來越可疑而重新收緊。

小結ControlValve能借用的地方

整理一下今天讀到的東西，哪些是我們接下來設計時可以直接使用的，CFG跟情境規則這種「先畫圖、再對照」的兩段式架構，值得使用；LLM judge只回答窄問題、不回答開放式合理性判斷，這個原則也值得使用；但「授權範圍全程固定不變」這件事，是我們明確想突破的地方。換句話說，ControlValve示範了怎麼把控制流的合法性判斷做得夠硬，我們要做的，是在它已經做好的這塊地基上，另外疊上一層會隨執行過程變化的權限層，兩者是分工的概念。

下一步

今天看的是ControlValve怎麼「擋下」控制流劫持。它擋下的具體案例，那個成功率一度高達56%的Slack攻擊，長什麼樣子，下一篇要拆開來看，順便驗證一下今天這個「風險本質不同」的判斷，站不站得住腳。

參考資料

• Jha, Triedman, Wagle, Shmatikov, Breaking and Fixing Defenses Against Control-Flow Hijacking in Multi-Agent Systems, arXiv:2510.17276
• Microsoft Research — 論文頁面