GitHub 於 2026 年 9 月 9 日宣布 enterprise-managed permissions for GitHub Copilot agent operations，對象是 Copilot Business 和 Enterprise 管理員。它把 agent 的操作權限由個別開發者的提示和每次對話設定，提升到企業政策層：管理員可以集中決定某類操作要被封鎖、要先取得人手批准，還是可以在符合條件時繼續。
現時涵蓋的範圍很實際，包括 shell commands、讀取或編輯檔案，以及連接哪些 network domains。這三類權限正好對應 coding agent 最常見的外部影響面：執行命令可能改變環境，檔案操作可能修改程式碼或讀取敏感內容，網絡存取則可能把資料送到外部服務。把它們拆開設定，比一個籠統的「允許 agent」開關更接近企業需要的風險分級。
GitHub 特別強調，enterprise policy 不能被較低層級的 user 或 workspace settings、auto-approval，或者已保存的 approval 放寬。這個優先順序很重要：如果一家公司規定某個外部網域不可連接，使用者不能單靠工作區設定或記住一次批准，就把限制推翻。政策因此成為不可向下削弱的最低安全線，而不是另一個會和個人偏好互相競爭的提示選項。
管理員亦可以為不同 enterprise team 設計專門政策。開發環境、CI 維護、資料工程和高敏感度程式碼庫的工作，需要的批准節奏未必相同。分隊設定讓企業可以按照 repository、團隊和任務風險調整權限，而不用把最嚴格的規則套在所有人身上。當然，政策越細，測試和版本管理的要求也越高，否則團隊會難以知道哪條規則實際生效。
這項功能已在 GitHub Copilot app、Copilot CLI，以及使用 Agent Host 的 Visual Studio Code session 一般可用。這個範圍顯示 GitHub 正把 agent 治理放到不同操作介面的共同控制面，但不代表所有 AI coding agent 或所有 IDE 都會自動受到同一套政策保護。企業仍要核對自己使用的客戶端、Agent Host、方案和政策文件，再決定哪些流程已經納入管理。
從工程治理角度看，這次更新把「人手批准」重新定義成一種政策狀態，而不是只在模型感到不確定時才彈出的對話框。封鎖、批准、繼續三種結果可以對應不同風險級別；shell、檔案、網絡三種資源則可以各自設定。這讓團隊有機會把 agent 操作寫成可審查的政策矩陣，並用實際任務測試每條規則，而不是只依賴使用者的安全習慣。
採用時仍要保留其他防線。企業應該限制 agent 接觸的 secrets，配合分支保護、測試要求、code review、最小權限憑證和可回復的工作環境。政策可以阻止一個類型的操作，但不能判斷一段程式碼是否符合業務規則，也不能代替對資料外洩、依賴套件和部署影響的審查。最安全的工作流是讓 agent 多做可驗證的準備，人保留合併、部署和例外決策。
GitHub 這次發布的信號，是企業級 coding agent 正由「每個人自行調校批准提示」走向集中政策控制。當 agent 可以跨 IDE、CLI 和雲端流程運作，權限規則必須能夠跟隨工具和工作階段，並且不能被較低層設定悄悄放寬。對企業來說，下一步不是單純開啟功能，而是建立一套可讀、可測試、可追蹤版本的 agent policy，證明每個命令、檔案路徑和網絡目的地都有合理的批准邊界。
