标题和作者
本文探讨了 Claude Code 引入的一项新功能——Auto mode，这是一种旨在替代 --dangerously-skip-permissions 参数的安全权限管理模式。作者 Simon Willison 是一名知名的开发者和安全研究员，他长期关注 AI 在代码生成和网络安全领域的应用，本文详细分析了该功能的实现机制及其安全性影响。
摘要
本文介绍了 Claude Code 新推出的 Auto mode 功能，旨在为开发者提供一种介于完全自动和手动审批之间的权限管理方案。此前，开发者若要完全自动化操作，只能使用 --dangerously-skip-permissions 参数，但这会绕过所有安全检查。Auto mode 的出现填补了这一空白，它利用 Claude Sonnet 4.6 模型在执行具体操作前进行审查和拦截。具体实现上，系统拥有一套包含“允许”和“软拒绝”的默认规则集，能够识别并阻止越权操作、对未识别基础设施的攻击以及恶意内容驱动的行动。尽管该功能通过预设规则提升了安全性，但其效果依赖于 AI 的非确定性判断，仍存在被绕过的风险。
此外，本文特别解释了 Auto mode 的工作原理和核心概念。Auto mode 会在每次行动执行前，由一个独立的分类器模型（基于 Claude Sonnet 4.6）分析对话上下文，判断行动是否符合用户意图。例如，它允许在项目范围内进行本地文件操作和安装已声明的依赖项，但会阻止强制推送到默认分支或执行外部代码。对于不熟悉的读者，需要理解“Project scope”指的是会话启动时的仓库范围，超出此范围（如访问系统根目录或 /etc）被视为权限升级。同时，理解“Supply chain attacks”（供应链攻击）至关重要，即攻击者通过在依赖包中植入恶意代码来破坏系统，Auto mode 的默认允许列表仅针对已声明的依赖项安装，无法防范未锁定依赖项的恶意包。
主要主题和概念
Auto mode 的工作机制
- What：Auto mode 是一种新的权限模式，它允许 Claude 在执行代码操作前，自动做出安全决策，而无需用户逐一确认。
- Why：传统的
--dangerously-skip-permissions模式虽然完全自动化，但缺乏安全性；而手动审批模式则效率低下。Auto mode 旨在解决这种安全与效率的平衡问题。 - How：系统利用 Claude Sonnet 4.6 模型作为独立的分类器，在每次行动运行前，根据对话记录和预设的安全规则来判断该行动是否合法。如果符合“允许”列表中的规则，则执行；否则，根据“软拒绝”列表进行拦截。
安全规则的分类与边界
- What：系统通过“允许”和“软拒绝”两个列表来界定哪些操作是安全的，哪些是危险的。
- Why：为了防止编码代理执行破坏性操作（如删除云存储文件）或越权访问（如访问系统目录），同时保留必要的开发便利性。
- How：系统通过分析操作的具体特征进行分类。例如，对于“本地操作”，系统严格限制在项目仓库内，并区分可逆与不可逆的破坏；对于“Git 操作”，系统阻止强制推送和直接推送到主分支。对于“声明的依赖项”，系统只允许通过读取 manifest 文件来安装，防止拼写错误劫持。
对 AI 驱动安全保护的质疑
- What：作者对基于 AI 的安全保护机制的有效性提出了质疑。
- Why：AI 模型本质上是概率性的，而非确定性的，且可能因上下文不足而无法识别潜在风险。
- How：作者指出，Auto mode 的分类器可能无法识别模糊的用户意图，或者因缺乏环境上下文而放行危险操作。例如，它无法防范利用 LiteLLM 依赖包漏洞进行的供应链攻击。作者认为，相比于基于规则的确定性沙箱，这种基于提示的 AI 保护在安全性上存在不足。
此外，本节涉及一些专业术语，如“Prompt injection”（提示注入），指攻击者通过精心构造的输入诱导 AI 执行非预期的指令；“Supply chain attacks”（供应链攻击），指攻击者破坏软件供应链，在依赖包中植入恶意代码；“Typosquatting”（拼写错误劫持），指攻击者注册与流行软件名称相似但略有不同的域名，诱骗用户下载恶意软件。
重要引文
- 论点：基于 AI 的自动权限保护机制存在局限性，无法提供 100% 的安全性。
- 论据：1. 文档明确指出，当用户意图模糊或 Claude 缺乏足够的环境上下文时，分类器仍可能允许某些风险操作；2. 实际发生的 LiteLLM 供应链攻击案例表明，默认的允许列表（如允许安装
requirements.txt中的包）可能无法防范恶意依赖项；3. AI 模型本质上的非确定性导致其无法像确定性规则那样保证绝对安全。 - 论证：因为 AI 分类器依赖于对文本的理解，而文本中可能包含隐藏的攻击意图或模糊的指令，且它无法像人类管理员那样深入理解复杂的系统环境，所以它必然会漏掉某些风险。即使有大量的默认规则，如果用户或攻击者能利用 AI 判断的不确定性，就可能导致系统被入侵。因此，作者认为这种模式不如传统的确定性沙箱可靠。
在本节中，可能存在的困惑点在于“供应链攻击”与“Auto mode 允许列表”的关系。读者可能误以为 Auto mode 能防御所有依赖项风险，但实际上它仅防御“已声明”且通过标准命令安装的依赖项，对于未锁定版本的依赖包（如 pip install foo），系统默认是允许的，这正是供应链攻击的常见入口。
总结
本文最核心的内容是揭示了 Claude Code 新推出的 Auto mode 的工作原理及其潜在的安全隐患。作为 --dangerously-skip-permissions 的替代方案，Auto mode 引入了一个基于 Claude Sonnet 4.6 的分类器，通过“允许”和“软拒绝”规则集来实现自动化审批。它成功拦截了如强制 Git 推送、外部代码执行和云存储大规模删除等高风险行为，同时保留了项目范围内的本地操作和声明依赖安装的便利性。然而，文章的总结部分也强调了该模式最大的软肋：AI 的非确定性本质。Simon Willison 指出，由于意图模糊和上下文缺失，该系统无法完全防止供应链攻击（如 LiteLLM 事件），且在安全性上不如传统的确定性沙箱。未来的改进方向可能需要结合更严格的沙箱机制，或者对 AI 的判断过程进行更透明的审计，以确保在追求自动化效率的同时，不会牺牲系统的安全性。