D6：實作護欄與課責

D6-O1 定義自主程度

自主程度描述代理可以自行決定與推進到哪一步；權限描述它實際可以操作哪些資源。兩者必須一起設計。要求代理自主完成測試，不代表它需要管理員權限；給它 repository 寫入權，也不代表所有可執行的操作都在任務授權內。

以動作與資料判斷風險

不要只為整個代理貼上「安全」或「危險」標籤。同一代理讀取公開文件、在獨立工作目錄修改指定分支、查詢個人資料與發布正式服務，風險差異很大。唯讀也未必低風險：把敏感資料送往外部服務，雖未修改來源，仍可能造成不可撤回的揭露。

這張表是設計輔助，不是 GH-600 官方的固定等級名稱。自主程度還要符合組織的資料與責任規則，不能由代理為了加快進度自行提升。

匯出案例可以授權代理在獨立工作目錄、指定分支與測試資料上自動修正，並在測試失敗時自行調整；若驗證突然需要正式客戶資料，就到達新的資料邊界。應優先使用能重現問題的去識別化或合成資料；仍不足時，再由資料權責者決定可用範圍。

判斷練習： 團隊把每個檔案讀取都設為人工核准，卻讓發布工具預設自動執行。核准次數很多，是否代表控制充分？

解析： 核准次數不是風險控制的替代指標。應把人工注意力放在發布範圍、版本、影響與可回復性；對已授權、低風險的重複操作，可使用清楚邊界降低不必要摩擦。第一個問題是「哪個動作值得判斷」，不是「總共按了幾次確認」。

技能範圍：GH600-SG；產品責任與限制延伸閱讀：Responsible use of GitHub Copilot Agents（GH-DOC-21）。

D6-O2 實作護欄與人工介入

護欄要落在真正能限制行動的位置。文字指令能表達政策，工具權限與資源隔離能限制可用能力，執行前檢查能拒絕不符合規則的操作，分支規則與審查則控制交付路徑。每一層保護不同事情，不應讓單一提示承擔全部責任。

執行前與執行後檢查

GitHub hooks 提供 preToolUse 與 postToolUse 等事件。前者位於工具執行前，可用於權限決策；後者可用於記錄與檢查結果，但不能把已經完成的外部副作用變成「從未發生」。各執行環境支援的欄位與行為不同，必須依目標環境的官方參考實測，不應把 CLI 設定原封不動視為雲端行為。

若某項控制是必要防線，驗收時至少檢查三種輸入：允許的動作能執行、禁止的動作會被阻止、控制本身失敗時走向預定的停止或升級路徑。不能只驗證 hook 有被呼叫，就宣稱禁止規則有效。具體失敗策略應由工作流程定義，不能假設所有平台自動拒絕。

讓核准有可判斷的內容

一份有用的核准請求應說明要做什麼、作用在哪裡、依據哪個版本、已跑哪些檢查、可能造成什麼副作用，以及如何恢復。使用者同意發布特定版本後，若產物又被更改，原核准不應被當成新版本的通行證；需要重新核對差異是否仍在授權範圍。

例如 PR 已通過審查，但發布工作準備使用另一份未驗證產物，問題不在於少按一次確認，而在於核准對象與執行對象不一致。把 artifact、commit 與核准紀錄串起來，才能指出誰對哪一個變更負責。

判斷練習

情境： 執行後 hook 發現代理已刪除外部測試資料，於是把結果標為失敗。這是否足以證明刪除護欄有效？

解析： 它證明事後偵測有效，沒有證明動作被阻止。若政策要求禁止刪除，應在權限或執行前決策限制它，並用可拋棄資料驗證拒絕路徑。需要清理的資料則走有明確範圍的受控程序。

交付前自問： 能否指出需求、實際差異、受測版本、核准者與產物之間的關係？若其中一段只能靠「代理應該記得」，課責鏈仍有缺口。這也是整合章將六個領域重新串接的起點。

來源：GitHub Copilot hooks reference（GH-DOC-11，2026-09-22 核對）。技能範圍：GH600-SG；分支控制延伸閱讀：GH-DOC-14。