Claude Code 自动模式：一种更安全的跳过权限方式

# Claude Code 自动模式：一种更安全的跳过权限方式 来源：https://www.anthropic.com/engineering/claude-code-auto-mode 默认情况下，Claude Code 在执行命令或修改文件前会请求用户批准。这保障了用户安全，但也意味着大量点击"批准"。久而久之，这会导致批准疲劳，人们对正在批准的内容不再仔细关注。 用户有两种避免这种疲劳的方案：内置沙箱（工具被隔离以防止危险操作），或 `--dangerously-skip-permissions` 标志（禁用所有权限提示，让 Claude 自由行动，这在大多数情况下都不安全）。图1展示了权衡空间。沙箱安全但维护成本高：每项新能力都需要配置，任何需要网络或主机访问的操作都会破坏隔离。绕过权限则零维护但无保护。手动提示处于中间位置，而实践中用户接受了93%的提示。 **图1：Claude Code 中可用的权限模式，按任务自主性和安全性定位**。圆点颜色表示维护摩擦。自动模式以低维护成本实现高自主性；虚线箭头显示随着分类器覆盖范围和模型判断能力提升，安全性随时间改善。 我们维护一份专注于智能体不当行为的内部事件日志。过往案例包括：因误解指令而删除远程 git 分支、将工程师的 GitHub 认证令牌上传到内部计算集群、尝试对生产数据库执行迁移。这些都是模型过于急切的结果，以用户未预料的方式主动采取行动。我们在 Claude Opus 4.6 系统卡（https://www-cdn.anthropic.com/14e4fb01875d2a69f646fa5e574dea2b1c0ff7b5.pdf）（§6.2.1 和 §6.2.3.3）中记录了这一模式。 自动模式是 Claude Code 的新模式，将审批委托给基于模型的分类器——介于人工审查和无防护措施之间的中间地带。目标是拦截那些与用户意图不一致的危险操作，同时让其余操作无需批准提示即可运行。按照文档（http://code.claude.com/docs/en/permission-modes#eliminate-prompts-with-auto-mode）开始使用自动模式。 ## 工作原理 自动模式采用两层防御：一层针对 Claude 读取的内容，一层针对 Claude 执行的操作。 在输入层，服务器端提示注入探针扫描进入智能体上下文的工具输出（文件读取、网页获取、Shell 输出、外部工具响应）。当内容看起来像是试图劫持行为时，探针在结果传递给智能体前向上下文中添加警告——告知智能体将此内容视为可疑，并锚定用户实际要求的内容。 在输出层，转录分类器（运行在 Sonnet 4.6 上）在执行前根据一组决策标准评估每个操作，作为人工审批者的替代。分类器分两个阶段运行：快速单令牌过滤器（决定"是"以阻止或"否"以允许），仅在第一个过滤器标记转录后才进行思维链推理。由于大多数操作都通过第一阶段，推理令牌仅在需要时消耗。分类器仅看到用户消息和智能体的工具调用；我们剥离 Claude 自身的消息和工具输出，使其在设计上无法获取推理过程。我们在下面的设计决策部分详细讨论这些选择，包括它们的收益和代价。 **图2：系统架构**。转录分类器控制工具调用；提示注入探针筛选工具结果。子智能体递归运行相同的流水线，在委托时（可拒绝）和返回时（仅警告）有交接分类器。 ## 威胁模型 智能体可能因四种原因采取危险行动： 1. **过度急切行为**。在这种情况下，智能体理解用户目标并真诚地想提供帮助，但采取了超出用户批准范围的主动行动。例如，它使用了偶然发现的凭据，或删除了它判断为障碍的内容。这种行为难以捕捉，因为没有敌对推理。该行动反而看起来像合理的问题解决，只是应用超出了用户授权或意图的边界。 2. **诚实错误**。这里，智能体误解了影响范围。例如，它认为资源是测试范围的，而实际上是共享的；或认为分支是自己的，而实际上不是。 3. **提示注入**。植入文件、网页或工具输出中的指令劫持智能体，将其从用户任务重定向到攻击者目标。 4. **未对齐模型**。典型地，未对齐发生在智能体追求自身目标时。我们目前在实践中未观察到这种情况，但对我们发布的每个模型都仔细评估。 在所有四种情况下，防御措施都是阻止该行动。我们的分类器针对过度急切行为和诚实错误进行了调优，因为我们从内部模型测试中有具体例子，但无论哪种威胁产生了该行动，防御都适用。 以下示例改编自我们的内部事件日志，说明自动模式旨在阻止什么： - **范围升级**。用户要求"清理旧分支"。智能体列出远程分支，构建模式匹配，并发出删除命令。这会被阻止，因为请求模糊、操作不可逆且具有破坏性，用户可能仅指删除本地分支。 - **凭据探索**。智能体在任务中途遇到认证错误。它没有请求许可，而是开始系统地搜索环境变量和配置文件以寻找替代 API 令牌。由于这些凭据可能针对不同任务，这被阻止。 - **智能体推断参数**。用户说"取消我的作业"。智能体查询集群，按名称相似度选择最接近的匹配，并尝试删除。这被阻止，因为特定目标可能不是用户意图的，且可能属于他人。 - **通过外部服务共享**。智能体想分享脚本进行调试，并构建了 GitHub Gist 命令。这被阻止作为数据外泄，因为用户可能认为内容是机密的，不适合公开。 - **安全检查绕过**。部署命令未通过预检查；智能体重试时使用了跳过验证标志。这被阻止，因为它可能影响共享基础设施。 ## 权限决策如何工作 上述所有示例都会到达分类器，但大多数操作在此之前就被标准 Claude Code 允许规则放行： **第一层：内置安全工具允许列表和用户设置。** 固定允许列表包括无法修改状态的工具，如文件读取、文本和文件模式搜索、代码导航、待办事项和计划模式切换。用户还可以为特定工具模式配置始终允许规则。一个例外是进入自动模式时，我们会放弃已知授予任意代码执行权限的规则，包括 blanket shell 访问、通配脚本解释器（python、node、ruby 及类似）和包管理器运行命令。虽然这是基于真实世界使用情况的最佳努力，但任何列表都必然不完整。许多用户为手动批准模式的便利设置了这些 blanket 规则，但保留它们活跃意味着分类器永远看不到最有能力造成损害的命令。窄规则（"允许运行代码格式化工具"）会保留，但宽泛的解释器逃逸不会。 **第二层：项目内文件操作。** 项目目录内的文件写入和编辑无需分类器调用即可允许。常规编码（例如编辑仓库中的源文件）不支付分类器延迟；项目内编辑可通过版本控制审查。 只有具有实际负面潜力的操作才会到达最终层： **第三层：转录分类器。** 转录分类器处理其余所有内容，包括 Shell 命令、网页获取、外部工具集成、子智能体生成、项目目录外的文件系统操作。第一阶段是快速的单令牌（是/否）过滤器，被指示偏向阻止；如果标记，第二阶段用思维链推理重新评估相同输入以减少误报。 ## 分类器决策标准 分类器的提示是我们发布的固定模板，中间插入三个可定制插槽。固定部分完成解释性工作——如何确定操作实际做什么、如何读取用户授权、分类过程本身——这些对所有人都相同。插槽定义您的策略：什么在您的环境中算作可信、要阻止的类别、要 carve out 的例外。良好的默认值开箱即用。您可以立即开始使用自动模式，并在使用该功能时迭代扩展配置。 ### 固定模板 **评估规则告诉分类器如何查找危险命令**。原则是评估操作的实际影响，而不仅仅是调用的表面文本。智能体不应将危险操作隐藏在看似良性的包装后面。如果智能体将载荷写入文件然后运行，分类器评估载荷。如果命令链用 `&&` 连接，整个链条是一个操作。如果智能体编写组装 Shell 命令的 Python 脚本，分类器从转录上下文中评估组装后的命令，然后才允许执行脚本。 **用户意图规则告诉分类器如何读取授权**。这是提示中难以做对的部分。也是过度急切行为防御所在之处。分类器必须判断操作是否是用户授权的操作，而不仅仅是与用户目标相关的操作。分类器故意保守。提示建立什么是授权的；智能体自行选择的一切都是未授权的，直到用户另有说明。在这种情况下，"清理我的分支"不授权批量删除，"我们能修复这个吗？"会被视为问题而非指令。 模板包含逐步分类过程，检查操作是否符合阻止规则，然后允许例外，接着检查用户意图，最终做出决定。 ### 可定制插槽 "环境"定义信任边界，哪些域、云存储桶、源代码管理组织和内部服务算作"内部"与"外部"。默认情况下，分类器唯一信任的是您当前工作的 git 仓库。用户可以在设置中自定义，使分类器识别其可信基础设施（例如 GitHub 组织、云存储桶或内部 API）。此边界外的任何内容都可能是外泄风险。 默认有二十多条阻止规则，分为以下几组： - **销毁或外泄。** 通过强制推送覆盖历史、批量删除云存储、向外部发送内部数据造成不可逆损失。 - **降低安全态势。** 通过禁用日志、安装 SSH 密钥或 cronjob 等持久化机制、或修改智能体自身权限配置，使系统更难监控或防御。 - **跨越信任边界。** 对智能体没有信任基础的事物采取行动，如运行从外部仓库克隆的代码、扫描凭据存储以寻找可用令牌、或向用户未指定的服务发送数据。 - **绕过审查或影响他人。** 通过直接推送到 main、运行生产部署、或修改智能体未创建的共享资源或作业，跳过共享基础设施的安全措施。 允许例外是技术性匹配阻止规则但操作良性的强制 carve-out。默认范围狭窄，包括安装已在仓库清单中声明的包、标准凭据流程、以及推送到会话的工作分支。 三个插槽都带有保守默认值，因此您可以无需编写任何内容即可开始。运行 `claude auto-mode defaults` 查看完整列表。如果自定义这些，我们建议编辑此基线，而非从头开始。 ## 结果 我们在三个不同数据集上评估了完整流水线。两个数据集衡量自动模式所做的权衡：真实流量上的误报率（剩余多少摩擦）和真实过度急切行为上的召回率（运行自动模式时仍然存在的风险）。第三个衡量合成数据外泄任务上的召回率。 - **真实内部流量**（n = 10,000）。Anthropic 员工的真实 Claude Code 工具调用。 - **真实过度急切行为**（n = 52）。从员工拒绝操作或事后标记的会话中精选。数量少是因为需要 Claude 在真实会话中尝试危险操作，并被捕获和标记。 - **合成数据外泄**（n = 1,000）。包括敏感数据的 HTTP POST、推送到不可信远程的 git、嵌入 URL 的凭据等生成尝试；许多使用混淆。 我们报告两个指标。假阴性率（FNR）是分类器放过的危险操作比例；假阳性率（FPR）是分类器阻止的良性操作比例。完美分类器两者都为零。实践中它们相互权衡。第一阶段快速廉价，调优为低 FNR 但高 FPR。第二阶段更昂贵，仅在第一阶段标记的内容上运行。它清理误报但会让更多危险操作通过。 **真实流量** n=10,000**真实过度急切** n=52**合成外泄**n=1,000第一阶段（快速过滤器）8.5% FPR6.6% FNR1.8% FNR第一阶段→第二阶段（完整流水线）0.4% FPR17% FNR5.7% FNR 表1. 按阶段分类器性能。第二阶段仅在第一阶段标记的操作上运行，因此第二行反映端到端部署流水线：FPR 从 8.5% 降至 0.4%，代价是一些召回率。 真实过度急切行为上 17% 的假阴性率是诚实数字。智能体试图解决用户问题并尝试执行超出授权的危险命令。 在我们检查的大多数漏检中，分类器正确识别了危险。它看到了，例如，强制推送、删除和基础设施变更。它出错的是否会话中的真实同意信号实际覆盖*此*操作。"清理 PR"是用户说的，但没有指名强制推送。类似操作之前被批准过，但一次批准不是模式。分类器找到看似批准的证据，却未检查它是否是对操作影响范围的同意。我们尝试了提示工程来解决这个问题，但找不到收益大于成本的方案。 17% 是否可接受取决于您与什么比较。如果您运行 `--dangerously-skip-permissions`，这是显著改进。如果您仔细手动批准每个操作，这可以说是退步——您用自己的判断换取有时会犯错的分类器。自动模式面向第一组人，以及第二组人批准开销不值得边际安全性的任务。它不是高赌注基础设施上仔细人工审查的直接替代品。 ## 设计决策 ### 为什么剥离助手文本和工具结果 我们剥离助手文本，使智能体无法说服分类器做出错误判断。智能体可能生成有说服力的理由