前言

今天要跑的是全suite的主數字，workspace全部40個任務、banking全部16個任務，不開攻擊，看這套機制在完整樣本上的誤殺代價與觸發率。

先看過程中不合理的數字

banking掉了四分之一，十六個任務裡少完成四個，前面幾天測過的任務裡，新設計最多就是跟基準持平或差一格，不曾出現這種規模的落差。

翻執行紀錄，基準組一次都沒拒絕過

把兩組的政策拒絕次數拉出來對：

基準組在十六個任務裡一次都沒有拒絕過任何呼叫，更可疑的是新權限格那八次拒絕，理由長這樣：

The recipient does not come directly from the user.
The recipients can't read the transaction amount: amount readers=frozenset({'me'})

第一句是CaMeL原本send_money政策的訊息，第二句是原本的可讀者檢查，八次裡只有一次的理由來自我加的那一層，也就是說，基準組根本沒有政策引擎可以拒絕任何東西。

根因

去看管線怎麼組起來的：

# Adaptive tightening needs real policies to tighten: without them
# nothing is ever denied and there is nothing to replan around.
engine if adaptive else ADNoSecurityPolicyEngine,

沒有開啟動態權限的時候，掛上去的是ADNoSecurityPolicyEngine。那個類別的內容是空的政策清單：

self.policies = []
self.no_side_effect_tools = set()

動態收權限需要有政策才收得動，但我沿用它當基準組，等於把「完全沒有政策」當成了「靜態政策」。

所以我量錯了什麼

從Day21排消融階梯開始，每一組A對D的對照都是這個組合：

這解釋了基準組的utility為什麼總是比較高：沒有政策就沒有任何拒絕，任務當然更容易完成。CaMeL的防禦有兩層，政策引擎只是第二層；第一層的隔離區與能力追蹤本身就擋住了注入。拿掉政策，注入還是進不來，所以攻擊成功率一直是0.0，連基準組也是，。防禦不是政策層給的。過程中新設計看起來一直在扣分，
因為被拿來比的那一組不用付任何安全成本。

正確的基準是存在的，而且不用額度

程式裡本來就有一條真正掛政策的路，名稱是+camel+secpol，它的做法是重放已經記錄下來的程式碼，把政策引擎套上去重新判斷一次，過程中不呼叫模型。

換成正確基準之後，結論反過來

動態權限在兩個suite上都高於靜態政策，workspace多完成四個任務，banking多完成一個，原本看起來像「新設計讓utility掉了0.075與0.25」，實際上是「靜態政策讓utility掉了0.175與0.312，新設計把其中一部分救回來」。

贏的是權限判斷還是重擬

動態權限那一組同時有兩件事在作用，換了權限判斷以及被擋之後可以重新規劃。贏的那些是哪一件的功勞，表面上看不出來，重放的程式碼是固定的，模型沒有機會重新規劃，所以把動態權限判斷套到重放上，得到的就是「只有權限判斷、沒有重擬」那一組：

workspace上兩者各出一半，權限判斷把0.625拉到0.675，有界重擬再拉到0.725，各兩個任務。banking上權限判斷完全沒有貢獻。0.375對0.375，一格都沒動，拒絕次數也是九次對九次。那0.062全部來自重擬。這個設計相當於「被擋下來之後不要放棄」，不是權限格本身有多聰明。

從九次裡大部分是轉帳的收件人判斷與可讀者檢查來看為什麼banking會這樣，而重放的程式碼是無政策組產生的——那一組跑的時候沒有任何拒絕，所以模型從來沒有理由去寫一個「能通過檢查」的版本。

重擬不只是補救手段，它本身是讓權限判斷有機會發揮的前提。靜態政策沒有這個機制，所以它的代價不只是擋掉一些東西，而是擋掉之後就結束了。

救回來哪些工具

把兩組被拒絕的呼叫按工具分類：

workspace那邊，刪除檔案、寄信、附加檔案、加入參與者這四類拒絕全部消失了，banking那邊轉帳的拒絕從六次降到四次，能在完整任務集上看到修法確實減少了誤殺。

建立行程反而多拒絕了一次

同一張表裡，建立行程從四次變成五次。那是Day25修過的地方——參與者複製自既有行程的情況。Day25修掉的是其中一種形狀，看來還有另一種沒被涵蓋。

這格要留到之後追，不在今天改，因為Day28之後不再動設計。記下來比假裝沒看到重要。

小結

今天原本只是要跑一組主數字，比起結論反轉，更值得記的是發現的過程，因為banking掉0.25這個幅度不合理，追下去才挖到的，Day13把攻擊成功率讀成防禦率、Day19發現測試流程污染、今天發現基準組沒有政策，三次都是同一種模式——數字看起來怪，追下去發現評估設計本身有問題。

補上正確基準之後把「只有權限判斷、沒有重擬」那一組也跑了，結果顯示banking上的全部收穫都來自重擬，權限判斷一格都沒貢獻，這幾天的力氣大多花在權限判斷的細節上——四個洞、一條判斷線、三條不變式，被擋之後不要放棄這件事，至少一樣重要。

明天見

最後了，把機制怎麼運作、四個洞補在哪裡、必須維持的不變式是什麼、改過的設計與原因。