假設一張值班工單只允許處理測試環境，Agent 提出的工具參數卻指向正式資料庫。使用者已登入，Gateway 也允許呼叫這個工具，請求一路正常送到後端。這時仍需要有人或某個控制看出：呼叫者有身分，工具有入口，這次目標卻超出工單範圍。

這是上線前的設計審查情境，不是已發生的公司事故。我想用它釐清一個容易藏在架構圖裡的問題：平台維護認證和路由，誰定義資料庫可修改的條件？需要人工批准時，誰有權批准？真正改動後，又由誰判斷影響？

系列最初的安全 Lab 提供了這個問題的起點。模型從不可信 Log 提出 delete_demo_database，Open Policy 按設定回 ALLOW，Tool 也照實作留下 no-op Canary。控制沒有當掉，但規則沒有比較原始調查任務與危險動作。本篇接著把規則、維護和單次決定分回具體角色。

身分、技術權限與業務條件

先看已登入的值班工程師。Token 驗證能確認憑證由可信來源簽發、用在預期服務、仍在有效時間內。這提供了請求者身分的依據，還沒有回答他是否能修改這個資料庫。

Gateway 可以再檢查共同規則，例如這個角色能不能走工具 Route，呼叫是否符合平台政策。這些規則讓入口的接受範圍可維護，但「工單只允許測試環境」需要取得工單和目標的可信資料，通常由理解資源語意的應用或後端實作。

資料或服務 Owner 則定義哪些修改可接受，例如允許環境、變更時段、資源範圍與必要的批准。這些條件有些能寫成程式檢查，有些需要具名的人根據影響作決定。業務意圖不應只存在模型對工單的摘要裡，能確定的條件應轉成可驗證的授權輸入。

如果把這三種判斷都壓成 authorized=true，事件裡就看不出哪一層通過什麼。比較容易調查的做法，是分開保存身分確認、入口決策和資源授權，再用同一個操作 ID 關聯。

控制維護者與決策負責人

Control Owner 維護檢查如何執行。控制服務故障、版本升級或拒絕結果不如預期時，由他處理。Decision Owner 則定義規則或批准單次操作，知道哪種影響可以接受。兩個角色可以由同一團隊擔任，責任仍需要分開記錄。

例如資料庫 Owner 決定正式環境修改需要哪些條件，應用團隊把工單環境和工具目標的比較寫進授權檢查。檢查漏判是實作問題，規則需要例外則是決策問題。值班的人要知道兩種情況各找誰，不能只看到一個模糊的 Platform Owner。

這裡的 Business Owner 是能替目標資源或流程決定變更、判讀影響和接受剩餘風險的人。服務變更可能是 Service Owner，資料操作可能是 Data Owner，部署則可能有指定的 Change Owner。角色名稱要回到實際權限，不能只填最高階主管。

下圖沿同一筆動作走過五站。每站分開列維護者、決策者和交出的證據，閱讀時特別看工單與正式環境的差異在哪裡被檢查。

一筆請求如何交接五個決策點

第一站由身分系統確認 Caller，入口取得可信的主體、Token 用途與有效期。第二站由 Gateway 套用共同政策，記錄 Route、規則版本與接受或拒絕原因。這兩站在本例都可能正常通過，因為使用者身分和工具入口本來就有效。

第三站需要對照工單與目標資源。Application 或 Resource Server 確認工單只允許測試環境，而參數指向正式環境，就應在執行前拒絕。若只驗工具名稱或字串格式，仍可能接受一份格式正確、範圍錯誤的參數。

第四站只在流程需要人工決定時出現。有權批准的人需要看到已固定的目標、參數、版本和影響範圍，再留下具體決定。第五站由資源服務確認執行結果，應用整理技術狀態，資源或業務 Owner 判讀影響並決定後續處置。

這份表應按組織實際分工填寫。關鍵是下一站收到的資料，真的對應同一筆操作。Application 不能拿別張工單授權，Runtime 也不能在批准後換掉目標，最後的結果則不能借用另一個工具的成功狀態。

Production Responsibility Contract 提供完整欄位與空白模板。它固定來源、目的、工具、資源、參數摘要、執行版本與規則，再填負責人、交接資料和升級路徑。附檔的已填範例只使用 Day 1／26 的安全歷史證據，缺失值仍是 UNKNOWN，與本文假設的正式資料庫操作分開。

人工批准如何綁住待執行內容

HITL，也就是 Human-in-the-loop，可以讓工作暫停等待人的決定。對高風險工具來說，批准畫面要讓人知道即將改哪個資源、使用哪些參數，以及可能造成什麼影響。只有 Approve 按鈕，仍不足以確認決定涵蓋哪筆動作。

可用的批准證據會記下批准者身分與權限，並綁定工具、目標、正規化參數、Agent 產物、Policy Version 和有效期。這些內容可以形成 Action Digest，作為固定動作的摘要。摘要需要明確的欄位和正規化方法，不能只對模型寫的一段自然語言說明計算 Hash。

例如批准時是測試資料庫和 Digest A，Resume 前變成正式資料庫和 Digest B，原批准就不應繼續使用。應用回到授權流程，重新決定是否接受這個新動作。批准過期或 Resume ID 被重複使用時，也需要有明確處理。

下圖表示這份設計要求。沿上方看批准和執行內容一致的分支，再看目標或參數改變後如何回到拒絕或重新批准。

Day 18 已跑過相容 BYO 路徑的 Pause／Resume，Approve 和 Reject 保持相同 Task ID、Context ID，Reject 不執行工具。它還沒有驗證正式批准者認證、批准權限和完整 Digest 綁定，因此不能把本文設計當成已完成的產品整合。

平台可以提供暫停、通知、UI 和收據傳遞。Application 要確認恢復時內容沒被替換，批准者則決定這次影響是否接受。這個分工讓人的決定有實際執行邊界，不會只留在畫面上。

執行結果與事故處理

工具收到允許後，仍可能執行失敗、只完成一部分，或產生超出預期的結果。資源服務需要留下它能確認的效果，例如修改數量、Resource Revision 或後端收據。Application 再將這份結果和原本的操作關聯，讓使用者知道工作完成到哪裡。

若放行後遲遲沒有收據，調查應先查工具端和管線，而不是直接重送有副作用的動作。是否能重試，取決於資源操作的冪等性與已知狀態。結果超出批准範圍時，則要有明確接手人處理停止、回復或補償。

這些處置不需要全部放進單一 Gateway。平台維護關聯與運行觀測，Application 和 Resource Server 提供正確結果，業務 Owner 判讀影響。既有 LGTM 可以支援這條調查路徑，保存要求則由目的另行決定。

保存要求與剩餘風險

Operational Telemetry 支援值班和效能排查，Audit 保存則可能需要不同的事件範圍、存取權限與保存期限。若有防刪改、Legal Hold 或其他正式要求，要由對應角色確認，不能只拉長 Loki Retention 就宣稱完成。

兩種用途可以共用 Action ID、Trace ID 和事件欄位，但不必共用全部讀取角色。能看服務錯誤率的人，不一定需要查看單一人的高風險操作。Security／Risk 定義保存目的，平台協助實作，資源 Owner 提供影響判讀。

剩餘風險也要具體到會改變決策的缺口。本例若還無法比對工單和正式目標，就沒有足夠控制開放正式資料庫。若這一點已補齊，但批准者身分或執行版本仍未驗證，就由有權接受影響的人決定能否在特定範圍試行，並留下重驗條件。

Residual Risk Register 收錄本系列已有來源的缺口、負責人與關閉條件。NIST AI RMF 1.0 的 Govern 也將角色、責任和溝通路徑放在組織層級。本文契約是作者以單一動作整理的設計工具，並非 NIST 的官方表格。

用具體操作進行設計審查

審查時可以先拿一筆會改資料的請求，讓工單目標和工具參數故意不同，檢查哪個控制拒絕。再看批准後換參數、批准過期和重複 Resume 如何處理，最後確認結果能否對回原操作。這些是上線前的驗證建議，不是本篇新增的 Lab 結果。

每個結果都連同控制維護者與決策負責人保存，下一次規則或工具變更，才知道誰要重驗。責任交接的價值，是讓系統運作、規則改變和事故處理各有清楚入口。

最後一天會把這些接縫放回整體架構，回看系列開頭的危險工具提議：它在碰到資源以前應遇到什麼控制，事後又能沿哪些資料查證。