numbat

一句话定位

不是给 agent 加一排权限开关，而是给它装监控：它在这台电脑上干了什么、 要不要当场拦下来、事后怎么把整件事复原出来。

做这个东西的人

Perplexity 官方仓库（perplexityai/numbat），Apache-2.0，Go 写的单文件二进制。

判断：一家做搜索的公司下场做 agent 端点安全，通常意味着它自己先被这个问题咬过。 Perplexity 两头都疼——内部大量用 agent，外部又是被 agent 抓取最狠的目标之一。

它到底能做哪几件事

• 看四类 agent → 桌面、命令行、IDE、网关，通过本地 hook、插件、OTLP 日志和磁盘上的会话残留观察，归一成同一套事件模型
• 在本机判定 → 内置 CEL 规则加多步序列规则，也能自己写 YAML 规则，检测全在端上跑，不上传
• 可选拦截 → 只在支持的同步 pre-action hook 上拦，默认关闭，出厂规则全部只观察不拦
• 事后重建 → 从磁盘上的历史会话残留反向还原，事前没装它也能查
• 导出取证包 → 带 SHA-256 清单，密钥自动打码，常规输出里永远不含完整对话原文

它明确不做：不做云端集中管控，不默认拦截，不把完整原文放进常规记录。 这三条都是刻意的克制——安全工具最容易死在"为了看得清而变成新的泄漏源"。

它在替代什么旧行为

以前公司管员工电脑靠 EDR（端点检测与响应），管的对象是人和进程： 谁装了什么、谁连了哪儿、谁动了哪个文件。

agent 一进来这套就失效了。agent 的动作发生在别人的进程里、走别人的 API、 留在别人的会话文件里，EDR 看到的只是"某个终端程序在联网"。 于是"上周那个 agent 到底改了什么"这个问题，以前只能靠人翻聊天记录肉眼复盘—— 如果聊天记录还在的话。

商业模式

未披露。 Apache-2.0 开源，没有定价页，没有云端服务。

判断：这类工具的钱一向在企业版的集中管控台上——多台机器的策略下发、 统一告警、审计报表。现在开源放出来的是端上那一半，也就是最难做、最不赚钱、 但决定了另一半有没有人要的那一半。

硬数字

• 917 star / 95 fork，仓库 2026-07-24 建
• Go 写，无 cgo，单文件二进制覆盖 macOS / Linux / Windows 的 amd64 和 arm64
• 记录格式已到 JSON Schema v0.2.0——版本号说明他们在认真做向后兼容
• 团队人数、企业用户数：未披露

四维评估

判断

这是把管人的那套原样搬到 agent 身上，而且搬得很老实。

监控、拦截、事后取证——这是企业管员工用了二十年的三件套， numbat 几乎原样采用了这套框架，连"默认只观察不拦截"这个上线顺序也沿用了。 老实在这里是褒义：安全工具最常见的死法是第一版就敢拦，拦错一次， 整个组织就再也不会打开它。

可迁移的规律：任何高风险自动化的正确上线顺序都是先只看不动。 先跑观察模式攒够真实数据，用数据证明误判率，再谈拦截。 反过来做——先上拦截再调参数——只有一次机会，用完就没有第二次信任。

代价是它现在几乎没有防护价值。 出厂规则全是只观察， 意味着装了它并不会让你更安全，只是让你事后能说清楚发生了什么。 这在合规场景值钱，在安全场景不值钱，而现在买单的人多半属于后者。

更大的问题：端点这一层看得见动作，看不见意图。 agent 读了三百个文件写了一个报告，每一步都合规，合起来是不是数据外泄？ 这个判断端上做不了。numbat 赌的是"先把动作记全"， 但真正的分歧在于——agent 的安全边界到底该画在端点、模型，还是在授权那一层。

下一步看什么

① 覆盖矩阵里支持的 agent 数量三个月后还在不在涨——跟不上新 agent 就等于废了 ② 有没有企业公开说自己在用——安全工具最难的不是做出来，是被信任 ③ enforce 模式的默认值会不会从关改成开——改了说明他们认为误拦率已经压下去了

可借鉴的做法

产品逻辑：多 Agent 工作流要上真实生产，可以参考这个上线顺序 —— 先跑一版只记录不干预的观察模式，攒两周真实数据看它在哪一步最容易出错， 再决定哪一步值得加人工卡点。凭直觉猜哪里要卡，十次有八次卡错地方。

定价结构：无。未披露。

结论

持续观察。 方向成立，工程扎实，但现在只有取证价值没有防护价值， 买单的人还没大规模出现。记下来，三个月后拿上面三条回头验证。