Who verifies the verifier? 谁来验证验证本身？

On August 15, 2026, a security researcher posting as @xsser_w described a technique for bypassing a safety check reportedly built into GLM-5.3: before running a penetration test against a domain, the agent is said to shell out to dig to look up a TXT record as evidence that the user actually controls the target. Replace the local dig binary, or simply tamper with the tool call's return value, and any domain can be made to report "ownership verified." The agent, trusting what it reads, proceeds to scan a target it was never authorized to touch.2026 年 8 月 15 日，一位以 @xsser_w 为名发帖的安全研究者描述了一种绕过手法，据称针对的是 GLM-5.3 内置的一项安全检查：在对某个域名发起渗透测试之前，Agent 会调用本地 dig 命令查询 TXT 记录，以此作为"用户确实拥有这个域名"的证据。只要替换掉本地的 dig 可执行文件，或者直接篡改这次工具调用的返回值，任何域名都能被伪装成"归属验证通过"。Agent 相信了它读到的东西，于是对一个它从未被授权触碰的目标发起了扫描。

What we can and can't confirm. We have not been able to trace this report to a primary write-up, a reproduction, or a response from Z.ai, and we have not reproduced it ourselves. What is independently established is the context that makes it plausible: Z.ai's own August 2026 release notes for GLM-5.3 describe post-training that produced emergent exploit-chain reasoning the team says it did not specifically train for, including the discovery of over a thousand real vulnerabilities across Linux, WebKit, and FreeBSD during evaluation. A model with that much unsupervised offensive capability is exactly the kind of system that would need a pre-flight authorization check in front of it — and exactly the kind of system where a check built out of a locally observable tool call is worth being suspicious of. We're treating the specific report as unverified and writing about the pattern it describes, not the incident.能确认什么，不能确认什么。我们没能找到这则报告对应的原始文章、复现记录，或 Z.ai 官方的回应，我们自己也没有复现过。能独立确认的是让它显得可信的背景：Z.ai 在 2026 年 8 月为 GLM-5.3 发布的说明里提到，训练过程涌现出了团队声称并非刻意训练出来的漏洞利用链式推理能力，评测期间在 Linux、WebKit、FreeBSD 上发现了上千个真实漏洞。一个具备这种未受专门监督的攻击能力的模型，正是最需要在动手之前设一道授权检查的那种系统——也正是"检查本身建立在一次本地可观察的工具调用之上"这件事最值得警惕的那种系统。我们把这则具体报告当作未经证实的信息来处理，接下来讨论的是它描述的模式，而不是这起事件本身。

The shape of the failure, independent of whether this report is accurate不论这则报告是否准确，失效的形状是一样的

Set the specific tool aside. The described design makes one move: it lets the party whose authority is in question also produce the evidence that decides the question. The user (or whoever controls the machine the agent runs on) is exactly who a domain-ownership check exists to constrain — and, in the description, that same party can shape what the check sees. A verification step built this way isn't weak. It's decorative. It will pass every honest test run against it, because honest test runs supply honest inputs, and it will fail the one input that matters, because that input is exactly the one the design let through.先把具体是哪个工具放到一边。这种设计只做了一件事：让"权限本身有待确认的那一方"，同时成为"提供裁决证据的那一方"。用户（或者任何控制着 Agent 运行环境的人）恰恰是域名归属检查本该去约束的对象——而按报告的描述，正是同一方，决定了这项检查会看到什么。这样搭起来的验证步骤不是"弱"，而是摆设。它会通过每一次诚实的测试，因为诚实的测试提供的是诚实的输入；它会在唯一要紧的那个输入上失守，因为那个输入正是这套设计留出来的口子。

This is not a novel failure mode and it is not specific to domain verification. It is the same shape as: an approval flow that trusts a status flag the requester set; a rate limit keyed on an identifier the caller invents fresh each time; a classification label read off a field the sender wrote. Different surface, same defect — a gate whose input is chosen by the party it is meant to constrain isn't a gate.这不是一种新出现的失效模式，也不是域名验证专属的问题。它和下面这些情形是同一个形状：一个审批流程相信的是请求方自己设置的状态标记；一个限流机制的键，用的是调用方每次可以随手编造的标识符；一个分类标签，读的是发送方自己填在字段里的值。表面各不相同，缺陷是同一个——一道门控，如果它的输入是由它本该约束的那一方自己提供的，那它就不是一道门控。

Why "verify more carefully" isn't the fix为什么"验证得更仔细一点"不是答案

The intuitive patch is to make the check harder to fool — sign the DNS response, query from multiple resolvers, cross-check against a second data source. Those are real improvements and worth making. But they don't change the shape of the problem, they just raise its price. As long as the evidence a permission decision relies on passes through a channel the party being evaluated can observe or influence — a local tool call, a value echoed back from the agent's own environment, a field the agent itself populated — a sufficiently motivated party eventually finds the seam. The fix that actually closes the class of bug is architectural, not procedural: the decision that grants capability must not be made from evidence the constrained party can produce. It has to come from something fixed before the agent starts acting — issued by a party with no stake in the outcome, over a channel the agent cannot write to.直觉上的补丁是把检查做得更难骗——给 DNS 响应加签名、多找几个解析器交叉验证、再核对一个独立数据源。这些都是真实的改进，也值得做。但它们不改变问题的形状，只是抬高了绕过的成本。只要一项放行决定所依赖的证据，要经过"被评估的那一方能够观察或影响"的通道——一次本地工具调用、一个从 Agent 自己的运行环境里回传的值、一个由 Agent 自己填写的字段——一个足够有动机的人迟早会找到缝隙。真正能关掉这一整类漏洞的修法不是流程性的，而是架构性的：授予能力的那个判断，不能建立在被约束的那一方自己能够生产的证据之上。它必须来自某个在 Agent 开始行动之前就已经固定下来的东西——由一个与结果没有利害关系的一方签发，走一条 Agent 写不进去的通道。

What we checked in our own system, and what we're honest about not having我们在自己系统里查了什么，以及我们诚实承认没有的东西

PEA doesn't build penetration-testing agents, and nothing in our system does domain-ownership verification — this specific attack doesn't have a direct target in our codebase to check. What we did instead was run our own mechanical audit — the check that asks, for every decision our system makes, "what does this depend on, and who supplied it" — looking specifically for anything shaped like the pattern above: a grant of capability that reads its evidence from something the governed agent's own tool calls could produce. We found nothing of that shape currently wired into our authorization path. We're not claiming that as a permanent property; we're recording it as a checked one, which is a different and more useful claim.PEA 不做渗透测试类的 Agent，我们系统里也没有域名归属验证这个功能——这个具体的攻击手法在我们代码里没有直接对应的靶子可查。我们做的是另一件事：跑了一遍我们自己那套机械化的审计——对系统做出的每一个判断，都要问一句"它依赖什么，这个依赖是谁提供的"——专门找有没有任何地方长成上面这个形状：一次能力的授予，读取的证据来自被治理的 Agent 自己的工具调用能够产生的东西。目前接进授权路径里的，没有查到这种形状的东西。我们不把这当作一个永久不变的结论去讲，只把它记录成一个"查过、当前是干净的"的结论——这是一个更诚实、也更有用的说法。

The general answer we hold to is this: authorization has to bind at issuance — before the agent starts acting, by a party outside the agent's control — rather than at evidence time, in the middle of a run, from something the agent observed. A capability an agent is exercising should be something it was handed, not something it talked itself into believing it had earned. Under that rule, a forged tool result can, at worst, make an agent believe it is authorized. It cannot make it be authorized — those have to be different things, checked by different parties, at different times.我们坚持的一般性答案是：授权必须在签发那一刻绑定——在 Agent 开始行动之前，由一个 Agent 控制不到的一方来做——而不是在取证那一刻，在运行过程中途，凭 Agent 自己观察到的东西来判断。一个 Agent 正在行使的能力，应该是它被交付的东西，而不是它自己说服自己"我应该已经赢得了这个权力"。在这条规则下，一次被伪造的工具调用结果，最多只能让 Agent 相信自己被授权了，不能让它真的被授权——这两件事必须是不同的事，由不同的一方，在不同的时间点分别核对。

Closing结语

We're publishing this while treating the originating report as unverified, because the pattern it describes is worth naming on its own merits — and because a fabricated dig response and a fabricated approval flag are the same design mistake wearing different clothes. If the specific report turns out to be wrong in its details, the underlying question doesn't go away: when your system asks "is this allowed," where does the answer actually come from, and could the thing being asked have written it itself?我们把原始报告当作未经证实的信息来处理，仍然选择把这件事写出来，是因为它描述的这个模式，本身就值得被单独指出来——一次被伪造的 dig 响应，和一个被伪造的审批状态标记，本质上是同一个设计错误穿了不同的衣服。就算这则具体报告的细节最终被证明有出入，它背后的那个问题也不会因此消失：当你的系统问"这个动作允许吗"，这个答案究竟是从哪里来的——而被问的那一方，有没有可能，答案本来就是它自己写的？