前言

「讓Agent邊讀邊決定」是我最初的目標，和現在所做出來的東西跟當初想的不太一樣，在過程中也發現很多有價值的思考點。今天分四段整理做了什麼、驗證到什麼、沒驗證到什麼、方法上學到什麼。

一、做了什麼

我的主要設計就是在CaMeL的兩層防禦之上，加了一層會隨執行過程改變的權限判斷。

訊號來自直譯器自己的能力標籤與政策引擎的拒絕紀錄，不問模型，三種訊號累積成分數，分數決定三個等級。

權限格依等級決定什麼可以替一個呼叫背書，乾淨層接受使用者授權範圍或可讀者檢查，可疑層只剩可讀者檢查，已被操縱層全部拒絕。乾淨層刻意比靜態政策寬，因為單純疊在靜態政策上的一層，結構上只能扣分。

有界重擬讓被擋下來的呼叫有第二次機會，但限制總次數、單一工具的拒絕次數，並偵測繞道。

二、驗證到什麼

四個靜態政策的缺陷，每一個都能確定性重現。

這四項不依賴模型抽樣，有回歸測試驗證，任何人拿CaMeL原始碼都能驗證。

在完整任務集上，動態權限把靜態政策擋掉的一部分工作救回來。

貢獻來自workspace上權限判斷與重擬各出一半；banking上權限判斷一格都沒動，全部來自重擬。

三、沒驗證到什麼

防禦率沒有改善空間：攻擊成功率在所有測過的組合一律是0.0，包含完全沒有政策的那一組，CaMeL的防禦有兩層，擋住注入的是第一層的隔離區與能力追蹤，政策引擎不是，所以這個研究從頭到尾量不到防禦的改善，因為在這個benchmark上沒有東西可以改善。

核心的新穎主張沒有量到：相對於Progent，這個設計的差別在「有界」，不讓被擋下來的模型無限試探，避免政策引擎變成可以反覆查詢的預言機，這個主張到最後只有設計論述，沒有數字。

自己造出來的攻擊面沒有量。 等級會升就代表可以被惡意推升，推到已被操縱之後使用者的正常工作會被擋。成本多少沒測過。

四、方法上學到什麼

**評估設計出錯三次，每一次都是數字看起來怪才挖出來的。**Day13把攻擊成功率讀成防禦率，以為CaMeL被打穿，其實被打穿的是utility。Day19發現測試流程本身在污染結果，有個參數型別會讓其中一組崩潰而另一組不會，而且我以為存在的旗標根本不存在，所謂的基準組其實包含我的修改。Day27發現基準組沒掛政策。

三次模式的數字幅度不合理，研究才發現問題不在被測的東西，在測量的方式。

基準組沒掛政策這件事，在單一任務的對照上一直表現為一兩格的差距，看起來像正常的抽樣波動，小樣本藏得住測量錯誤，大樣本藏不住 。直到banking十六個任務掉了四格，幅度大到不能用雜訊解釋，才讓我知道該翻執行紀錄。

四個修法每一個都有手寫情境證明有效，但手寫情境只涵蓋想得到的情況 ，誤殺檢查另外抓出兩個誰都沒想到的邊界情況，因為它們需要很具體的任務形狀才會出現。

AgentDojo在這兩個suite上沒有安全餘裕，而且符合這套機制形狀的任務只有八分之一，這件事應該在第一週看論文時就想清楚並在實作時做出相對應的處理，而不是在第二十六天算成本的時候才發現。

小結

所以說這次30天最後整理，做了一份對CaMeL政策層的缺陷分析，一套完整的動態權限實作，以及一個還沒被驗證的主張。

明天見

談接下來能往哪走，以及為什麼換一個評估場域是繼續做下去的前提，而不只是延伸選項，從更新的研究方向去統整目前所嘗試的方向。