CUA 安全检测全链路实战:从内置评测到审计回放,一个 Agent 的完整安全闭环

这是 CUA 安全检测系列的第三篇。前两篇分别讲了 多框架日志导入与注入传播链溯源 和 静态源码审计，评论区和私信里出现频率最高的一个新问题是：

功能都明白了，但从评测到落地再到复盘，一次完整的安全检测闭环到底长什么样？

这一篇不追新功能，做一件更实用的事：把「能力评测 → 运行时拦截 → 人工裁决 → 审计回放」整条链路完整跑一遍，顺便把前两篇没来得及展开的三块能力——内置场景集评测、审计回放页、L2 远程裁决页——一次讲透。

一、前两篇还有哪些没细讲

剩下的三块恰好覆盖「评测、复盘、人工裁决」三个环节——串起来就是完整闭环。

二、评测方法：为什么是「纯规则 0 LLM」

平台页面上有一句容易被略过的话：评测方法为内置场景集端到端回放，纯规则、0 LLM 调用。

这对工程落地意味着什么？

1. 成本可预测
   ：每次回归检测不消耗任何 token，放进 CI 里随便跑，不用担心账单；
2. 结果可复现
   ：同一份轨迹，今天跑和下周跑分级结果完全一致——这对审计和合规是刚需；
3. 延迟可忽略
   ：规则分级是亚秒级的，可以放在每一次 GUI 动作执行前的关键路径上，不拖慢 Agent。

配合第二篇讲过的 screen_filter（同样是模式层、0 LLM 的事前注入过滤），可以看出平台的整个检测底座都不依赖 LLM 的「心情」——在安全工具里，这是很克制的工程选择。

三、审计回放页：每个动作都有「记录」

无论是网页在线检测还是运行时 Gate，只要填了会话 ID，整条轨迹就会写入审计表，随后可以在 审计回放 页面按时间线逐动作复看：

• 每个动作的级别（L0-L3）、处置（放行 / 记录 / 需确认 / 阻断）、以及命中规则的具体原因；
• 运行时 Gate 上报的轨迹完整保留执行顺序，配合第一篇的传播链分析，能直接回答「注入从哪步进来、带偏了哪几步」；
• 审计上报失败时会落本地 fallback_path（cua_audit_fallback.jsonl），网络抖动不阻塞业务，恢复后数据不丢。

gate = ActionGate(    policy=Policy(),    confirm_callback=make_remote_confirm_callback(        "https://aihcc.cloud", API_KEY, timeout_s=120),    audit_sink=make_http_audit_sink(        "https://aihcc.cloud", API_KEY, session_id="my-session-001",        fallback_path="cua_audit_fallback.jsonl"),   # 上报失败落本地不阻塞)

四、L2 确认裁决页：人在环路的最后一公里

L2 动作（发邮件、点「发送」这类不可逆操作）会被挂起，等待人在 确认裁决 页面处理——网页或手机都可以，Agent 不在工位旁边也能裁决。

这条链路有几个值得注意的工程细节：

• Agent 侧 confirm_callback 挂起等待，默认 120 秒超时；
• 超时/断网默认拒绝
  ——宁可误拦，不可漏拦；
• 批准后配合 remember_ttl，完全相同的动作在 TTL 内免重复确认，批量操作不烦人；
• L3 永不进缓存、不参与批量确认
  ——该拦的一次不放。

五、串起来：一个 Agent 的完整安全闭环

把三篇的内容拼成一条可以直接照抄的流水线：

新仓库  → audit 静态审计，生成能力清单              （第二篇）开发中  → SDK 两行接入，轨迹自动采集                （第一篇）改代码  → scan --fail-on L3 回归，对比基线 diff     （第一篇）上线前  → Gate 运行时拦截：L2 网页/手机裁决，L3 阻断 （本文）上线后  → 审计回放逐动作复盘，传播链溯源             （本文 + 第一篇）

写在最后

三篇到此构成一个完整系列：运行前审源码、运行中拦动作、运行后溯轨迹。核心观点其实一句话——Agent 安全不是某一次检测，而是一条每天都在跑的流水线。

系列导航：

• 第一篇：CUA 安全检测平台重磅升级：6 种 Agent 框架日志直接拖入检测，注入攻击自动溯源
• 第二篇：Agent 还没跑就知道它有多危险：CUA 平台上线「源码级安全审计」
• 免费体验入口：aihcc.cloud/cua（在线检测登录即可用，无需安装）