智能体能读文件跑命令之后，企业权限该怎么管
内容提要
GitHub 为 Copilot 新增集中权限管理，管理员可按团队对 Shell 命令、文件读写和网络域名分别设置阻止、审批或放行，企业策略不可被本地设置削弱。智能体风险来自动作组合，应按最小权限拆分能力，并定期审计权限与批准记录。
延伸解读
企业策略不可下调的实际意义
GitHub新权限功能强调企业级限制不能被用户设置、工作区设置、自动批准或历史批准记录削弱。这意味着组织策略成为权限上限，解决了过去中央治理可能被本地配置覆盖的问题。但文章也指出，具体效果仍取决于管理员是否正确分类命令和域名，因此不可下调原则是控制面的强化，而非风险的自动消除。
动作矩阵：从账号边界到能力边界
传统工具以仓库访问为边界，智能体却会连续调用多种能力。文章指出风险来自动作组合，例如读取配置文件后联网发送可能泄密，修改依赖后执行安装脚本可能运行第三方代码。因此最小权限需拆分为读、写、执行、联网等独立能力，让低风险动作顺畅、高影响动作停在可判断位置。
审批界面应提供完整上下文
文章以支付团队修复订单重试Bug为例，说明策略可允许读取仓库、编辑测试目录和访问官方文档域名，但修改基础设施目录需审批，生产部署命令、读取.env或访问粘贴服务直接阻止。审批者不应只看到“允许吗”，而应看到完整命令、工作目录、目标文件、域名和预计副作用，以便做出有效判断。
适用边界与持续维护
托管权限只覆盖支持的Copilot入口，不自动约束其他脚本、IDE插件或自建代理。域名白名单也不能识别所有内容级泄露，允许的官方域名可能承载用户可控内容。管理员错误地允许通配域名或危险命令同样会扩大风险。团队需像维护CI配置一样维护代理权限，并每月复盘被阻止与被批准的动作。
Q&A
GitHub 为 Copilot 新增的集中权限管理具体能管什么？
管理员可以集中管理智能体操作权限，针对 Shell 命令、文件读取与编辑、网络域名分别设置为阻止、需要人工批准或无需提示直接执行，并能为不同企业团队配置不同策略。
为什么企业级权限限制不能被本地设置覆盖？
因为过去员工可能在项目中打开自动批准或沿用临时授权，如果企业策略能被本地设置覆盖，中央治理就只是建议。不可下调原则让组织策略成为权限上限，确保企业级限制不被用户设置、工作区设置、自动批准或历史批准记录削弱。
智能体的风险为什么不能只看单个动作？
智能体会连续调用多种能力，风险来自动作组合。例如读取配置文件本身可能无害，但读取后联网发送就可能泄密；修改依赖文件可回滚，但紧接着执行安装脚本可能运行第三方代码。因此安全的基本单位是每一种操作能力及其后果，而非账号。
如何为智能体设计最小权限矩阵？
目标是让低风险动作顺畅、高影响动作停在可判断的位置。例如允许读取源码和运行单元测试，编辑普通业务文件需要记录，访问生产凭证目录、执行部署命令、连接未知域名则必须阻止或审批。
托管权限管理有哪些适用边界和风险？
托管权限只覆盖支持的 Copilot 入口，不自动约束其他脚本、IDE 插件或自建代理。域名白名单不能识别所有内容级泄露，允许的官方域名可能承载用户可控内容。管理员错误地允许通配域名或危险命令也会扩大风险。涉及生产环境时还需要独立凭证、网络隔离和变更审批。
今天就能执行的权限检查有哪些？
列出代理可读、可写、可执行、可联网的对象；将删除、部署、付款、权限修改和密钥访问设为阻止或强制审批；清理永久批准记录；为批准界面补齐命令、路径、域名、数据量和回滚方式；每月复盘被阻止与被批准的动作，删除不再需要的权限。
