2026 年 9 月 9 日，GitHub Changelog 宣布：GitHub Copilot Business 与 Copilot Enterprise 的管理员，现在可以集中控制 Agent 操作是被拦截、需要人工批准，还是无需提示即可执行。这项能力覆盖 shell 命令、文件读取与编辑，以及网络域名，并已在 GitHub Copilot 应用、Copilot CLI，以及使用 Agent Host 的 Visual Studio Code 会话中正式可用。
真正卡住企业启用 Agent 的，往往不是模型会不会改代码，而是一次本机“自动批准”会不会把删目录、读 ~/.ssh、访问未审批域名一起放过去。GitHub 这次把判断权从个人会话收回到企业策略，并写明：托管限制不能被用户或工作区设置、自动批准，或此前保存的批准记录削弱。
本文只讨论这一次发布：管理员要把策略接到一次真实 Agent 会话里，改的是哪一步，以及人还必须守住哪里。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
企业第一次能从中心拦住 Agent 的敏感动作
此前，Copilot Agent 能不能执行一条命令、读一个路径、访问一个域名，更多取决于开发者本机的自动批准、YOLO / bypass 模式，以及会话里已经点过的“允许”。平台团队很难保证：有人用 Agent 修测试时，不会顺手读到 SSH 私钥目录，或对未审批域名发起请求。
9 月 9 日这次更新，把控制收成中心策略。管理员可以把每类操作设成三种结果：直接拦截、每次重新询问，或无需提示放行。GitHub 同时说明，可以为不同企业团队提供专门策略，而不是全公司共用一份过宽或过严的名单。
官方文档把规则落在 managed-settings.json 里，对应键是 permissions.deny、permissions.ask、permissions.allow，以及用于关闭 YOLO 式全部放行的 permissions.disableBypassPermissionsMode。判定优先级是 deny 高于 ask，ask 高于 allow。文档还写明：只要托管来源定义了权限规则或 allow 列表，未匹配到的受支持操作会默认改成需要批准，而不是继续走开发者本机的宽松流程。任意一个托管来源写下的 deny，也会对所有用户生效，其他来源的 ask 或 allow 不能把它打开。策略文件怎么创建，官方文档指向 Getting started with enterprise-managed settings，而不是让各客户端各自发明一份配置。
一次 Agent 操作会怎么被判定
接到真实会话里，路径很短。管理员先写入企业托管配置；开发者在 Copilot 应用、CLI，或 VS Code 的 Agent Host 会话里让 Agent 工作；当 Agent 要执行 shell、读文件、改文件或访问域名时，客户端按选择器匹配规则，再给出拦截、弹窗或放行。
官方示例把边界写得很具体：Shell(rm -rf *)、Read(~/.ssh/**)、Edit(//etc/**) 和 Domain(*.unapproved.example) 放进 deny；Shell(git push *)、Edit(/src/**) 和 Domain(api.github.com) 需要 ask；Shell(npm test *)、Read(/src/**) 和 Domain(registry.npmjs.org) 可以 allow。
选择器本身也决定了能不能写进日常工作流。Shell(git push *) 这种写法匹配命令前缀；Bash(...) 是 Shell 的兼容别名，PowerShell(...) 则按不区分大小写匹配。Read 和 Edit 支持 glob，并用 // 表示文件系统根、/ 表示工作区根、~/ 表示用户主目录、./ 表示当前工作目录。Domain 的裸主机名默认按 HTTPS 处理，主机匹配不区分大小写，*.example.com 会覆盖主域和子域。
对工作流影响最大的，是 ask 必须是新鲜的一次性批准。GitHub 写明，它不能被 bypass / YOLO 模式、自动批准、hook 或其他批准捷径，或更早保存的授权满足。同一操作下次出现，还要再问一次。这正好打断很多团队已经习惯的“第一次点允许，后面 Agent 自己跑”。
它改的是批准这一步，不是模型能力
对开发者，输入还是“修这个失败测试、提交补丁”。变化发生在中间：Agent 生成补丁后，若要跑 npm test，命中 allow 就可以继续；若要 git push，必须有人点一次；若要删目录或读 SSH 密钥，应按 deny 直接挡住。交付和反馈仍在 IDE 或 CLI 里完成，但敏感副作用不再默认跟随会话记忆。
对管理员，工作从“提醒大家别开 YOLO”变成维护一份可分发的策略文件，并按团队覆盖。文档允许把部分键设成 overridable，再在团队文件里给出更严或更宽的替换规则。平台组可以先定底线，应用组再收紧推送，或放行自己的测试命令。
allow 的合并方式也值得单独看一眼：如果多个托管来源都声明了 allow 列表，生效的是交集而不是并集。也就是说，企业底线允许 npm test，并不等于某个团队文件再写一次更宽的 allow，就能把 git push 也变成免确认。这套模型把 Agent 当成会发起系统调用的执行者，而不是只补全文本的聊天窗口。
还不能把它当成全面安全闸门
先看范围。Changelog 写明，一般可用的客户端是 Copilot 应用、Copilot CLI，以及使用 Agent Host 的 VS Code 会话。文档补充：VS Code 里这些细粒度规则作用于 Agent Host；disableBypassPermissionsMode 的支持面更广，并不限于 Agent Host。如果团队还在普通 Copilot Chat，或未启用 Agent Host 的会话里跑 Agent，不能默认 deny / ask / allow 已经生效。
再看产品边界。它面向 Copilot Business 与 Copilot Enterprise 管理员，不是所有个人用户的新开关。GitHub 也没有宣称这能替代密钥扫描、PR 门禁或运行沙箱。相邻的是 9 月 8 日 Changelog 里 Copilot for JetBrains 的企业托管沙箱，那是另一项发布，覆盖命令执行环境，而不是同一天的同一套权限键。GitHub 还在 Changelog 里给出了社区讨论入口，方便管理员反馈落地问题和实现细节。
最后看策略本身。allow 写得过宽，等于把中心控制又放回去；deny 如果只拦 rm -rf，Agent 仍可能用别的命令造成破坏。策略文件从“没有”变成“有一份不完整名单”时，开发者会突然看到更多弹窗。上线时需要同步团队，明确哪些命令会免确认、哪些每次都要人点，而不是只丢一个 JSON 就当治理完成。
信息来源
- GitHub Changelog，2026-09-09：Enterprise managed permissions for GitHub Copilot agent operations
- GitHub Docs：Enterprise managed settings（deny / ask / allow）
- GitHub Changelog，2026-09-08：Enterprise-managed sandbox in Copilot for JetBrains（相邻发布，不是本文事件）
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
