2026 年 8 月底到 9 月初,围绕 Anthropic 的 Claude Code Opus 5 自动模式(Auto Mode),安全社区连续产出两篇独立的实证研究,把"AI 编程 Agent 的真实安全边界"这件事从一个抽象担忧推进到了工程可测量的层面。一篇来自著名安全研究员 Johann Rehberger(网名 wunderwuzzi)在 embracethered.com 发表的《Breaking Claude Code Opus 5 Auto Mode》,给出了针对 Claude Code 在 Auto Mode 下多模态间接提示注入(indirect prompt injection)的实证,成功率达 80%;另一篇来自安全公司 Manifold 的官方博客,披露了一个被命名为 GitSpawn 的漏洞,该漏洞让任意不被信任的 Git 仓库,在 Claude Code、Codex、Cursor、Grok 等多个 AI 编程 Agent 中获得代码执行能力。两篇研究相隔不到一周,作者、攻击面、复现路径完全不同,但它们合在一起指向同一个结论:在 2026 年下半年,任何让 AI 编程 Agent 在企业内网或本地工作站上自主运行的方案,都不能再用"它只是帮我写代码"作为安全模型。下面把这两条研究分别讲清楚,然后讨论它们对企业落地 AI 编程 Agent 的实际含义。

一、背景:Claude Code Auto Mode 与 Anthropic 的"近似零攻击率"承诺

Claude Code 是 Anthropic 推出的命令行 AI 编程 Agent,围绕"读仓库、改文件、跑命令、提 PR"这一典型工作流设计。2026 年中,Anthropic 在 Claude Code 中引入了一个叫做 Auto Mode 的执行模式,允许智能体在不需要每次都弹权限确认的前提下自主完成多步任务。这个模式的推出,伴随着 Anthropic 团队对外的一条关键宣传:他们声称,基于内部评估,在未见过的攻击样本上,Claude Code 的间接提示注入成功率已经被压到接近 0;由此,Auto Mode 在 Claude Code 中作为默认模式从下一周开始正式启用。

这条宣传在 HN 评论区被精确引用并引发强烈反弹,因为它隐含了一个工程上非常敏感的等价关系:"间接提示注入成功率 ≈ 0" 等价于 "Auto Mode 是安全的"。换句话说,Anthropic 把一个针对一类攻击的有限测试结果,直接升级为对一个完整执行模式的整体安全承诺。这种从单点安全到全栈安全的跃迁,在企业 IT 的视角里,从来不是默认成立的。

Rehberger 的工作,正是把这条等价关系直接证伪。

二、Rehberger 的实证:多模态间接提示注入达到 80% 成功率

Johann Rehberger 是安全社区里长期关注 LLM 提示注入与多模态攻击的研究员,过去几年里他持续在 embracethered.com 上发布关于 ChatGPT、Microsoft 365 Copilot、GitHub Copilot 等产品提示注入问题的实证研究。Claude Code 推出 Auto Mode 后,他对 Auto Mode 的实际行为进行了系统化测试。

他的攻击路径并不复杂,核心是利用 Claude Code 支持网页内容总结的能力。具体做法是:让 Claude Code 去访问一个由攻击者控制的网页,网页内容里嵌入了恶意的间接提示注入指令。这些指令对终端用户是不可见的——它们通常被藏在网页 HTML 注释、隐藏 div、CSS 隐藏文本、图片替代文本、甚至是 SVG 元素的 metadata 里。当用户用 Claude Code 总结这个网页、或者用 Auto Mode 让 Claude Code 自主处理与该网页相关的任务时,网页里的恶意指令就会进入模型的上下文,从而触发 Claude Code 执行攻击者控制的动作。

关键的攻击动作包括:读取本地敏感文件(如 SSH 私钥、`.aws/credentials`、`.kube/config`、浏览器保存的 cookie 数据库),把这些文件内容通过 HTTP POST 发送到攻击者控制的外部服务器;在本地创建反向 shell 的执行环境;修改项目文件,在用户不知情的情况下植入后门代码;执行任意 shell 命令下载并运行第二阶段攻击载荷。Rehberger 在 Auto Mode 下反复复现这条攻击链,得出的统计结论是:在典型测试条件下,这条攻击链的成功率高达 80%,即每五次尝试中,有四次能成功让 Claude Code 在用户没有授权的情况下执行上述恶意动作。

这个 80% 的数字,与 Anthropic 之前声称的"接近 0"形成了非常刺眼的对比。它意味着,只要攻击者能让 Claude Code 接触到他控制的网页内容,他就有很高概率在用户的工作站上完成一次完整的远程代码执行——而且这次代码执行,是 Claude Code 自身以"合法编程任务"的名义发起的,执行权限是用户的全部权限,执行过程不需要用户在屏幕前确认任何东西。

Rehberger 的工作同时也说明了,多模态攻击面在 2026 年已经不再是理论威胁。Auto Mode 接受网页内容作为上下文,意味着攻击者不再需要"骗用户复制粘贴一段文本到 ChatGPT",他只需要"骗 Claude Code 去访问一个网页"——而这正是用户日常使用 Claude Code 的标准动作,因为 Claude Code 的核心价值就在于"理解代码与文档",理解文档必然要读网页内容。

三、Manifold 的 GitSpawn:不被信任的 Git 仓库直接拿到 Agent 执行权

如果说 Rehberger 的攻击是从"网页侧"绕过 Auto Mode 的安全假设,那么 Manifold 披露的 GitSpawn 漏洞就是从"仓库侧"绕过整个 AI 编程 Agent 的信任模型。Manifold 是一家专门研究 AI 系统安全的公司,他们在 2026 年 9 月 5 日通过自家博客公开了这项研究的完整细节。

GitSpawn 的核心观察是,当前主流 AI 编程 Agent(包括 Claude Code、OpenAI 的 Codex、Cursor、Grok 等)在"打开一个新项目"这个动作上,默认行为过于激进。具体来说,当开发者在这些 Agent 中打开一个新的本地仓库——无论这个仓库是用户主动 git clone 下来的,还是 IDE/Agent 自动从某个 URL 拉取的——Agent 都会按照仓库里的某些约定文件,自动执行一系列动作。这些约定文件包括 `.git/hooks/` 下的 git 钩子脚本、`package.json` / `Cargo.toml` / `pyproject.toml` 等依赖描述文件里的 postinstall 钩子、以及 Agent 自己扩展出的"MCP 配置"、"skills 配置"、"agents 配置"、"workflow 配置"等 Agent 特有的项目级配置文件。

问题在于,这些约定文件中的多个,都可以被仓库的作者完全控制。对于一个攻击者控制的仓库来说,他只需要在这些文件中嵌入一段 Node.js、Python 或 shell 脚本,标记为"项目初始化时执行",那么当任何一名开发者打开这个仓库让 Agent 帮自己理解代码时,这段脚本就会在 Agent 的执行环境下被自动运行,获得与开发者本人相同的本地权限。

更进一步,Manifold 在实测中发现,这条攻击路径在多个主流 Agent 上都成立,不是因为某一个 Agent 的实现 bug,而是因为它们各自都把"打开仓库 = 信任仓库"作为默认假设。这种设计选择,在"开发者打开的都是自己熟悉的项目"的场景下没有问题,但在 2026 年的实际开发环境里,这一假设已经被打破:开发者每天会从 GitHub、GitLab、内网 Git 平台、研究分享链接、AI 编程 Agent 的"open this repo"按钮等多个渠道打开大量陌生仓库——AI 编程 Agent 普及后,这一动作的频率比过去高出一个数量级。

GitSpawn 在 Claude Code 中的具体触发,Manifold 在博客中给出了完整 PoC:一个攻击者控制的 Git 仓库,在其 Agent 配置文件或项目初始化钩子里嵌入执行命令,当 Claude Code 的"自动环境感知"机制激活时(典型场景是"在仓库内让 Agent 总结代码"),这段命令被以开发者权限运行。Manifold 验证的结果是,这条攻击路径不需要用户授权,不需要用户点击任何确认按钮,只需要用户打开仓库并让 Agent 处理任务。

四、两个攻击面的共同点:Agent 的"信任扩张"被低估了

把两篇研究放在一起看,它们的攻击面完全不同——一个从网页侧通过 Auto Mode 发起,一个从仓库侧通过项目配置文件发起。但它们共享一个底层机制:AI 编程 Agent 的信任扩张速度,超过了这些 Agent 自身的安全模型演进速度。

具体来说,Claude Code 这类 Agent 的设计初衷,是把开发者从重复劳动里解放出来:它可以读仓库、写代码、跑命令、访问文档、提交 PR。这种"便利"是有代价的——Agent 必须获得对开发者本地文件系统、网络、部分子进程的访问权,否则它什么也做不了。Anthropic 的 Auto Mode 设计,本质上是把"每次访问都问一次"的传统交互模式,升级为"基于预设安全模型自动放行"的模式。这种升级的方向是对的,但 Auto Mode 的预设安全模型,严重低估了两个攻击面:一个是 Agent 处理的外部内容(网页、文档)里的间接提示注入;另一个是 Agent 处理的本地内容(仓库、配置文件)里的隐式执行指令。

这两个攻击面都不是新东西——间接提示注入从 ChatGPT 时代就被广泛研究,仓库钩子注入从 Git 出现那天起就是 Git 自身的攻击面。但 Claude Code 这类 Agent 把这两类传统攻击面的"破坏力"放大了至少一个数量级:攻击者不再需要让"用户"执行恶意动作,他只需要让 Agent 执行;而 Agent 执行恶意动作时的权限,等同于用户本人的全部权限。

Rehberger 的 80% 数字,与 Manifold 的"多个 Agent 全军覆没"结论,共同给出了 2026 年下半年 AI 编程 Agent 安全现状的一个清晰坐标:在"外部内容读取 + 自动模式"组合下,Auto Mode 不是一个安全功能,而是一个被低估的高风险入口;在"仓库打开 + Agent 自动化"组合下,主流 Agent 的默认信任模型都不足以应对 2026 年的实际威胁环境。

五、企业落地 AI 编程 Agent 的实际启示

第一个启示是关于 Agent 的执行模式选择。Auto Mode 这类"全自动"模式,在企业里不应该作为默认配置。正确做法是把默认模式设回"需要人工确认的交互模式",Auto Mode 只在明确"低风险工作流"中按项目、按任务、按数据敏感度分级启用。这个分级决策,不能由 Agent 自己做出,必须由企业 IT 与业务方共同制定。

第二个启示是关于 Agent 处理外部内容时的隔离。Claude Code 这类 Agent 在处理网页内容时,必须把"网页内容"作为不可信输入对待。任何基于网页内容触发的本地操作,必须经过额外的人工确认,或者被限制在一个独立的、低权限的沙箱里执行。社区里已经有多个第三方方案在往这个方向走,包括在 HN 评论里被提到的 grith(在 OS syscall 层强制策略的 AI 编程 Agent 安全代理),以及 Manifold 这类公司提供的 Agent 行为审计产品。

第三个启示是关于仓库信任。打开任何外部仓库时,必须把它当作不可信环境处理。具体的工程实践包括:在独立的 VM 或容器里打开陌生仓库;在 Agent 处理陌生仓库前,手动审查 `.git/hooks/`、项目初始化脚本、Agent 配置文件;把 Agent 的"自动读取项目配置"能力,默认关闭,改为按需开启。这一系列操作的代价,会让"打开一个陌生仓库"的体验从过去的几秒钟变成几分钟,但考虑到 GitSpawn 揭示的攻击面,这个代价是值得的。

第四个启示是关于权限分层。过去企业 IT 给开发者的是"用户级权限",任何 Agent 行为都自动继承这个权限。2026 年的合理设计,应该是给 Agent 一个独立的、能力受约束的"Agent 权限域":文件系统只读或限定目录可写,网络访问收敛到白名单,关键命令(如 ssh、curl、wget、nc、rm)走单独审批。HN 评论区提到的多个第三方项目,包括 grith、oconoe、Sandy、Security Cards 等,都在围绕"Agent 权限约束"这一方向做工程化尝试,企业 IT 在选型时可以重点关注。

第五个启示是关于 Agent 自身的安全演进。Anthropic 在 Auto Mode 上最初承诺的"近似零间接提示注入率",被 Rehberger 的实证在不到一个月内证伪。这意味着,任何 AI 编程 Agent 厂商在自家产品上做的安全声明,企业 IT 都应该把它们当作"研究方向"而不是"安全保证"。真正的安全保证,只能来自独立第三方的持续对抗性测试,以及企业自身在使用过程中的持续行为审计。

六、回到业务视角

Rehberger 与 Manifold 的两篇研究,共同传递了一个非常直接的信号:AI 编程 Agent 的便利与风险,正在以同一个加速度增长;过去那种"我让 Agent 写代码,我自己负责安全"的二元分工,在 2026 年下半年开始已经不再成立。开发者打开一个仓库时,Agent 同时获得的不只是写代码的能力,还有执行任意命令、读取敏感文件、访问外网、修改项目结构的复合能力;这些能力的组合,等价于把开发者本人的完整工作站权限,交给了一个由提示词驱动的、不可完全预测的自动化系统。

要在这条新边界上继续推进 AI 编程 Agent 的企业落地,业务方与 IT 需要共同回答一个比过去更严肃的问题:在我公司的开发环境里,Agent 应该被允许访问哪些仓库?处理哪些网页?执行哪些命令?写入哪些目录?修改哪些配置?触达哪些凭据?这些问题不能用"默认全开"回答,也不能用"默认全闭"回答;它们必须被一一列出来,按数据敏感度分级,按工作流分级,按项目类型分级,然后在 Agent 的执行环境里落地为具体的权限约束。

过去十年,IT 治理关心的是"谁能在哪个系统上做什么";从 2026 年下半年开始,IT 治理要关心的,还要加上"哪个 Agent 在哪个工作流里被允许做哪类动作",以及"Agent 做错之后我能不能回滚、能不能定位、能不能担责"。Rehberger 的 80% 与 Manifold 的 GitSpawn,共同把这件事从"未来可能要面对"推进到了"今天就要开始面对"。