前三篇依序談 Contract（合約）、Evidence（證據）與 Attestation（獨立確認）；本文聚焦信任鏈的最後一環：Authority（授權），以及如何依風險在 Human-in-the-loop 與 Human-on-the-loop 之間配置人的決策位置。本文可以獨立閱讀。
前言
先從一個常被混淆的問題開始：所有必要檢查都通過、審查也完成了，是不是就等於可以合併、發布或上線？
前一篇已經把驗收和獨立確認分開。Evidence 回答「在已定義的檢查條件下，結果是否符合預期」；Attestation 則由與產出角色分離的審查者或審查機制，判斷這些證據是否足以支撐受治理需求。Authority 要回答的是另一個問題：誰有權依照什麼規則，做出合併、發布、部署或正式放行的決定？
因此，檢查通過與審查完成，不會自動產生放行權限。若把「驗收結果」直接當成「授權結果」，責任邊界就會被綁在檢查的完備性上；而任何檢查都不可能覆蓋所有情境。
commit、push 與放行是不同的授權動作
授權分離的重點是：
commit、push、merge、publish 與 deploy 是不同動作；完成前一個動作，不會自動取得下一個動作的 Authority。
在許多流程裡，這些動作可能被串成一條自動化路徑：push 之後執行 CI，CI 通過後自動 merge，再由部署流程發布。自動化本身不是問題，問題在於每一個放行動作是否都有明確的治理規則、適用範圍與授權來源。
放到 agent 的工作流程裡，可以先分清楚幾件事：
- agent 可以在授權範圍內建立 commit 或 push 變更，但這只代表版本被提出或送進流程，不代表需求已經被核准。
- Evidence 與 Attestation 都完整，也不代表自動取得 merge、publish 或 deploy 的權限。
- merge、publish 與 deploy 可以由人類明確決定，也可以由事先核准的政策自動串接；前提是每一步的放行條件與授權來源，都已經由治理規則明確定義。
每一個放行結果都應該能回到一條清楚的授權規則，而不是前一步流程的無條件延伸。
薄介面：入口不能偷偷升級授權
現代的 agent 工具通常會用不同入口操作同一套流程：命令列（CLI）、給 agent 使用的 MCP、CI 的 adapter，或其他內部服務。如果每個介面各自實作一套授權規則，規則就可能逐漸漂移：某個入口多開了一個操作，另一個入口的把關又比其他地方寬鬆。
比較實務的做法，是把這些介面維持成薄介面：負責解析輸入、基本格式驗證、authentication / scope 檢查、呼叫共用的治理邏輯，再把結果格式化輸出。真正涉及敏感操作的 authorization，仍應在共用的受治理路徑中重新確認。
多加一個介面，可以多一個入口，但不應因此多出一份 Authority。
CLI、MCP 或 CI adapter 都可以有自己的 authentication、authorization 或 scope 檢查，但不能自行擴大底層已授予的權限。能呼叫某個 tool，不等於有權執行底層的敏感動作。
這樣設計的重點，不是把所有 authorization 都放進單一中央元件，而是避免不同入口各自發展出互相矛盾的權限規則。入口會增加，工具會更換；CLI、MCP、CI adapter 或其他內部服務仍應回到可追蹤的共用治理路徑，降低實作錯誤造成權限擴大的機會。
誰來決定？授權方式取決於風險
治理不代表每一個變更都要經過同樣嚴格的流程。比較實務的做法，是先評估變更的風險，再決定由誰、在什麼條件下取得放行權限。
- 低風險、可恢復且規則清楚的變更：例如文件、排版或已經被政策清楚界定的維護工作，可以在必要的 Evidence 與 Attestation 完成後，由事先核准的政策自動放行。
- 高風險、不可逆或影響範圍較大的變更：例如 public API、資料 migration、權限、安全性或正式環境行為，通常需要指定角色進行更明確的授權判斷。
這裡的重點不是把所有工作分成固定幾級，而是讓治理強度和實際風險對得上。風險可以往上調高，但不能在沒有理由的情況下偷偷調低；如果 agent 執行過程中讓任務範圍擴大，就應重新評估，必要時改用更嚴格的放行條件。
例如，同一個 coding agent 可以被允許建立 branch、commit 與 PR。若只是文件修改，CI 與既定檢查通過、必要的 Evidence 與 Attestation 完成後，可以依事先核准的政策自動 merge；但只要變更涉及權限模組、資料 migration 或 production deployment，就切換到需要指定人員核准的流程。Agent 的能力沒有改變，改變的是這次操作被授予的 Authority。
Authority 可以被委派給明確指定的角色或執行主體，而授權政策則定義這些權限在什麼條件、範圍與風險情境下可以被使用。自動化流程只能在這些規則界定的範圍內執行被授予的權限。授權依據、適用範圍與每次放行結果都必須可以追溯。
把人放在對的位置：從 Human-in-the-loop 到 Human-on-the-loop
當 agent 的數量與產出速度提高，逐行 Code Review 正在成為專案交付的瓶頸。人類很難用原本的方式逐一讀完所有變更，卻不代表授權邊界可以被拿掉。
這裡用 Human-in-the-loop 與 Human-on-the-loop 描述兩種可以共存的授權位置。這不是要用 Human-on-the-loop 全面取代 Human-in-the-loop，而是依風險，把人的注意力留在真正需要人工決策的位置：
- Human-in-the-loop（人在迴圈裡）：人類在被治理規則指定、需要人工決策的關鍵節點做出明確決定，適合高風險、不可逆或需要處理例外的情境，但不等於逐行看完所有 code。人類可以依照合約、Evidence、Attestation 與例外資訊，專注判斷需求、風險與是否放行。
- Human-on-the-loop（HOTL）：系統可以在既定政策內自主執行，人類則負責政策、監督、例外與介入。低風險、可恢復且規則清楚的工作，可以更多採用這種方式；但人仍需要看到足夠的狀態與例外資訊，並保有暫停流程、撤銷權限、人工介入或切回人工核准的能力。
這裡所謂「上移」，指的是人的決策與監督位置上移，而不是所有操作權限都往上集中。實際執行所需的 Authority，反而可能在治理規則界定下被委派給自動化流程。
Human-on-the-loop 不只是事先寫好政策後就離開流程。政策自動放行所使用的 Authority，仍然來自事先由有權限的主體確認過的規則；自動化流程只是依照這些規則執行，人仍必須能在風險條件改變時介入處理。
這也是前面三篇建立的基礎：Contract 固定要做什麼，Evidence 記錄在定義條件下的可重現結果，Attestation 確認證據是否足以支撐需求。這些資訊越清楚，人類才越能把注意力從每一行 code，移到政策與例外，而不是把放行權交給一個沒有明確來源的自動判斷。
自動放行前，還需要處理的治理問題
Human-on-the-loop 是把部分放行工作交給既定政策執行，不是把責任交給自動化之後就結束。在把更多放行工作交給政策與編排流程之前，至少要先處理幾個問題：
- 責任歸屬：政策自動放行出了問題，誰負責維護政策、檢視紀錄與處理後續？
- 合規：這樣的自動化是否符合稽核、法規與組織內部的要求？
- 撤銷與介入：政策已授權 agent 自動執行後，如果風險條件改變、存取憑證外洩或行為超出預期，誰可以暫停流程、撤銷權限，或強制切回人工核准？
- 授權模型：政策由誰制定、誰有權修改？政策本身的變更，是否也有清楚的確認與追蹤紀錄？
這些問題還沒有答案之前，不適合只因為自動化看起來有效，就把人類移出所有關鍵放行點。先把底層的版本、證據、獨立確認與授權紀錄做好，再依風險把適合的決定交給政策執行。
小結
這篇談的是信任鏈第四個、也是最後一個支柱：Authority（授權）。
- Contract（合約）：固定這次工作要做什麼、哪些事情不在範圍內，以及後續要對照的版本基準。
- Evidence（證據）：由可重現的檢查產出，綁定實際被驗收的版本與執行條件。
- Attestation（獨立確認）：由與產出角色分離的審查者或審查機制，判斷 Evidence 是否足以支撐受治理需求。
- Authority（授權）：決定誰或哪一套經核准的政策，有權 merge、publish、deploy 或正式放行。
Trust is a chain, not a prompt. 授權邊界不會消失，只會上移。
人類掌舵，Agent 執行；而哪些事情可以交給 Agent 執行，仍然要由清楚的 Authority 決定。