编码智能体自动放行配置可能成为攻击入口

Full translation

完整中文译文

书籍：Prompt Engineering Pocket Guide

我的其他作品：Thinking in Go（两册系列）——Go 编程完整指南 + Go 六边形架构

我的项目：Hermes IDE | GitHub——为使用 Claude Code 等 AI 编程工具交付软件的开发者打造的 IDE

关于我：xgabriel.com | GitHub

这次漏洞利用只需要一行 JSON。

"chat.tools.autoApprove": true

攻击者在源文件中植入 prompt injection，指示 GitHub Copilot 把这一行写进 VS Code 的 settings.json。设置生效后，Agent 使用工具前就不再征求许可，注入的指令也就能够在开发者的机器上运行 shell 命令。Embrace The Red 的研究员于 2025 年 6 月向 Microsoft 报告了这个问题，随后 Microsoft 在当年 8 月的补丁星期二以 CVE-2025-53773 修复了它。漏洞分析文章列出了这类注入可能藏身的位置：“源代码文件、网页、GitHub issue、工具调用响应，或其他内容。”

同年 8 月稍晚些时候，s1ngularity 恶意软件通过 npm 上遭入侵的 Nx 包传播。Wiz 的分析指出，它会在每台受感染的机器上寻找 AI CLI，并以 claude --dangerously-skip-permissions、gemini --yolo 和 q chat --trust-all-tools 的方式运行它们。

两次攻击的第一步，都是关掉询问权限的环节。我的立场是：一旦你的编程 Agent 停下来询问，就只能由你回答。这意味着，不能交给包装工具，不能交给“只要没命中拒绝列表就放行”的 hook，也不能交给监视终端并自动发送 y 的脚本。

权限提示，是注入文本触及 shell 的地方

编程 Agent 整天都在读取并非由你编写的文本：README、issue、文档页面、工具输出。其中任何一处都可能夹带指令。2025 年 5 月，Invariant Labs 展示了一次攻击：公开仓库中的恶意 GitHub issue 劫持了连接 GitHub MCP server 的 Agent，让它泄露用户私有仓库中的数据。触发攻击的，只是一个查看未关闭 issue 的普通请求。研究人员这样解释它为何奏效：“许多用户在使用 Agent 时，已经选择了‘Always Allow’确认策略，不再逐项监控操作。”

厂商也在自己的文档中给出了同样的警告。Claude Code 的权限模式页面明确指出，bypassPermissions“无法防范 prompt injection 或非预期操作”，只能用于“容器、VM，或无法访问互联网的开发容器等隔离环境”。OpenAI 的 Codex 文档则把 --yolo 标为“Dangerous full access”：没有 sandbox，没有审批，不建议使用。

所以，权限提示就是攻击者控制的文本转变成你机器上实际命令的关口。

没错，你确实会不看就点“Allow”。Anthropic 测过了

反对我这一立场的最有力证据，恰恰来自 Anthropic。它介绍 auto mode 的工程文章指出，“用户会接受 93% 的”手动审批提示。8 月的公告则把这个比例写成了 97%。在一项有 1,053 名付费测试者参与的受控研究中，“人工审查只识别出 13.6% 的危险命令，而 auto mode 识别出了 89%”。当用户此前已经处理过至少 50 次提示时，人工拦截率会降到“大约 5%”。

如果你对所有请求都点同意，那你就是一个反应更慢的自动审批器。

但再看看这项研究实际测量的是什么：把一条危险命令藏在日常提示中，而随着提示不断累积，识别率持续下降。这说明问题出在数量上，那就减少数量：少弹一些提示，把真正的注意力留给剩下的那些。

审批疲劳确实存在。把按钮交给 Agent 之外的机器，并不能解决它。

有两种不同的东西都被称为“自动审批”，但它们值得得到不同的回答。

第一种是 Agent 内部的策略，用来决定哪些操作根本需要询问：允许规则、拒绝规则、sandbox，以及厂商自己的审查器。根据文档，从 v2.1.283 开始，auto mode 已成为 Claude Code 在终端和 VS Code 中的初始模式。Codex 也有 auto-review，需要通过 approvals_reviewer = "auto_review" 主动启用。两种审查器都内置在 Agent 中，而且 Anthropic 的设计专门考虑了注入问题：它的分类器“只能看到用户消息和 Agent 的工具调用”，完全看不到工具结果；工具输出则由另一个独立的探测机制扫描。

两者在连续拦截后，都会把决定权交回给你。Claude Code 连续拦截 3 次，或在一次会话中累计拦截 20 次后，就会升级为人工处理；Codex 则会在连续拒绝 3 次，或最近 50 次审查中拒绝 10 次后，中断当前轮次。

它们的开发者也公开了漏检情况。Anthropic 把对真实的、超出用户意图的操作所测得的 17% 漏检率称为“诚实的数字”，并表示 auto mode“不能直接替代对高风险基础设施的认真人工审查”。OpenAI 则表示，auto-review 并非“确定性的安全保证”，“仍然可能犯错，尤其是在对抗性或不寻常的情境下”。

你可以质疑这些数字。至少，它们是公开的。

第二种则是 Agent 外部的工具，替你回答 Agent 已经决定展示给你的权限提示：比如读取屏幕并发送按键的脚本，或者对拒绝列表未捕获的一切操作都返回“allow”的 hook。我的界线就画在这里。

出现在你面前的权限提示，已经经过了 Agent 自身的策略筛选。规则没有覆盖它，审查器如果存在，也把它交回来了。外部工具替你作答，批准的恰好就是 Agent 标记为不确定的那批操作。

拒绝列表靠不住。2025 年 7 月，Backslash Security 找到了四种绕过 Cursor 自动运行拒绝列表的方法，其中包括 Base64 编码、子 shell，以及 "e"cho 这样的引号技巧。他们把当时实现的拒绝列表称为“严重不足”，并建议：“改用允许列表设置。”

审批工具的配置也是文件，而 Copilot 的漏洞已经说明：只要 Agent 能写入某个文件，注入指令就可能让它写入这个文件。Claude Code 把这视为真实风险：.vscode、.git 和 .claude 都属于受保护路径，允许规则不会预先批准对这些路径的写入；在 Manual mode 下，写入它们始终会触发询问。

用集中分流解决疲劳，别替人作答

先从源头减少提示，也就是在 Agent 内部处理。在 Claude Code 中，通过 .claude/settings.json 允许那些日常、低风险的命令，拒绝危险命令。下面的规则语法遵循权限文档：

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)"
    ]
  }
}

拒绝规则在所有模式下都会生效，包括 bypassPermissions。不过，要把这类模式匹配规则当成减速带：权限文档明确列出，git -C . push origin main 就是上述 push 规则会漏掉的一种变体，因此还要配合 sandbox 使用。

在 Codex 中，sandbox 文档为风险较低的本地自动化推荐了下面这组设置：

sandbox_mode = "workspace-write"
approval_policy = "on-request"

sandbox 允许的命令无需询问即可运行，写入范围限制在工作区内，网络默认关闭。只有越过边界的操作才会交给你。

如果你希望 Agent 完全无人值守，就把它放在无法伤害你的地方：按照两家厂商文档中的做法，在容器或 VM 里运行 Agent 的完全访问模式；或者，如果你接受厂商公开的漏检率，也可以使用其内置审查器。对于 CI，Claude Code 的 --permission-mode dontAsk 配合 --allowedTools，会直接拒绝列表之外的所有操作，而不会发起询问。

然后，把剩下的请求集中起来处理。前面提到的 5% 拦截率，出现在用户已经处理过至少 50 次提示之后。如果同时运行三个 Agent，你就会收到三股请求，它们分别在不同终端中打断你。把这些请求放进同一个队列，优先处理等待最久的那个。专门坐下来处理它们，逐条阅读命令，遇到不认识的就拒绝。

一个队列，先来先处理，由人把关。

Hermes 如何处理权限提示：不作答

Hermes IDE 是我开发的，所以阅读这一节时，请把这一点考虑在内。它的设计原则明确写着：“只观察，绝不代答。Hermes 读取 Agent 的信号，但绝不会代你回答权限提示或问题。”还有：“Hermes 绝不会自行向终端输入内容；唯一允许的写入，是由你亲自触发的一行可见内容。”

它做的是请求分流。默认情况下，每个 Agent 都运行在真实终端中；Claude 还提供了可选的 Agent 视图，改为渲染对话内容。每个会话都会显示一种状态：working、needs approval、asked you、done、error 或 idle；如果状态是推测出来的，也会附上说明。注意事项收件箱会统计有多少 Agent 正在等你处理。按下 ⌘I，在 Windows 和 Linux 上则是 Ctrl+Shift+I，就会跳转到等待最久的 Agent；你在它自己的会话里，面对它原本的问题作答。Agent 被阻塞或完成任务时会触发通知，但你正在查看的会话不会重复通知。

它不做什么：Hermes 不会为 Agent 提供 sandbox，也不会执行自己的一套权限规则。终端会话的运行方式与其他终端完全相同，因此，限制已获批准命令的，仍然是 Agent 自己的 sandbox 和规则。请先把这些配置好。Hermes 免费，采用 BSL 1.1 许可证开放源码，可运行于 macOS、Windows 和 Linux。它与 Nous Research、Anthropic、OpenAI 或任何 Agent 厂商都没有关联。你可以下载使用，也可以阅读源码。

你的界线画在哪里？你能接受厂商内置的审查器，却不能接受第三方自动点同意的脚本？还是你会把一切都放进容器，彻底跳过提示？欢迎在评论区告诉我。

prompt injection 正是权限提示之所以重要的原因。我的 Prompt Engineering Pocket Guide 除了介绍 system prompt 和 context engineering，也讨论了 prompt injection。如果你同时运行多个 Agent，Hermes IDE 可以把所有等你处理的提示集中到一处，并把回答权留给你。

如需进一步处理，你可以考虑屏蔽此人和／或举报滥用行为。