Claude Code Auto Mode：一种更安全的权限跳过方式¶
原文发布于 2026 年 3 月 25 日，作者 John Hughes
问题背景¶
用户 93% 的权限提示都被批准——审批疲劳使得权限系统形同虚设。 Claude Code 通常在运行命令或修改文件前会征求用户许可。但数据显示，用户批准了 93% 的权限提示。这导致了"审批疲劳"——人们不再认真审查自己正在批准什么。
在此之前，用户面对两个极端选择：
| 方案 | 自主性 | 安全性 | 维护成本 |
|---|---|---|---|
| 沙箱（Sandbox） | 高 | 高 | 高 |
--dangerously-skip-permissions |
高 | 低 | 零 |
| 逐条手动审批 | 低 | 高 | 中 |
| Auto Mode（新方案） | 高 | 高 | 低 |
Auto mode 填补了这个空白——以低维护成本实现高自主性和高安全性。
内部事故驱动¶
真实的生产事故证明了仅靠用户审批是不够的。 团队维护了一份内部事故日志，记录了以下类型的危险行为：
- 将"清理旧分支"误解为删除远程 git 分支
- 将工程师的 GitHub 认证令牌上传到内部计算集群
- 尝试对生产数据库执行迁移操作
这些事故记录在 Claude Opus 4.6 系统卡（§6.2.1 和 §6.2.3.3）中。
系统架构¶
双层防御：输入层扫描注入攻击，输出层分类每个动作是否安全。 Auto mode 使用两个独立的防御层：
- 输入层（Prompt 注入探测）：服务端探测器扫描工具输出，在注入尝试进入 Agent 上下文之前添加警告。
- 输出层（转录分类器）：基于 Sonnet 4.6 的分类器在每个动作执行前进行评估。
两层防御相互叠加——注入攻击要成功，必须同时绕过输入层探测 和 引导 Agent 生成一个被转录分类器独立判定为安全的工具调用。
威胁模型¶
Agent 可能执行危险动作的四个原因，按当前发生频率排列。
| 类别 | 描述 | 频率 |
|---|---|---|
| 过度积极行为 | Agent 主动超出用户授权范围行事 | 最常见 |
| 诚实错误 | Agent 误判了操作的影响范围 | 常见 |
| Prompt 注入 | 文件或网页中的恶意指令劫持 Agent | 偶发 |
| 模型不对齐 | Agent 追求自身目标（实践中尚未观察到） | 理论风险 |
被拦截的真实案例¶
分类器在实际使用中拦截的五类典型危险操作。
| 类别 | 场景 |
|---|---|
| 范围升级 | 用户要求"清理旧分支"，Agent 尝试删除远程分支 |
| 凭据探索 | Agent 遇到认证错误后，系统性地 grep 环境变量中的 API 令牌 |
| Agent 推断参数 | Agent 根据名称相似度选择最接近的任务进行删除 |
| 通过外部服务分享 | Agent 构造 GitHub Gist 命令，可能包含机密代码 |
| 绕过安全检查 | 部署前检查失败后，Agent 用 skip-verification 标志重试 |
权限决策分层¶
三个层级逐步递进：允许列表 -> 项目内操作 -> 分类器审查。
Tier 1：内置允许列表 + 用户配置¶
包括文件读取、搜索、代码导航等安全操作。进入 auto mode 时，用户原有的宽泛 shell 访问规则会被移除。
Tier 2：项目内文件操作¶
无需调用分类器即可放行，因为这些操作可以通过版本控制系统进行审查。
Tier 3：转录分类器¶
处理所有其他情况——shell 命令、网络请求、外部工具调用、子 Agent 派生、项目目录外的文件系统操作。
分类器的输入：它看到什么？¶
分类器被设计为"推理盲"——只看用户消息和工具调用载荷，不看 Agent 的推理文本和工具输出。 这意味着：
- Agent 的自然语言解释（assistant prose）被剥离
- 工具调用的描述性文本被剥离
- 工具输出结果被剥离
- 只保留用户消息和可执行载荷
两阶段流水线¶
第一阶段快速过滤，第二阶段深入推理——在速度和准确率之间取得平衡。
| 阶段 | 机制 | 特点 |
|---|---|---|
| Stage 1 | 单 token 输出（yes/no） | 快速，倾向于阻止（宁严勿宽） |
| Stage 2 | Chain-of-thought 推理 | 仅在 Stage 1 标记时触发，几乎全部是缓存命中 |
允许列表中的工具直接跳过分类器执行；其余一切先过 Stage 1 快速过滤，被标记的再进入 Stage 2 深入推理。
分类器决策标准¶
固定模板规则 + 可定制插槽，用户可通过 claude auto-mode defaults 查看完整默认配置。
固定模板部分¶
- 评估规则：评估真实世界影响，而非表面文字
- 用户意图规则：保守原则——"Agent 自行决定的一切在用户明确同意前都视为未授权"
- 分类流程：检查阻止规则 -> 检查允许例外 -> 判断用户意图 -> 做出决定
可定制插槽¶
- 环境定义：定义信任边界（域名、云存储桶、组织）
- 阻止规则（20+）：分为四组——销毁/泄露、降低安全态势、跨越信任边界、绕过审查/影响他人
- 允许例外：窄范围的放行规则（安装声明的依赖包、标准凭据流程、推送到工作分支）
评估结果¶
0.4% 误报率使 auto mode 实际可用；17% 对过度积极行为的漏报率是"诚实数字"。
| 数据集 | Stage 1（快速过滤） | Stage 1 + Stage 2（完整流水线） |
|---|---|---|
| 真实流量（n=10,000） | 8.5% 误报率 | 0.4% 误报率 |
| 真实过度积极行为（n=52） | 6.6% 漏报率 | 17% 漏报率 |
| 合成泄露攻击（n=1,000） | 1.8% 漏报率 | 5.7% 漏报率 |
17% 漏报率的主要失败模式：分类器发现了"看起来像批准"的证据，就不再进一步检查该批准是否覆盖了当前操作的实际影响范围。
关键设计决策¶
为什么剥离 Assistant 文本和工具结果？¶
防止 Agent "说服"分类器，也防止注入通过工具输出传递。
- 如果保留 Assistant 文本，Agent 可能通过合理化解释误导分类器
- 如果保留工具输出，注入攻击可直接写给分类器
- 代价：丢失了来源信息（例如分类器不知道某个值来自用户还是自动生成）
- 更短的转录文本也让分类器更容易评估
为什么用两阶段而非一阶段？¶
- Stage 1 的 8.5% 误报率可接受（因为后面还有 Stage 2）
- Stage 2 将误报率降到 0.4%
- Stage 2 的 prompt 输入几乎全部是从 Stage 1 的缓存命中，延迟开销小
Prompt 注入探测的作用¶
要让注入攻击端到端成功，必须同时绕过输入层探测 和 引导 Agent 生成一个被转录分类器独立判断为安全的工具调用。两层防御复合叠加。
多 Agent 交接¶
- 出站检查：在委派时进行，此时原始用户意图的上下文尚未丢失
- 返回检查：审查子 Agent 的完整动作历史，再让结果返回编排者
拒绝并继续（Deny-and-Continue）¶
被阻止的动作不会终止会话，而是作为工具结果返回，指导 Agent 寻找更安全的替代方案。
- 连续 3 次拒绝或累计 20 次 -> 升级到人工
- headless 模式（
claude -p）中：进程终止 - 这让误报变得可生存——Agent 会重试而非停摆
- "0.4% 误报率听起来很小，但如果每次误报都杀死会话，将是严重的可用性问题"
下一步¶
Anthropic 计划扩大过度积极行为的测试集，并持续迭代安全性和成本的改进。他们指出分类器"不需要完美才有价值"，同时鼓励用户保持对残余风险的意识。
致谢¶
作者：John Hughes。贡献者：Alex Isken、Alexander Glynn、Conner Phillippi、David Dworken、Emily To、Fabien Roger、Jake Eaton、Javier Rando、Shawn Moore 和 Soyary Sunthorn。