摘要： GitHub 於 2026 年 10 月 26 日宣布，Copilot assisted permissions 正式一般可用（GA），涵蓋 GitHub Copilot CLI、GitHub Copilot app 與 Visual Studio Code。當 Copilot 想執行指令、存取檔案路徑或開啟 URL 時，改由大型語言模型先評估該請求；被判定為「明確安全」的自動放行，其餘仍需你點頭核准。對每天讓 agent 跑指令的人來說，這直接減少了核准次數，而企業端也拿到了對應的管控開關。
實際上怎麼運作
過去 agent 式工作流程最磨人的地方，往往不是模型能力，而是核准疲勞：每一個 mkdir、每一次讀取設定檔，都要人工確認。Assisted permissions 的做法是在請求與人工之間加了一層 LLM 分類——GitHub 在 changelog 中說明，被分類為 clearly safe 的請求會自動執行，其他一律回到手動核准。
要注意的是，這不代表你可以完全放手。分類錯誤的邊界情況仍會掉回人工核准那一側，也就是設計上偏保守：不確定的就問你。
三個入口，開法不一樣
啟用方式依工具而異：
- Copilot CLI：執行
/permissions，選擇 assisted。 - Copilot app：開啟 mode picker，點 Tool permissions，選 Assisted。
- VS Code：開啟 permissions picker，選 Assisted permissions。
三個介面各自保留了既有的權限模型，assisted 只是多了一檔可選。如果你已經在用 Copilot app 整合 diff、終端機與瀏覽器的審核流程，這一檔可以理解成把「每次都問」換成「可疑才問」。
企業管理員拿到了預設權
對企業管理者而言，這次 GA 比個人體驗更值得留意。GitHub 提供兩個企業層級的 managed settings：可以封鎖 Allow All 但保留 Assisted，也可以單獨停用 Assisted。另外，管理員能為新 session 指定預設權限模式，開發者仍可在政策允許的範圍內切換；若預設模式不可用或被政策禁止，session 會退回手動核准。
這個設計思路和先前 JetBrains 版 Copilot 把預設模型決定權交給企業管理員的做法一致：把預設值的決定權還給管理員，而不是讓每個開發者的個人設定各自為政。權限這種事交給「每個人自己記得開」從來行不通，有組織層級的預設值才推得動。
該不該開？一個務實的判斷
如果你的日常是高頻率的 agent 迴圈——跑測試、建置、重複的檔案操作——assisted 檔能省下大量按下核准的時間，成本只是多信任一層 LLM 分類。如果你的環境涉及生產憑證、敏感路徑，先讓管理員設定好企業預設，再考慮是否保留 Allow All。
GitHub 表示關於評估機制與何時需要核准的細節，可參考其文件〈Allowing safe commands to run without manual approval〉。值得一讀再決定要不要在團隊內預設開啟——安全機制的價值，最終取決於你了解它放行的邊界在哪裡。
參考來源
在 X 上查看原貼文