AI Coding Tools
GitHub 將代理工具權限統一交由企業政策裁決，但軟體規則不等於作業系統隔離
Copilot 企業管理員現可跨 App、CLI 與 VS Code，集中把命令、檔案及網域操作設為允許、詢問或拒絕。政策不能被使用者的自動核准或既存許可覆寫，但若未搭配沙箱，代理啟動的程序仍可能繼承主機帳號能力。
GitHub 為 Copilot Business 與 Enterprise 推出正式版「managed permissions」，讓管理員以相同規則控制 Copilot App、Copilot CLI，以及採用 Agent Host 的 VS Code 工作階段。規則目前可比對 `Shell`、`Read`、`Edit` 與 `Domain` 四類操作，分別設定 `deny`、`ask` 或 `allow`；企業還能對不同團隊套用不同政策，而毋須全面關閉代理模式。
這項更新處理的是代理前端常見的權限漂移：使用者先前保存的核准、工作區設定、`allow-all` 或自動核准，都不能削弱中央限制。VS Code 的公開測試計畫顯示，解析優先序為拒絕高於詢問、詢問高於允許，未匹配操作預設要求確認。路徑規則可區分工作區、目前目錄、家目錄與檔案系統根目錄；網域亦可個別列入允許或拒絕清單，適合封鎖憑證目錄、限制 `git push`，或只開放內部套件站。
重要的是，managed permissions 是 Agent Host／Copilot SDK 在工具呼叫層執行的政策，不應與核心或容器提供的強隔離混為一談。GitHub 自己的 CLI 文件指出，Shell 命令可以安裝軟體、刪除檔案、推送程式碼及發送網路請求；若管理規則允許命令執行，實際能力仍取決於程序的主機權限及是否另行啟用本機或雲端沙箱。這也與日前 JetBrains 加入的企業沙箱不同：前者決定代理可否嘗試某項操作，後者限制已啟動程序真正能碰到的資源。
部署者應先以最小規則集驗證萬用字元、符號連結、工作區根目錄解析及命令包裝器，並把拒絕事件納入稽核。後續值得觀察的是 MCP 工具、瀏覽器操作與子代理能否納入同一權限語法，以及各平台是否維持一致的強制執行語意。