在前面幾天我們整理了CaMeL是管資料流，而ControlValve是管控制流，今天將進入研究CXI（Context-to-Execution Integrity），名字本身就幾乎是「判讀層」的另一種說法，比前兩篇都形式化，今天花多一點篇幅把它拆透，能夠很大幅度幫助後面設計判讀層時借用這些概念。

CXI管的四種東西

CXI定義了四個核心元件
1.Protected sink fields（受保護欄位）：會決定、授權、或參數化一個副作用的欄位，例如要呼叫的工具名稱、核准狀態、目標路徑。
2.Typed release（型別化釋放）：一座範圍極窄的授權橋樑，把一個候選值對照信任快照驗證過後，只授權給一個特定欄位。
3.Opaque data slots（不透明資料槽）：保留證據但不給權限，內容可以被存起來當紀錄，但如果之後又被丟進一個有副作用的地方，一樣要重新走一次授權，不會因為「之前存過」就自動放行。
4.Action manifest（行動清單）：一份綁定用的承諾物件，把行動摘要、信任快照、政策版本等資訊全部釘在一起，三種授權都要綁到同一份，才能執行。

像是一份CI log裡如果寫著一個檔案路徑，一個FilePath typed release可以把這個路徑授權給 arguments.file_path 這一個欄位，但同一份log，就算裡面寫著已核准，對 approval_state（核准狀態）這個欄位，完全沒有授權效力，文字說了什麼不重要，重要的是有沒有對應的授權管道。

三種授權，缺一不可

1.Field authority：受保護欄位只能來自信任政策或對應的typed release，原始的可寫內容不能直接填進去。
2.Exact-effect authorization：對於會產生實際內容的酬載（修補檔、SQL、shell指令），系統綁定的不是文字長什麼樣，而是在信任快照下實際會產生的效果，驗證器授權過什麼效果，執行時就只會套用那個精確效果，一個字都不能多。
3.Invocation authority：呼叫這個動作本身，需要一個綁定manifest的capability，執行前會先被消費掉，用過一次就不能重複用。

三者必須同時綁定到同一份action manifest，任何一點竄改都會讓摘要對不上，執行直接失敗。

Invocation authority這一步是使用到的lease（租約）概念，在三種授權都通過之後，系統不是直接放行執行，而是先發一張租約，這張租約才是真正拿去執行的憑證，而且租約是消費型的，用過一次就作廢，不能拿同一張租約重複觸發同一個動作兩次，這個設計擋能擋住重放攻擊，就算攻擊者想辦法截到了一次合法的授權紀錄，想要拿去重放、重複觸發同一個危險動作，租約用過即焚的特性讓這招失效。這個概念在傳統資安裡也不是新東西，跟一次性密碼、防止交易被重複送出的冪等金鑰是同一種思路，CXI把它套進了agent的執行流程裡。

判讀層的六個步驟

任何一步失敗，都在執行前就被擋下，保證在不對時就能停止。

資料來源：本文自行整理

一句話講完它的立場

論文原句：「the gate classifies authority, not text intent」，判讀層分類的是權限，不是文字意圖。這跟Day 5、Day 6從ControlValve案例歸納出的判斷是同種方向，CaMeL靠資料來源標記、ControlValve靠控制流圖、CXI靠三重授權綁定，三者都是把「這聽起來合不合理」的語意判斷，換成「這有沒有被授權」的結構判斷。

Exact-effect authorization，擋「文字對，效果不對」

三種授權裡，exact-effect authorization這一項擋的攻擊手法特別細緻，假設一個修補檔（patch）工具，驗證器授權的是把某個設定值從A改成B這個具體效果，如果只檢查呼叫這個工具的文字內容看起來合不合理，攻擊者有機會生成一段文字上看起來完全合理、實際套用到系統上卻造成不同效果的酬載，例如修補檔的文字敘述寫著改A到B，但實際的diff內容裡多夾帶了一行看起來無關緊要、卻會造成額外副作用的改動。CXI的做法是不管文字寫了什麼，直接綁定在信任快照下，這個動作實際會產生的效果，執行時只允許套用驗證器當初授權過的那個精確效果，酬載的文字敘述本身完全不是判斷依據。

模型還是會亂來，但不影響

論文測了三種不同壓力的情境，結果都不好看，在判讀層真正擋下來之前，一般的utility對抗情境下，196/300次提案未授權；拉高壓力之後，407/522次；換成hosted／API的對抗情境，也還有85/400次，底層模型自己提出未授權提案的比例在對抗情境下最高到407/522，三個情境的比例雖然不同，但方向完全一致，模型完全沒有變乖，它一直在嘗試做不該做的事，但因為判讀層不信任模型的行為，只信任綁定manifest的授權鏈，最後執行層級的逃脫次數還是0，這呼應整個系列一路走來的方向，不指望模型被騙了還能自己收手，指望的是最後那道關卡能夠擋住。

Opaque data slot設計補足Day 2留下的疑點

Day 2讀CaMeL的時候，留了一個疑點沒解決，就是不受信任的內容被拿去當證據存起來，之後又被傳進另一個有副作用的地方，capability標記還跟不跟得上？CXI的opaque data slot某種程度上是把這個問題講得更清楚的版本，明確規定證據可以被保存進一個宣告過的欄位，但這份保存下來的內容，一旦要被傳進任何有副作用能力的地方，就得重新走一次完整的授權流程，不會因為它先前已經被存進某個證據欄位而享有豁免。這代表CXI是將保存跟授權徹底切開處理，保存這個動作本身不授予任何權限，權限永遠要在真正要被使用的那一刻，重新驗證一次，這個設計思路，剛好補上了Day 2那個疑點，資料被摘要、被搬移、被存放，不管中間經過幾手，只要最後要流向危險動作，就一定會被重新攔下來檢查，不存在洗白的問題與空間。

讀完三篇，我們的位置在哪

CaMeL、ControlValve、CXI三篇，各自用不同的機制做到結構取代語意，但三者管的都是「這個動作，此時此刻，有沒有被授權」，CaMeL管的是「這筆資料能不能流到這個動作」；ControlValve管的是「下一步能不能呼叫這個對象」；CXI管的是「這個欄位、這個效果、這次呼叫，三者是不是同時被授權」，是三者裡切得最細的一個。三篇的檢查時機也不一樣，CaMeL在工具呼叫當下、ControlValve在agent轉移當下、CXI則是把整個流程拆成標準化、驗證、授權、消費、執行五個步驟，每一步都可能被擋下，不是單一時間點的一次性檢查。沒有一篇讓「這次授權會不會通過」這件事隨著執行過程中動態變化。

這正是我們認為動態權限縮減有價值的地方：不是重新發明一套授權機制去跟CXI的三重綁定競爭，而是讓授權的範圍本身，會因為agent已經讀過多少不受信任的內容、已經觸發過幾次可疑但沒被擋下的邊界情況，逐步收緊。CXI回答了「這個欄位這一刻該不該被信任」，但沒有回答「經過了這些事之後，這個agent接下來還配不配擁有跟一開始一樣寬的權限」，接下來往動態權限就是我們要具體設計的。

下一步

三篇核心論文都拆完了，下一篇要把視野再打開一點，快速掃過幾篇處理相近問題的鄰近研究，確認站穩的位置不只是巧合，而是這整個領域正在收斂的方向。

參考資料

• Santos-Grueiro, Context-to-Execution Integrity for LLM Agents, arXiv:2607.06000