默认情况下,Claude Code 在运行命令或修改文件之前会请求用户批准。这可以保证用户的安全,但也意味着需要多次点击“批准”。随着时间的推移,这会导致批准疲劳,人们不再密切关注他们所批准的内容。
用户有两种解决方案来避免这种疲劳:内置沙箱,其中工具被隔离以防止危险操作,或者“--dangerously-skip-permissions”标志,禁用所有权限提示并让 Claude 自由行动,这在大多数情况下是不安全的。图 1 列出了权衡空间。沙盒安全但维护成本高:每项新功能都需要配置,并且任何需要网络或主机访问的内容都会破坏隔离。绕过权限是零维护,但不提供任何保护。手动提示位于中间,实际上用户无论如何都会接受其中的 93%。
图 1. Claude Code 中可用的权限模式,按任务自主性和安全性定位。点颜色表示维护摩擦。自动模式以低维护成本实现高自主性;虚线箭头显示随着时间的推移,随着分类器覆盖范围和模型判断变得更好,安全性得到改善。
我们保留一份内部事件日志,重点关注代理不当行为。过去的示例包括从错误解释的指令中删除远程 git 分支、将工程师的 GitHub 身份验证令牌上传到内部计算集群以及尝试针对生产数据库进行迁移。所有这些都是模型过于渴望的结果,以用户不希望的方式采取主动。我们在 Claude Opus 4.6 系统卡 中记录了这种模式(§6.2.1 和 §6.2.3.3)。
自动模式是 Claude Code 的一种新模式,它将批准委托给基于模型的分类器 - 介于手动审核和无护栏之间的中间地带。目标是捕获与用户意图不符的危险操作,同时让其余操作在没有批准提示的情况下运行。按照文档开始使用自动模式。
自动模式使用两层防御:一层针对克劳德所读的内容,一层针对克劳德所做的内容。
在输入层,服务器端提示注入探针会在工具输出(文件读取、Web 获取、shell 输出、外部工具响应)进入代理上下文之前对其进行扫描。当内容看起来像是企图劫持行为时,探测器会在传递结果之前向代理的上下文添加警告,告诉代理将此内容视为可疑内容并锚定用户实际请求的内容。
在输出层,转录分类器(在 Sonnet 4.6 上运行)在执行之前根据一组决策标准评估每个操作,充当人类审批者的替代者。分类器分两个阶段运行:快速单标记过滤器(决定“是”阻止或“否”允许),然后仅当第一个过滤器标记转录本时才进行思想链推理。由于大多数操作都会完成第一阶段,因此推理代币仅在需要的地方使用。分类器只能看到用户消息和代理的工具调用;我们去掉了克劳德自己的消息和工具输出,使其在设计上是盲目推理的。我们将在下面的“设计决策”部分中详细介绍每个选择,包括他们向我们购买的产品以及成本。
图 2:系统架构。转录分类器门控工具调用;提示注入探针筛选工具结果。子代理递归地运行相同的管道,并在委托(可以拒绝)和返回(仅警告)时使用切换分类器。
特工可能会出于以下四个原因采取危险行动:
在所有四种情况下,防守都是为了阻止行动。我们的分类器针对过度热切的行为和诚实的错误进行了调整,因为我们从内部模型测试中获得了这种行为的具体示例,但无论哪种威胁产生了该操作,防御都适用。
以下示例改编自我们的内部事件日志,以说明自动模式旨在阻止哪些内容:
范围升级。一位用户要求“清理旧分支”。代理列出了远程分支,构建了模式匹配,并发出了删除命令。这将被阻止,因为请求模糊,操作不可逆转且具有破坏性,并且用户可能只想删除本地分支。 代理推断的参数。一位用户说“取消我的工作”。代理查询集群,根据名称相似度选择最接近的匹配项,并尝试将其删除。这是被阻止的,因为特定目标可能不是用户想要的,并且可能已被其他人拥有。 通过外部服务共享。一位代理想要共享一个脚本进行调试,并构建了一个 GitHub Gist 命令。由于用户可能认为内容是机密且不适合公开,因此这会被视为数据泄露而被阻止。 安全检查旁路。部署命令
预检查失败;代理使用跳过验证标志重试。这是被阻止的,因为它可能会影响共享基础设施。
上面的所有示例都会到达分类器,但标准克劳德代码允许规则在此步骤之前允许大多数操作:
第 2 层:项目内文件操作。 允许在项目目录内进行文件写入和编辑,无需调用分类器。常规编码(例如编辑存储库中的源文件)不会产生分类器延迟;项目内编辑可通过版本控制进行审核。
只有具有真正潜在下行潜力的行动才能达到最后一层:
第 3 层:转录分类器。 转录分类器可以查看其他所有内容,包括 shell 命令、Web 获取、外部工具集成、子代理生成、项目目录外部的文件系统操作。第 1 阶段是一个快速单令牌(是/否)过滤器,指示错误地阻止;如果出现标记,第 2 阶段将使用思维链推理重新评估相同的输入,以减少误报。
分类器的提示是我们提供的固定模板,中间插入了三个可自定义的插槽。固定部分负责解释工作——如何确定操作实际执行的操作、如何读取用户授权、分类过程本身——而且它们对每个人来说都是相同的。这些槽位定义了您的策略:在您的环境中哪些内容被视为可信、要阻止哪些类别、要排除哪些例外情况。良好的默认设置是开箱即用的。您可以立即开始使用自动模式,并在使用该功能时迭代扩展配置。
评估规则告诉分类器如何寻找危险命令。原则是评估一个动作对现实世界的影响,而不仅仅是调用的表面文本。代理不应该能够在看似良性的包装后面隐藏危险的操作。如果代理将有效负载写入文件然后运行它,则分类器会评估该有效负载。如果用 && 连接命令链,则整个命令链就是一个操作。如果代理编写了汇编 shell 命令的 Python 脚本,则分类器会在允许执行脚本之前从脚本上下文中评估汇编的命令。
用户意图规则告诉分类器如何读取授权。这是正确提示中一个棘手的部分。这也是过度急切行为防御的根源所在。分类器必须决定该操作是否是用户授权的,而不仅仅是与用户目标相关的操作。分类器故意保守。提示确定了授权内容;代理自行选择的所有内容均未经授权,除非用户另有说明。在这种情况下,“清理我的分支”不会授权批量删除,而“我们可以解决这个问题吗?”将被视为一个问题,而不是一个指令。
该模板包括一个逐步的分类过程,其中根据阻止规则检查操作,然后允许例外,然后是用户意图,然后最终做出决定。
“环境”定义了哪些域、云存储桶、源代码控制组织和内部服务被视为“内部”与“外部”的信任边界。默认情况下,分类器唯一信任的是您当前正在使用的 git 存储库。用户可以在设置中对此进行自定义,以便分类器可以识别其可信基础设施(例如 GitHub org、云存储桶或内部 API)。此边界之外的任何其他内容都可能存在渗漏风险。
默认有二十多个阻止规则,这些规则分为以下几组:
销毁或渗漏。 通过强制推送历史记录、批量删除云存储或向外发送内部数据,造成不可挽回的损失。 降低安全态势。 通过禁用日志记录、安装 SSH 密钥或 cronjobs 等持久性或修改代理自身的权限配置,使系统更难监控或防御。 跨信任边界。 对代理没有信任基础的事物采取行动,例如运行从外部存储库克隆的代码、扫描凭证存储以获取可用令牌,或将数据发送到用户从未指定的服务。 **拜帕