Day 13 讓我多注意到關於legitimacy_reference的可討論問題。
執行環境要判斷一個工具呼叫能不能執行的時候，手上除了使用者、工具、參數、來源這些資訊之外，還缺一件事：這次執行到底要拿什麼標準來判斷？
如果只看單一工具呼叫，執行環境可以檢查權限、參數或資料來源。但當問題變成「這一連串工具呼叫組合起來是否符合預期」，判斷對象就從單一動作變成了整條執行路徑，問題也跟著變成：
執行環境要根據什麼參照標準，判斷這條執行路徑是否符合要求？
「整條執行路徑」這個詞很容易被理解成「授權做完之後，再另外加一層監控」，但這兩件事並不是同一件事。UCON（Usage Control）早就處理過持續授權的問題：資源使用期間，授權條件可以隨狀態改變，執行環境也可以重新檢查授權條件。ABAC（Attribute-Based Access Control）同樣可以根據主體、資源、動作與環境屬性進行判斷。
所以需要區分的不是「授權」和「監控」，而是執行環境正在判斷什麼對象。例如：
單一動作：
Agent → 查詢訂單 → 是否允許？
連續動作：
Agent → 查詢訂單 → 修改地址 → 匯出資料 → 是否符合允許的執行流程？
第一種判斷的是單一動作，第二種判斷的是一串動作之間的關係。判斷對象一旦變成整條執行路徑，執行環境就不能只看每個動作個別是否被允許，還必須知道哪些動作可以接在一起、哪些狀態可以轉換，以及目前的執行狀態是否允許下一步發生。
例如一個訂單流程可能被描述成：
等待付款 → 付款完成 → 要求出貨 → 已完成
如果目前狀態是「等待付款」，Agent 卻直接從「等待付款」進入「要求出貨」，即使「要求出貨」這個工具本身具有有效權限，整條執行路徑仍然可能不符合流程。執行環境在這裡問的已經不只是「這個工具能不能用」，還包括「這個工具現在能不能出現在這個位置」。而執行環境一旦開始判斷狀態與轉換，就必須先定義什麼樣的狀態轉換可以接受，這正是 legitimacy_reference 真正碰到的問題。
「符合要求」本身沒有明確意義，執行環境必須先取得一份參照標準，再把實際執行路徑拿來和這份標準比較。而參照標準可以有很多種。
最直接的方式，是讓執行環境根據已經定義好的政策判斷，例如：
這種方法的優點是規則明確，判斷結果通常也具有可解釋性。但政策只能判斷「規則有沒有被違反」，如果某種攻擊沒有直接違反任何單一規則，執行環境仍然可能放行。例如：
查詢公開資料
→ 讀取內部文件
→ 將兩份資料合併
→ 呼叫外部分析工具
假設每個動作都符合既有政策，政策檢查可能全部通過，但這串動作組合起來，仍然可能形成一條不應該出現的資料流。因此「符合政策」只能代表執行路徑符合目前已經寫下來的規則，不能直接代表執行路徑安全。
第二種參照不是逐條檢查政策，而是先定義允許的執行流程，例如：
建立訂單 → 付款 → 確認付款 → 出貨
執行環境可以要求 Agent 按照這個流程推進。如果 Agent 在「建立訂單」之後直接要求「出貨」，即使 Agent 擁有出貨工具的使用權限，執行環境仍然可以拒絕這次動作，因為目前狀態沒有允許這個狀態轉換。這類問題與 security automata、conformance checking 所處理的概念相近：系統可以根據預先定義的狀態或流程模型，判斷實際執行軌跡是否符合允許的行為。
比起單純的權限檢查，這種方法更能處理「順序」問題，但流程模型本身可能不完整。如果實際任務存在一條合理、卻沒有事先被寫進流程模型的路徑，執行環境可能把這條路徑當成異常。所以「符合流程」代表的是「符合這份流程模型」，而不是「一定安全」。
第三種方式是使用歷史執行資料建立參照。假設一個客服 Agent 過去處理退款時，大多遵循：
查詢訂單 → 確認付款狀態 → 檢查退款條件 → 執行退款
如果某次執行突然變成：
查詢訂單 → 讀取大量客戶資料 → 建立外部檔案 → 傳送到第三方服務
即使這些動作個別沒有違反政策，執行環境仍然可以發現這條路徑明顯偏離過去的行為模式。這比較接近異常偵測，問題也很明顯：過去出現過的行為，不代表那些行為就是安全的。 如果歷史資料中本身存在錯誤、濫用或攻擊行為，系統學到的「正常」就可能把錯誤行為當成正常行為；反過來說，一條從未出現過的新路徑，也不一定代表攻擊。因此歷史行為比較適合作為偏離程度的參照，而不能直接當成安全標準。
最後一種參照，是從目前任務本身推導出預期的執行方向。例如使用者要求：
「整理這份報告，最後輸出摘要。」
Agent 可以讀取文件、整理內容、產生摘要。但如果執行過程逐漸變成：
讀取報告 → 搜尋其他帳戶 → 下載附件 → 建立外部連線 → 上傳資料
即使其中部分動作具有權限，這條執行路徑仍然已經偏離原本的任務目的，執行環境因此可以檢查後續動作是否仍然服務目前任務。政策與流程模型沒有明確描述的情況，這種方法能夠處理，代價則是任務本身可能沒有被正確理解，Agent 建立的計畫也可能從一開始就錯了。所以「符合任務目的」仍然是一種參照，不是安全性的同義詞。
把四種方法放在一起，可以看出它們判斷的對象並不相同。
| 參照標準 | 執行環境實際判斷的問題 | 主要用途 | 主要限制 |
|---|---|---|---|
| 政策標準 | 執行路徑有沒有違反明確規則？ | 政策強制 | 無法涵蓋沒有寫進政策的攻擊組合 |
| 流程模型 | 執行路徑有沒有偏離允許的流程？ | 流程控制 | 模型可能遺漏合理的新路徑 |
| 歷史行為 | 執行路徑有沒有偏離過去的行為模式？ | 異常偵測 | 過去行為本身可能不安全 |
| 任務目的 | 執行路徑是否仍然服務目前任務？ | 任務一致性檢查 | 任務或計畫本身可能錯誤 |
所以 legitimacy_reference 並不是單純在授權資料裡增加一個欄位而已。執行環境一旦真的使用這個欄位，就必須回答至少四個問題：
參照內容：什麼標準可以用來判斷？
參照來源：這份標準是誰建立的？
適用範圍：這份標準適用哪些任務與執行流程？
信任基礎：執行環境為什麼相信這份標準？
如果這四個問題沒有處理，legitimacy_reference 只是換了一個名稱的「判斷依據」。
看過前面四種參照之後，另一個問題會跟著出現：如果執行路徑符合其中一種參照，執行環境能不能直接把這條路徑視為安全？
答案不能直接這樣推論。政策標準只能告訴執行環境「這條路徑有沒有違反已經定義的規則」；流程模型只能告訴執行環境「這條路徑有沒有按照指定流程執行」；歷史行為只能告訴執行環境「這條路徑和過去的行為有多大差異」；任務目的則只能告訴執行環境「這些動作是否仍然和目前任務有關」。這些判斷結果的意義都不一樣。例如一條執行路徑可能完全符合歷史行為，但歷史行為本身就包含不安全的操作；另一條執行路徑可能偏離既有流程，卻是完成新型任務時必要的新路徑。
所以 Day 14 目前能得到的結論比較精確：
參照標準可以定義「符合什麼」，但不能單靠參照標準本身證明「一定安全」。
這個區分對後面的動態權限控制很重要。當執行環境發現一條路徑偏離參照時，後續要不要縮減權限，必須另外定義判斷結果和授權決策之間的關係。
實際系統很可能同時使用多種參照，例如某次 Agent 執行可能得到：
政策標準 → 符合
流程模型 → 不符合
歷史行為 → 符合
任務目的 → 不符合
這時候不能只說「多判斷幾次」，因為四個參照對同一條執行路徑產生了不同結果。如果政策判斷允許，但流程模型判斷拒絕，執行環境到底要不要放行？如果歷史行為認為這是正常路徑，但任務目的認為這個動作已經偏離任務，哪一個判斷應該優先？
這裡缺少的不是另一個參照標準，而是參照之間的衝突處理規則。例如系統可以明確定義：
政策禁止 → 一律拒絕
流程偏離 → 視風險重新授權
歷史偏離 → 記錄並提高風險分數
任務偏離 → 要求重新確認任務目的
這只是其中一種設計，重點在於執行環境必須知道不同判斷結果之間的優先順序，以及每種結果會如何影響後續執行。否則多個參照同時存在，只會讓授權結果變得更難預測。
前面處理的是「怎麼判斷」，但執行環境得到判斷結果之後，還有另一個問題：這個結果要不要直接影響 Agent 的下一個動作？
最直接的做法是阻擋。如果執行環境發現下一個工具呼叫會讓執行路徑偏離參照，執行環境可以直接拒絕這次工具呼叫。這種處理會立即影響 Agent 的控制流程，Agent 收到拒絕結果後，也可能重新規劃後續動作。另一種做法則是先記錄：執行環境可以把偏離事件、目前路徑與判斷結果留下來，暫時不阻止工具呼叫，保留更多執行彈性，但也代表部分動作可能在判斷結果產生後繼續執行。
因此，路徑判斷與控制決策應該分開看。Day 14 先處理的是前者：執行環境要有明確的參照，才能知道一條執行路徑偏離了什麼。至於偏離之後是否要拒絕、縮減權限或允許執行，則是下一層的控制問題。這也讓 legitimacy_reference 從一個看似單純的欄位，變成了後續動態授權設計必須處理的核心依賴。
Day 13 讓我開始注意到，授權資料裡多放一個 legitimacy_reference，並沒有真正解決「這條路徑能不能接受」的問題。執行環境如果要判斷整條執行路徑，就必須先決定自己拿哪一種參照來判斷。政策、流程、歷史行為和任務目的都可以成為參照，但每一種參照回答的問題不同，符合參照也不能直接等同於安全。
這讓我看到後面的動態權限控制還有一個更實際的問題：執行環境發現路徑偏離之後，到底應該怎麼改變 Agent 接下來能做的事情？而在回答這個問題之前，還得先確認執行環境使用的參照本身是否值得信任。
感謝大家今日份的閱讀。
source:
iThome鐵人賽
看影片追技術