昨天我发了 CUA 安全检测平台的升级文章：6 种框架日志直接导入、注入传播链溯源、CLI 一行扫描。文章发出后，后台被问得最多的同一个问题是：

轨迹检测再强也是「事后」的——我的 Agent 还没跑起来，能不能先知道它理论上能干出多危险的事？

今天登录 aihcc.cloud/cua，发现平台正好上线了这个能力：静态源码审计。不用运行 Agent，扫一遍代码仓库，直接生成「这个 Agent 理论上能干什么」的危险能力清单。我第一时间实测，并把昨天那篇没讲透的几个运行时安全细节一并补上。

一、运行前 vs 运行后：安全检测的两个半场

先把昨天和今天的能力边界说清楚，两者是互补关系：

维度	昨天上线（运行后/事后）	今天上线（运行前）
检测对象	运行轨迹、框架日志	Agent 源代码仓库
回答的问题	Agent 实际干了什么？哪一步被注入带偏？	Agent 理论上能干什么？
典型入口	scan 命令 / 网页拖文件	audit 命令 / 仓库扫描
产出	动作分级 + 注入传播链	危险能力清单 + 权限边界核对

一个是「行为证据」，一个是「能力声明」。审计报告里两份放在一起，才能讲完整的的故事：它有能力做什么（源码），它实际做了什么（轨迹）。

二、静态源码审计：扫一遍仓库，生成「危险能力清单」

这次上线的源码审计做了四件事，每一件都对应 Agent 安全审查里的一个真实盲区：

1. 发现工具注册点。 自动扫描仓库里的 @tool 装饰器、tools=[...] 注册列表、MCP server 声明——Agent 的「手」全部枚举出来，一个不漏。

2. 标记危险调用。 subprocess、os.system、requests.post、文件删除这类高危 API 的出现位置逐条列出，精确定位到文件和行号。

3. 结合 AGENTS.md / system prompt 核对权限边界。 这是我觉得最实用的一点：很多 Agent 在文档里声明「仅读取、不修改」，但代码里实际注册了写和删的工具。声明与实现不一致，静态审计直接标红。

4. 输出能力清单。 汇总成一份「这个 Agent 理论上能干什么」的报告，与运行时轨迹检测互为印证。

示例输出（基于实际检测逻辑整理）：

$ hallucc cua audit ./my-agent/

🔍 静态源码审计报告 — my-agent/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📦 工具注册点（4 处）:
  tools/search.py:12   @tool web_search       → 网络读取
  tools/shell.py:8     @tool run_command      → ⚠ subprocess 任意命令执行
  tools/files.py:21    @tool delete_file      → ⚠ 文件删除（无路径白名单）
  mcp.json             MCP server: filesystem → 文件读写（挂载根目录 /）

📄 权限边界核对:
  AGENTS.md 声明「仅读」，代码实际含 2 处写/删能力 —— ❌ 声明与实现不一致

🎯 能力结论:
  该 Agent 理论上可执行任意 shell 命令并删除任意文件
  建议运行时 Gate 策略 ≥ L2，删除类动作按 L3 管控

对 code review 场景来说，这份清单可以直接贴进 PR 描述——评审人一眼看清这个 Agent 的能力面，不用翻遍整个仓库猜。

三、昨天没讲透：screen_filter，把注入拦在「进上下文之前」

昨天的文章讲了注入传播链——事后定位「注入从哪一步混进来」。今天补一个事前的配套能力：屏幕内容在喂给 Agent 之前，先过一道注入过滤。

from cua import screen_filter

report = screen_filter(ocr_text, task=user_task)   # 模式层检测，0 LLM 调用
if report.verdict == "injection":
    ...  # 拦截或清洗后再喂给 agent

两个细节值得注意：一是它是纯模式层检测，0 次 LLM 调用——意味着零额外 token 成本、亚秒级延迟，可以放在每一次截图之后无压力地跑；二是过滤时带上了 task 上下文，判断标准不只看文本本身，还看它和当前任务的相关性，误报率比纯关键词匹配低得多。

事后溯源（传播链）+ 事前过滤（screen_filter），注入防护的两个半场也齐了。

四、还有 3 个容易被忽略的运行时细节

翻 使用指南 和升级文档时，我发现几个昨天没提、但对生产落地很关键的细节：

1. remember_ttl：批准的 L2 不用反复确认。 开启「记住决定」后，已批准的 L2 动作在 TTL 内对完全相同的动作免重复确认——批量处理同类操作时体验提升明显。注意红线：L3 永不进缓存，该拦的一次都不会放。

2. approve_plan：L2 批量计划确认。 Agent 一次规划出一串动作时，可以把 L2 的一批一次性提交裁决，不用逐条点确认。L3 不参与批量——危险动作永远需要单独面对人。

3. icon_labeler：没有无障碍标签的图标按钮也能识别。 对那些只有图标、没有 a11y 标签的按钮，可以注入 VLM 兜底标注。设计上标注结果只升不降——VLM 只能把动作风险往上调，永远不能把高危动作标成安全的。

五、为什么敢接生产：四条设计红线

安全工具最怕的不是功能少，是边界模糊。这套平台的设计红线写得很死：

• 策略可收窄不可放宽——运行中只能越收越紧；
• L3 不可豁免——白名单也不能给 L3 降级；
• 确认通道超时/断网默认拒绝——宁可误拦，不可漏拦；
• 审计上报失败落本地不阻塞——fallback_path 兜底，监控故障不会变成业务故障。

另外对顾虑侵入性的团队，还留了两个低门槛入口：「仅记录不拦截」模式先观察再决定要不要拦，自定义字段映射让非标格式的日志也能接入（告诉平台哪个字段是命令、哪个是输出即可）。

写在最后

昨天的升级回答「Agent 干了什么」，今天的源码审计回答「Agent 能干什么」——运行前后两个半场拼齐，再加上事前注入过滤和批量裁决这些运行时细节，CUA 安全检测从「演示可用的工具」真正变成了「能进工作流的系统」。

建议的用法：新 Agent 项目先跑 audit 看能力清单 → 开发中用 SDK 自动采集轨迹 → 每次改代码 scan --fail-on L3 回归 → 上线前把能力清单和审计轨迹一起归档。在线检测登录即可免费体验：aihcc.cloud/cua。