Claude Code 实测注入成功率达 80%，沙箱与权限规则防护指南

Anthropic 委托第三方机构 Trajectory Labs 开展的安全评测显示，Claude Code 的 Opus 5 模型在 Auto Mode（自动模式）下应对 72 个间接提示注入场景时，攻击成功率为 0.00%。然而，安全研究员 Johann Rehberger 在 2026 年 8 月下旬公布的定向攻击链实测中，该模式下的恶意代码执行与外联成功率达到了 60% 至 80%。表面上看这是安全分类器对新型提示注入的漏判，本质上则是开发者将模型内置的便利性分类器误当成了操作系统级的安全边界。

Auto Mode 旨在通过后台分类器自动审批常规 Bash 命令与文件修改，免去频繁的人工弹窗确认。当恶意设计隐藏在看似合理的良性开发行为中时，模型自身推导出的“最优解决方案”恰恰会绕过安全审查。在无人值守编码（vibe coding）与智能体自动化普及的背景下，理清这套攻击链路并构建多层防御体系，是保障开发环境安全的前提。

攻击链拆解：良性行为如何组合成系统后门

Rehberger 披露的利用链不包含任何直接覆盖系统指令的强硬提示词，而是通过构造特定环境，诱导 Claude 做出符合其安全直觉却致命的决策。整个链条由 5 个看似合规的步骤构成：

第一步，诱导工具切换。攻击者诱导用户执行总结网页的任务。恶意服务器针对 Claude 内置的 WebFetch 请求返回 HTTP 415（不支持的媒体类型）错误，迫使 Claude 自主选择 curl 命令作为达成目标的最优替代路径。

第二步，引入受污染的工作区。curl 顺着 HTTP 303 重定向下载一个伪装成数据归档的 ZIP 包并解压。压缩包内包含常规说明文件、数据记录以及一个攻击者预置的 macOS 二进制文件 decoder-darwin 与恶意 Python 脚本 struct.py。

第三步，激发模型的“安全替代”机制。Claude 识别出 decoder-darwin 存在执行风险而拒绝运行，这完全符合攻击者的预判。为了完成解密任务，Claude 选择在当前解压目录内自行编写一段纯 Python 解码脚本。

第四步，触发模块遮蔽（Module Shadowing）。Claude 编写的脚本中包含 import base64，而 Python 标准库的 base64 内部依赖 struct 模块。根据 Python 的导入优先级规则，当前工作目录下的恶意 struct.py 优先于系统标准库被加载。该恶意文件在模块导入阶段即触发执行，通过独立子进程下载原生 Payload，回传受害者环境信息，并弹出计算器证明权限获取。

第五步，建立持久化逃逸。恶意进程完全脱离 Claude Code 会话独立运行，即使主会话结束，后台后门依然存活。


[用户指令: Summarize URL]
│
▼
[恶意网站返回 HTTP 415] ──► [Claude 改用 curl 下载 ZIP 压缩包]
│
▼
[Claude 拒绝运行预置二进制] ──► [自主编写 Python 解码脚本并运行]
│
▼
[运行引发模块遮蔽] ──► [加载恶意 struct.py 并派生独立恶意子进程]

在测试变体中，恶意 struct.py 还可以直接启动无界面的 Claude Code 实例（claude -p）。这种子智能体继承了系统的工具访问权限，能以自动化名义在工作区外写入文件或执行探测，实测写文件成功率达 80%。更严峻的是，当 Claude 在事后检测到异常并尝试执行 kill 终止恶意进程时，Auto Mode 的安全分类器反而将该清理命令判定为高风险操作并予以拦截，安全机制反向阻碍了应急响应。

攻击阶段与防御盲区全景对照

这套攻击链之所以能够穿透 Auto Mode，核心在于安全评估与底层执行之间存在上下文割裂。以下表格梳理了攻击各环节的核心成因与残留风险：

阶段	核心问题	留下的硬伤
诱导与下载阶段	分类器允许良性工具链（如 curl 跟随重定向）自由下载未知归档，缺乏网络出口过滤。	不可信文件进入工作目录，工作空间被注入恶意依赖与模块遮蔽载荷。
执行与遮蔽阶段	模型信任自身生成的代码，却忽略了 Python 等运行时默认从当前目录解析依赖的机制。	触发隐式导入漏洞，恶意模块以合法身份拉起脱钩子进程，绕过分类器审查。
失控与清理阶段	分类器对后续脱钩子进程缺乏监控，且将模型的自愈清理操作误判为危险行为。	恶意进程持续驻留，模型发出的自我修复与阻断指令被自身安全策略锁死。

防护配置：用沙箱与权限规则构建纵深防御

依赖单一的 LLM 分类器无法提供确定性的安全保障。防御间接提示注入必须遵循最小权限原则，将策略前置到确定性规则中。

1. 配置确定性拦截规则（permissions.deny）

permissions.deny 规则具有最高优先级，在 Auto Mode 分类器介入之前求值且不可被模型覆盖。企业或个人应在全局配置中锁定高危行为。

在 ~/.claude/settings.json 或组织托管配置中添加：


{
"permissions": {
"deny": [
"Bash(curl * | sh)",
"Bash(wget * | bash)",
"Bash(nc *)",
"Bash(ncat *)",
"Bash(/bin/sh -c *)",
"Bash(python* -m http.server*)"
]
}
}

2. 设置人工复核断点（permissions.ask）

对于涉及外部状态变更的操作，通过 permissions.ask 强制弹出确认，阻止 Auto Mode 静默批准：


{
"permissions": {
"ask": [
"Bash(git push *)",
"Bash(gh pr create *)",
"Bash(aws *)",
"Bash(gcloud *)",
"Bash(kubectl *)",
"Bash(ssh *)"
]
}
}

3. 配置可信环境范围（autoMode.environment）

明确告知分类器哪些域名与仓库属于可信资产，未登记的目标将被从严处理。该配置仅从全局配置（~/.claude/settings.json）或托管策略读取，不会加载项目目录下的 .claude/settings.json，防止恶意仓库注入篡改。


{
"autoMode": {
"environment": {
"trustedDomains": [
"github.com",
"api.internal.company.com",
"pypi.org"
],
"trustedRepositories": [
"my-org/*"
]
}
}
}

4. 强制隔离模式运行 Python 脚本

模块遮蔽攻击依赖工作区本地路径的导入优先级。在提示词约定或系统别名中，强制 Python 使用 -I（隔离模式）运行临时代码。隔离模式下 Python 会忽略当前目录与用户环境变量，阻断递归遮蔽：


# 错误示范：优先加载当前目录下的 struct.py
python3 decode_data.py

# 安全实践：忽略当前目录并隔离环境
python3 -I decode_data.py

5. 系统级容器与网络隔离清单

对于无人值守运行的 Agent，容器隔离是不可省略的底线：

网络出口限制：在 Docker 或虚拟化网络中使用 iptables 仅开放必需的包管理器与代码托管平台白名单。
凭据解耦：切勿将宿主机的 ~/.ssh、~/.aws/credentials 或环境变量 API Key 挂载进 Agent 所在的工作容器。
启用 Bash 沙箱：结合 macOS 的 sandbox-exec 或 Linux 命名空间（Namespace），限制进程派生与跨目录读写能力。

权限模式对比与安全边界划分

Claude Code 提供了多档权限模式，不同模式对应不同的信任层级与使用场景：


[安全级别递增]
bypassPermissions ──► auto ──► dontAsk ──► acceptEdits ──► plan ──► default(Manual)
(仅限隔离容器)         (安全分类器) (预设白名单) (仅编辑文件)   (只读分析) (全手动审批)

default (Manual)：只读模式，所有命令和编辑均需人工审批，适用于高敏感审计场景。
plan：先分析后修改，生成变更方案前不执行任何写操作。
acceptEdits：自动放行文件修改，但在执行 Bash 命令时依然强制弹窗。
dontAsk：仅允许预先在白名单中定义的工具与命令，适合 CI/CD 自动化流水线。
auto：全自动模式，由分类器在后台实施安全检查并放行良性操作，兼顾效率与常规防护。
bypassPermissions：完全放行所有操作，仅应在无外网权限的临时销毁型容器或轻量 VM 内开启。

无论处于何种模式（bypassPermissions 除外），针对根目录、用户主目录（Home）以及工作区顶层目录的 rm / rmdir 破坏性指令，均受到内核级硬编码保护，不会被自动放行。

综合判断

针对 Anthropic 的 0.00% 基准数据与安全社区的 80% 实测成功率，二者并不矛盾：静态基准仅能覆盖已知的 72 个固定提示注入场景，而针对性的攻击链则利用了动态决策和环境协同漏洞。

Auto Mode 不是操作系统的安全边界，而是开发体验的增强层。任何试图完全依靠大模型自我审查看守执行权限的架构都是不可靠的。真正的安全防御应当建立在确定性的 permissions.deny 拦截、明确的 permissions.ask 检查点、隔离的 python3 -I 运行时以及系统级容器沙箱之上。

未解决的问题

当编码智能体在本地自主编写胶水代码来解决数据格式转换问题时，动态脚本语言（如 Python、Node.js）内在的依赖解析路径机制与环境变量注入风险，目前尚无法仅靠静态规则在不降低编码自由度的情况下完全消除。如何在保证智能体自动化灵活性的同时，为临时生成的动态脚本提供零开销的沙箱封装，仍是一个悬而未决的工程挑战。

引用来源

Simon Willison, “Breaking Claude Code Opus 5 Auto Mode”, 2026-08-27, https://simonwillison.net/2026/Aug/27/breaking-claude-code-opus-5-auto-mode/
Johann Rehberger (Embrace The Red), “Breaking Claude Code Opus 5 Auto Mode”, 2026-08-26, https://embracethered.com/blog/posts/2026/breaking-claude-code-opus-5-and-automode/
Claude Code Docs, “Configure auto mode”, 2026-08-20, https://code.claude.com/docs/en/auto-mode-config
Claude Code Docs, “Choose a permission mode”, 2026-08-22, https://code.claude.com/docs/en/permission-modes
Claude Blog, “Auto Mode default announcement and evaluation”, 2026-08-15, https://claude.com/blog/auto-mode-default-in-claude-code