KENSAI 研究：前置条件胜过更大的 agentic 安全宣称

KENSAI 最近几次运维给出的有用教训很简单：agentic 安全不需要更响亮的自信，它需要更严格的前置条件，只有这样结果才配得上成为“声明”。

真正的失败模式

现代安全自动化很擅长生成输出，但输出不等于真相。扫描器可以给出没有实际影响的被动发现。测试 runner 可能失败，只是因为 API 根本没启动。发布系统也可能在源目录里有文件，但线上镜像依然是旧的。

这些问题彼此不同，但根因相同：系统在没有证明上游前置条件之前，就放行了下游声明。

前置条件才是隐藏的控制平面

对 agentic 安全来说，前置条件这一层应该和模型层一样被认真对待。测试套件在报告产品失败之前，应先证明必需服务是健康的。漏洞在朝提交推进之前，应先证明真实影响，而不是把被动 recon 当成 bounty 进展。内容在宣称“已更新”之前，线上路由和派生索引必须与源文件一致。

KENSAI 正在强制什么

这没有再加一层 agent loop 那么炫，但更有价值。前置条件把自动化从一个自信的讲述者，变成一个受控的系统。

KENSAI 已经在 bug bounty 运营中执行这一模式：超范围、弱影响、纯 recon 的 finding 不能进入提交。相同模式也适用于工程和发布。路由检查胜过 dashboard 宣称，实时健康检查胜过“我觉得服务应该在”，proof gate 胜过 severity 标签。

操作原则

4月26日的测试证据再次说明了这一点。根测试套件出现了数百个失败，但第一步修复不是盲目重写应用逻辑。第一步修复是让 runner 先验证 API 依赖在线，并确认 coverage 和 e2e 命令真的存在。

一个有用的 agent 在大声说话前，应该先安静地问三个问题：前提是否存在，产物是否变化，公开表面是否证明了它？如果其中任何一个答案是否定的，正确输出就应该是带证据的 blocker，而不是成功标签。

结论

真正有用的标准很简单：只有当前提、产物和路由同时对齐时，声明才算真实。今天的工作继续把这个标准放在明面上。