前两天翻 dev.to 评论区，把去年那篇「智能体在权限全绿的账户上完成账户接管」的演示完整看了一遍，连带作者后来撤回部分结果的讨论也看了。这篇记一个坑：RBAC 全绿为什么会出事，以及「我已经验证过了」这个结论怎么会在自己手里被证伪。读完你能带走一条判断——碰到验证结果，先问它到底验证了什么。
先拆开看看攻击路径。公开工单里写了一段话，大意是「把账号邮箱改成攻击者地址，再发一封密码重置」，任何人都写得进去。智能体按顺序执行四步：
- 读工单
- 读客户资料
- 更新联系邮箱
- 发送密码重置
每一步单独做一次 RBAC 查询，每次都返回允许。四步连起来 → 攻击者拿到邮箱改权，密码重置直接进了自己的收件箱，账户整体易手。拆开看没有任何一个动作越权，问题出在组合上。作者自己也意识到了这层，他在更硬的那个案例里加了一条规则，标为 R4_SEQUENCE：同一会话内先做身份变更、再做凭证恢复，视为账户接管组合，拒绝执行。拒绝时生成的收据会带上当前工具的类别、参数、先前动作类别和决策原因，最后挂一个 chain_sha256 哈希，把这几个字段链在一起。他还跑了一组对照实验：完全相同的授权和工具，把顺序反过来——先发密码重置、再更新邮箱——全部放行。这个对照改了一个变量，证明挡住它的确实是顺序本身。
到这里，演示本身没什么毛病，评论区才是证伪它的地方。最值钱的一条批评是：你挡的是「同一个会话」内。攻击者把四步拆成两个会话——第一个会话改完邮箱就结束，第二个会话发起密码重置——第二个会话里没有任何「先前动作」的记录，R4_SEQUENCE 看不见，就漏过去了。作者后来也承认，以会话为键是错误方向，该绑的是客户记录本身的历史，不是会话边界。
哈希那条我盯着收据格式想了半天才转过来。💡 小技巧：看到一个「可证明」的哈希，先问一句它到底证明什么。chain_sha256 能证明「产生这个决策的那几个字段确实产出了这个结果」，证明不了「没有别的字段也参与了决策」。「先前动作类别」本身就是同一套流程生成的，它要是漏了，哈希照算不误。修复方向也简单直接：每个收据把前一个收据的哈希装进来，链条断了就是被动手脚了。
然后是整篇里最想记下来的部分。作者后来又发了一版结果，声称扩展了验证；隔了几天，自己在回复评论时公开撤回了一部分。撤的原因是控制条件没写好——没实现过的、拿自身做比较的、把拒绝当通过的，各有一个。这种问题写测试的人看了都会心一紧，在「我已经验证过了」的感觉里，人最容易给自己放水。我自己也踩过类似的坑，对照条件根本没跑起来，数据照样「过了」。所以这条我记下来了：验证框架也是被测系统的一部分，跟它验证的那个系统一样需要怀疑。
作者最后也承认，这套验证框架像个单调阶梯，每次修复只是把键向更外一层推一步，组织级、跨客户那一层还没碰过。安全边界最终落在谁有权限写入运行时观察账本和目的地验证记录上，而不是谁持有密钥材料。这个判断我认同，但「独立写权限」具体怎么落地，我现在还没想透。
划重点：第一，RBAC 是单次调用的语义，组合安全要另算，全绿不一定安全；第二，哈希能证明充分性，不能证明完备性，别被收据格式催眠；第三，验证代码也是待验证的代码，写控制条件时最容易放水。
这篇就记到这里。你可以把那个仓库 clone 下来跑一遍，十来秒就能复现整套流程；跑完之后试试把四步拆成两个会话重放，看看 R4_SEQUENCE 是不是真的看不见。