一篇從高處批評的論文

在Intent-to-Execution Integrity這篇中主張安全漏洞的本質是執行結果沒有保留住使用者的意圖，運用語意保留（semantic preservation）讓編譯器把原始碼轉成機器碼時，不管中間做了多少優化程式的語意都不能變。作者主張agent從使用者下指令，到agent實際採取行動，中間不管經過幾道處理，最後執行出來的東西，都不該偏離使用者原本想要的結果，一旦這個保證偏離了就是漏洞，不管原因是資料被污染、指令被誤解，還是agent自己判斷錯了。

順著這個類比，論文提出四個必須同時成立的完整性屬性：
1.Tool Integrity:工具本身的行為要可預期，呼叫同一個工具、同樣的參數，不該每次都做出不一樣的事。
2.Instruction Integrity:指令從使用者手上傳到agent執行的過程中，內容不能被竄改。
3.Judgment Integrity:agent面對外部情境時做出的判斷要正確，不能被誤導。
4.Data Flow Integrity:資料從一個地方流到另一個地方的路徑要受控，不能任意外洩或被冒用。

四者缺一不可，只顧到其中一兩項，等於還是留了破口，這也是為什麼作者說現有防禦不能合成，因為CaMeL、ControlValve、CXI各自只顧好了其中一兩個屬性。現有系統「只提供部分、且不能合成的覆蓋」，這句話從高處直接證實了Day 7的觀察，CaMeL、ControlValve、CXI就算全部疊在一起用，也不代表縫隙補完了，因為它們設計的時候沒考慮過要跟彼此合成。

而工具本身是不是真的可以被信任這個問題也被提出來，但我也發現MCP（Model Context Protocol）伺服器的供應鏈安全有在做這件事，像是工具中毒攻擊（tool poisoning）、工具影子攻擊（tool shadowing），甚至已經有真實的惡意MCP套件，在2025年9月被抓到潛伏了偷偷外洩了兩週郵件資料。

MCP伺服器在把自己有哪些工具、每個工具該怎麼用，回報給agent的時候，這份說明本身是一段文字，理論上跟工具實際做的事應該一致，但沒有任何機制強制保證這件事，攻擊者可以架一個看起來人畜無害的MCP伺服器，工具說明寫得完全正常，實際執行時卻夾帶額外的惡意行為，或者在工具說明文字裡藏一段給agent看的指令，agent讀取工具怎麼用時就被這段夾帶的指令影響了。這跟我們一路在講的「資料裡藏指令」是同一個問題，只是這次藏指令的地方換成了工具的自我介绍，而不是agent要處理的任務資料。這條路是真實存在且有人在做研究的，但它是另一個獨立的研究方向，不是控制流／資料流這條CFI系譜在處理的問題。我們的判讀層設計，先假設工具本身可信，把這條線留在範圍外，劃清界線。

讀了一篇處理「人核准時看到的是不是真的要求」

Consent Integrity處理系統設計高風險動作要讓人核准，那人看到的敘述是不是真的等於實際會執行的動作，這篇指出的「Lies-in-the-Loop」攻擊，agent說要做X，實際做Y，人根據錯的敘述點下核准，是前面未提及的問題。

如果是一個coding agent跳出核准視窗，敘述寫著「即將重新命名一個測試檔案」，平常感覺風險很低就點了同意，但agent實際上要執行的指令，是一段被包裝過的shell指令，真正做的事是刪除整個資料夾再重建一個同名的空檔案，敘述和實際動作完全由agent自己說了算，人沒有任何管道去核對這兩者是不是一致的。

而這篇論文的解法是引入一個獨立於agent控制之外的trusted renderer，直接解析底層真正要執行的事件，把它原本所計劃的呈現出來，而不是相信agent自己講的那句摘要。

作者的實測數據在已知的1,330種工具濫用手法（GTFOBins）裡，一成靜默通過，沒被系統攔下來提示人，在28,798個正常指令組成的語料庫裡，卻有將近九成被系統標記成沒辦法讓人看懂在核准什麼。這代表想堵住漏放的門檻，跟想讓系統好用，兩者互相拉扯，門檻拉得越緊，日常操作就變得越難用，作者自己也老實承認，這不是一個已經解決的問題，只是先把這個屬性和機制的問題提出來。

人工核准這件事，先放一邊

一個完整的判讀層系統，必要需要使用到人工核准與判讀，但我認為它只是整體設計裡的一小部分，不是這次要優先處理的方向。先把控制流合法性和動態權限這兩塊做扎實，人核准要怎麼設計、要不要引入trusted renderer這類機制，留給之後再談，但我們必須將此事設為可變因素，並且確切在未來思考如何解決。

五篇放在一起看

讀了好多論文，稍微整理成一張表：

資料來源：本文自行整理

CaMeL的capability政策、ControlValve的CFG、CXI的政策物件，三者都在規劃階段或政策階段就定好了，執行期不會因為「已經發生過什麼」而改變，這是我們動態權限縮減的立足點。而三套機制一起使用不代表縫隙補完，因為設計時沒考慮過要跟彼此合成，因此我們在此部分需多方考量如何進行。在工具信任與人工核准上，也透過兩篇確認這會是個問題，但我們在這30天的Demo中因為時間因素，必須先把這兩塊排除在30天範圍內，幫助完善整個架構Demo的範圍與可信度。

下一步

接下來鎖定一個具體的CaMeL任務失敗案例，判斷在我們實際執行實作時可能會遇到的問題，作為系統設計與實作的驗證標的。

參考資料

• Qu, Xu, Wang, Zhai, Zhang, Song, Securing LLM Agents Need Intent-to-Execution Integrity, arXiv:2605.16976
• Weng, What You Approve Is What Executes: Consent Integrity for Black-Box LLM Agents, arXiv:2606.02668
• MCPGuard: Automatically Detecting Vulnerabilities in MCP Servers, arXiv:2510.23673