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，证明每个命令、文件路径和网络目的地都有合理的审批边界。
