本页目录9
- auto mode 定位于「手动批准」「沙箱隔离」「--dangerously-skip-permissions」之间的折中方案,目标是减少批准疲劳同时保留安全边界
- 系统分两层:输入层做提示注入探针扫描工具输出,输出层用 Sonnet 4.6 转录分类器在行动执行前评估风险
- 分类器只看用户消息和工具调用命令,刻意不看助手自身文本和工具输出内容,防止代理用说服性文字影响分类结果
- 权限决策分三级:内置安全工具白名单、项目内文件读写自动放行、其余(Shell命令、外部工具、跨项目文件操作等)交给分类器
- 评测显示完整管道假正率(FPR)约0.4%,但对真实过度主动行为的假负率(FNR)仍有17%,官方称这是「诚实的数字」而非已解决问题
- 触发拦截时默认「拒绝并继续」而非直接中止,让代理换一条更安全的路径重试,连续或累计拒绝过多才升级人工审查
本文是对 Anthropic 官方文章「How we built Claude Code auto mode: a safer way to skip permissions」的中文要点摘要,完整内容以原文为准:https://www.anthropic.com/engineering/claude-code-auto-mode
背景:权限提示的两难
Anthropic 统计发现,Claude Code 用户对权限提示的批准率高达 93%。这说明大多数提示其实是「噪音」——用户已经默认信任代理,却仍要一遍遍点确认,造成「批准疲劳」。此前用户只有三种选择:手动逐条批准(安全但烦人)、跑在沙箱里隔离(安全但维护成本高)、直接用 --dangerously-skip-permissions 跳过所有确认(省心但完全没保护)。auto mode 想做的,是在这三者之间找一个中间地带。
四层威胁模型
官方把代理可能做出危险动作的原因归纳为四类:
- 过度主动:代理理解用户目标,但擅自扩大了授权范围,比如用发现的凭证登录、删掉它认为「碍事」的东西。
- 诚实错误:代理误判了影响范围,比如以为某个测试资源是私有的,实际上是共享资源。
- 提示注入:恶意指令藏在被读取的文件、网页或工具输出里,劫持代理的行为。
- 模型不对齐:代理追求自己的目标——官方表示目前在实践中尚未观察到这种情况。
两层防御架构
输入层:服务端的提示注入探针,扫描文件读取、网页抓取、Shell 输出等工具返回内容,检测是否存在劫持代理行为的企图,发现问题时附加警告而非直接拦截。
输出层:一个基于 Sonnet 4.6 的转录分类器,在代理真正执行动作之前进行评估,采用两阶段设计——先做快速筛选,再做链式思维式的深入推理。
一个关键设计是信息剥离:分类器只能看到用户的原始消息和代理即将发出的工具调用命令,看不到代理自己生成的对话文本,也看不到工具输出的具体内容。这是为了防止代理用一段「合理化」的说辞说服分类器放行本该被拦截的操作。
三级权限判定
- 第一级:内置的安全工具白名单,涵盖文件读取、搜索、代码导航等不会修改状态的操作,加上用户自己配置的「始终允许」规则。注意:一旦进入 auto mode,像
--dangerously-skip-permissions里那种可执行任意代码的规则会被移除。 - 第二级:项目目录内的文件写入/编辑默认自动放行,因为这类改动可以通过版本控制事后审查。
- 第三级:剩下的高风险类别——Shell 命令、网页抓取、外部工具集成、生成子代理、项目目录之外的文件系统操作——统统交给转录分类器裁决。
分类器的判断标准
分类器有一套固定模板,对所有用户统一适用,核心是两条规则:
- 评估真实影响,而非表面文本:如果代理把一段载荷写进文件再执行,分类器评估的是这段载荷本身;用
&&串联的命令链会被当作一个整体动作看待。 - 保守的用户意图原则:「先明确什么是被授权的,代理自行选择的一切在用户明说之前都视为未授权」。比如「清理我的分支」不能被解读为授权批量删除,「我们能修复吗?」应被当作一个问题而不是一条指令。
除此之外还有一组可定制插槽,由用户自行配置:
- 信任边界(环境定义):默认只信任当前 Git 仓库,用户可以扩展到 GitHub 组织、云存储桶、内部 API 等。
- 默认阻止规则(20 余条),大致分四类:破坏性/泄露类(强制推送覆盖历史、批量删除云存储、外发内部数据)、降低安全态势类(禁用日志、写 SSH 密钥或 Cron 任务做持久化、修改权限配置)、跨越信任边界类(运行外部仓库的代码、扫描凭证存储、把数据发到未声明的服务)、绕过审查类(直接推主分支、生产部署、改动共享资源)。
- 允许的例外情况很少,主要是仓库清单里已声明的包安装、标准凭证流程、推送到当前会话的工作分支。
拦截后怎么办:拒绝并继续
分类器判定危险时,并不会直接中止会话,而是返回拒绝理由和更安全的建议,提示代理「善意对待这条边界,换条更安全的路径」。只有连续 3 次被拒或累计 20 次被拒,才会升级为人工审查;在无头模式(claude -p)下,由于没有交互 UI,则直接终止进程。
多代理场景下,分类器会在子代理切换的出站和入站两端都跑一遍:出站检查防止主代理把超出用户原意的任务授权给子代理;子代理结果返回前,分类器会审查它完整的操作历史,若发现问题就附加安全警告而不是直接丢弃结果。
实测数据
官方用了三组数据集评测:1万条真实内部工具调用流量、52条员工事后标记或当场否决的真实过度主动行为、1000条模拟数据泄露样本(如把凭证塞进 HTTP POST 或 Git 推送里)。结果:
| 阶段 | 真实流量假正率 | 真实过度行为假负率 | 合成泄露假负率 |
|---|---|---|---|
| 第一阶段快速筛选 | 8.5% | 6.6% | 1.8% |
| 完整管道 | 0.4% | 17% | 5.7% |
官方坦承 17% 的假负率反映了分类器在判断「用户此前的同意是否覆盖当前操作」这件事上的局限——代理往往能正确识别出操作本身有风险(比如强制推送),但分类器很难判断这次具体操作是否已被此前的用户授权覆盖。0.4% 的假正率则意味着即使误判,用户重试一次的成本也很低。
如何启用
用 claude auto-mode defaults 命令可查看完整的默认规则列表,官方建议在默认配置基础上做增量修改,而不是从零开始写规则。详细文档见 code.claude.com 的 permission-modes 页面。
局限与定位
官方明确强调这不是万能方案:17% 的假负率是「诚实的数字」,说明仍有残留风险。auto mode 定位是替代 --dangerously-skip-permissions 这种「完全裸奔」的用法,而不是替代对高风险基础设施操作的人工审查。团队表示会持续扩充真实过度主动行为的测试集,并迭代这一能力的安全性与成本。