对抗性审计
这不是一次审计，而是一种纪律。
任何人都能跑一次安全检查，然后截一张全绿的图。更难的是随着系统增长不断重新攻击自己的系统，并且每次都得到同样的结果。最近一轮：一次50 个智能体的审计，修复已上线，然后是一次独立的14 个视角的对抗性复审，每条发现都必须先经受住质疑者的检验才算数。守得住的，就是守得住。
最近一次审计覆盖了什么
先讲范围、方法和局限，再讲智能体数量。
摘自最近一次核心审计，日期为 2026 年 9 月 25 日。智能体数量只说明审计有多忙，不说明审计有多好，所以下面说明这次审计实际做了什么。
- 代码
- 核心包，162 个文件、17,362 行，固定在某一次提交，外加判断每条路径是否在线所需的网关代码。
- 访问权限
- 完整源代码，以及由迁移脚本新建的数据库。不是生产数据库；仅生产环境才有的设置被标为未验证，之后由我自己检查。
- 方法
- 四名审查者各自完整阅读一个层。一名负责人对照文件复核每个发现，并实际运行每个关于时序或模式的论断，之后才计入。
- 严重程度
- HIGH 指在线路径上漏判危机或拒绝服务、跨租户泄露，或资金损失。中级别指失效时放行的防护、凭空产生的额度，或被静默丢弃的数据。每个发现还会标注为 live 或 latent：即今天在生产中是否可触达。
- 分歧
- 负责人无法复现的发现会被丢弃或标为未验证，而不是被平均进去。
- 结果
- 2 个 HIGH 和 13 个中级别发现。全部在当天修复，每个都配有一个在旧代码上失败的测试，并在 CI 中重新运行了完整测试套件。
- 未覆盖
- 约 7,000 行翻译后安全字符串的准确性、生产数据库、Web 服务器配置，以及仍未关闭的 17 个低级别发现。
由我指导的 AI 审查者自行执行，不是独立第三方保证。
节奏
一轮又一轮地重新攻击。下面每个跨租户发现都是由审计发现的，不是客户报告的，并且都已修复。
✓ 核心资产每一轮都守住了，隔离 · 资金 · 治理 · SSRF · 令牌域
其中三个真实案例
HIGH 跨租户会话泄露
聊天记忆按发送者而不是按租户作为键，因此一位通过平台给两家商家发过消息的客人，其中一家的对话可能出现在另一家的提示词中。已修复：历史记录在存储层按商家作为键，并加了一个测试，若旧键复现就会失败。这是审计发现的，不是客户报告的。
HIGH 提供方耗尽调用方的额度
在跨租户工具经济中，提供方可以在调用方开始使用某个已授权工具之后提高其价格，从而耗尽对方余额。已修复：调用方按每次调用同意价格，失败即关闭，未同意则不收费，在任何一笔额度转移之前强制执行。
高 计量背后的危机
计费检查在危机检查之前运行，因此一位陷入困境的顾客给一家额度耗尽的商家发消息时，得到的是“不可用”，而不是危机热线。已修复：危机服务免费提供，优先于所有上限和收费，覆盖每一个面向顾客的界面。
审查视角涵盖隔离 · 认证 · 注入 · 资金 · 治理 · 预订 · 渠道 · 自主常驻智能体 · 数据权利（GDPR/PECR） · 站点生成器 · 前端 · 运维。每一轮的结论：没有遗留的严重级问题；租户隔离和 XSS 攻击面复查结果干净；没有在线存在的认证绕过：每个已确认的边缘问题都已修复并重新部署。
如实的数字
每个数字都已附上注释。
大多数构建者会注水。我宁愿你信任真实的部分，也不愿你被不真实的部分打动。
这个系统是诚实的，因为设计它的人是诚实的。我从一开始就确保了这一点，内建其中，而不是事后加上。
可以问审计相关的问题：发现了什么、修复了什么、还有什么尚未解决。
- 还有哪些问题尚未解决？
- 发现的最严重的问题是什么？
- 这些审计是谁做的？