AI 程式開發與安全
GitHub Copilot 將內容排除政策擴至 App 與 CLI，但符號連結和間接語意仍可能越界
Copilot Business 與 Enterprise 管理員設定的排除規則，現在可阻止 Copilot App 和 CLI 直接把指定檔案加入模型上下文。這項機制不是完整資料防漏或執行沙箱；官方仍列出符號連結、遠端檔案系統及 IDE 間接語意等缺口。
GitHub 9 月 2 日宣布，Copilot App 與 Copilot CLI 已正式支援企業、組織及儲存庫層級的內容排除政策。管理員可依儲存庫與路徑指定模型不得讀取的檔案；對使用 Business 或 Enterprise 授權的開發者，受排除內容不應再被這兩個代理介面直接納入提示上下文。這補上了代理從終端機或獨立應用巡覽整個工作區時的一個治理缺口。
政策並非只存在於用戶端設定。GitHub 文件指出，用戶端會傳送目前的儲存庫 URL，以取得適用規則，官方稱這些 URL 不會被記錄。組織也能透過版本化 REST API 讀寫路徑規則，適合把設定納入基礎設施即程式碼與稽核流程；不過該 API 仍是公開預覽，而且不支援註解與重複鍵。以 API 更新時，既有註解可能被刪除，重複鍵則只保留最後一項，直接往返同步可能造成無聲的設定損失。
更重要的是，「排除」只是一道上下文篩選器。官方明列：IDE 可能透過型別資訊、符號懸停定義或建置設定，間接向 Copilot 提供源自排除檔案的語意；規則目前也不適用於符號連結與遠端檔案系統。部分編輯器的 Edit、Agent 模式仍沒有相同支援。因此，團隊不能把它當成祕密管理、資料外洩防護或檔案系統沙箱。
導入時應以測試儲存庫驗證每個 Copilot 介面，並把內容排除與 CLI 的工具 allow／deny 規則、受信任目錄、作業系統隔離及憑證掃描分開管理。下一個值得追蹤的指標，是 GitHub 能否提供可查證的政策命中紀錄，以及讓符號連結、遠端工作區和各種代理模式採用一致的強制邊界。