权限模型怎么配：自动批准和人工确认的边界在哪

agent 权限配置直接决定了它能闯多大的祸。这件事没有标准答案，但有一条判断原则：可逆的动作可以自动，不可逆的动作必须确认。 Claude Code 侧从 8 月中旬开始，auto 模式成为 Pro、Max、Team 用户的默认权限模式。它的机制是用一个后台分类器评估每个动作，安全的放行，有风险的拦截或标记。Anthropic 还专门加了规则，对于访问云元数据凭据、绕过出口、跨租户访问这类动作不再自动批准。另外自动模式在第一次读取工作目录之外的文件时会提示一次，这个设计很合理。 按可逆性给动作分级的建议： 完全自动（可逆且影响面小）：读文件、搜索、跑只读命令、装依赖到隔离环境、修改工作目录内的代码。 自动但记录（可逆但影响较大）：批量修改文件、执行可能改变本地状态的脚本、创建分支。这类动作要留完整日志，方便回溯。 需要确认（难逆或者涉及外部）：推送代码、合并 PR、向外部服务发请求、修改配置文件、删除文件。 绝不自动（不可逆或涉及生产）：生产环境操作、数据库结构变更、权限变更、删除数据、密钥相关操作。 两条补充原则： 一，影响面比可逆性更优先。一个可逆但影响上千个文件的操作，也应该要求确认。 二，环境切换要重新评估。开发环境可以宽松，预发收紧，生产必须是全人工。不要用同一套配置贯穿所有环境。 实践中的做法：把项目级的权限配置纳入版本管理，和代码一起 review。这样权限策略本身也是可审计的，不会悄悄漂移。 最后提醒：不要因为"确认太烦"就把所有环节都设成自动。那些确认提示拦住的问题，通常都是最贵的。