员工电脑同时跑多种AI助手,安全团队怎么统一审计和阻断

安全团队很快会碰到一个有点尴尬的现场：同一台开发电脑上，Claude Code、Codex、IDE插件和桌面Agent各记各的日志，各用各的钩子，谁都能执行命令、读文件、访问网络。

EDR看得见进程和系统调用，却不一定知道某条命令来自哪次Agent会话；Agent自己的日志知道上下文，却未必进入SIEM。出了问题，调查人员要在几个隐藏目录里拼时间线。

Perplexity在2026年7月底开源的Numbat，就是冲着这个缝隙来的。它把不同Agent的钩子、OTLP/HTTP日志和本地会话文件归一成一套事件记录，在端点本地做规则检测，还能在少数受支持的调用前钩子里阻断动作。

我对这个方向有兴趣，但不会把“开源了52条规则”直接等同于生产防护。它更适合先做一次边界很清楚的端点PoC。

第一步先别装钩子，只读盘点

Numbat提供单文件程序，支持macOS、Linux和Windows。numbat agents用于发现支持的Agent，numbat scan可以读取已有会话痕迹。官方说明这两类命令不会安装钩子，也不会修改Agent配置。

这一步回答两个基础问题：公司里到底出现了哪些Agent，已有会话能恢复多少动作。

别急着计算“覆盖率100%”。覆盖矩阵才是验收基准。每个Agent可能只支持部分会话文件、实时采集或调用前阻断；没有落盘的活动，事后扫描也恢复不了。Windows原生环境和WSL还要分别看待。

PoC记录建议保留Agent名称、版本、采集方式、事件类型、时间戳精度、缺失字段和会话关联结果。把这些字段交给SOC同事看一遍，他们通常很快就能指出哪些证据无法支撑调查。

Numbat内置52条规则，支持CEL规则和多步骤序列。官方README把一组受控重放写得很具体：例如读取密钥文件后准备向外发送数据，或者尝试写入authorized_keys。这些是文档中的测试样例，不是对真实入侵的披露。

README前面还有一行很容易被忽略：所有随项目发布的规则默认只监控。要启用阻断，运营方需要复制规则、明确设置enforce: true、提高版本号，再为受支持的调用前钩子安装策略。

这个默认值是合理的。Agent命令里有大量安装依赖、读配置、运行脚本的动作，直接把通用规则切成阻断模式，很容易影响开发工作。

建议先跑两周监控，挑出高频规则、误报原因和无法判断的上下文。然后只选三五个后果明确、误报低的动作进入有限阻断，例如写SSH持久化文件、访问云元数据地址、读取生产密钥后紧接外发。数量少一点，证据扎实一点。

调用前钩子拒绝某个动作，不代表这次任务结束。不同Agent可能把拒绝理由送回模型，模型还会寻找替代路径。端点产品如果只记录“成功拦截一次”，会漏掉后面的绕行。

PoC里要把一次任务当成完整序列：危险动作是否被拒绝，模型随后调用了什么工具，是否改用其他命令，用户能否手动绕过，策略失效时默认放行还是停止。

Numbat输出版本化NDJSON记录，可以写到本地文件或通过HTTP送出。接SIEM前还要处理一个现实问题：Agent上下文可能包含项目路径、命令片段和敏感业务信息。官方提供脱敏和只读重建，但也提醒记录在脱敏后仍可能保留敏感端点语境。

甲方验收可以看六项：Agent覆盖范围、事件字段完整性、序列规则准确性、阻断后的实际结果、端点资源开销、敏感日志处理。乙方若把它接进现有EDR或SOC方案，还要说明谁维护规则、Agent升级后怎么回归、调查包如何校验，以及哪些动作根本没有同步阻断接口。

Perplexity公开表示，它通过MDM把Numbat部署到内部端点，并把结构化遥测送入集中安全系统。这是厂商公开的自身实践，不能代替其他企业环境里的独立测试。

还有一句边界值得写进验收报告：Numbat的发现是规则命中，不是入侵成立的证明。开源工具能帮助安全团队摸清Agent活动、建立事件模型和验证规则。生产环境是否扩大阻断范围，要看误报、绕过、证据质量和运维成本。

• 技术说明：https://research.perplexity.ai/articles/securing-agents-across-perplexity%E2%80%99s-client-endpoints-with-numbat
• GitHub仓库：https://github.com/perplexityai/numbat
• 官方Release下载：https://github.com/perplexityai/numbat/releases

说明：本文基于官方文档设计PoC，没有把文档样例写成本文作者的实测结果。