Brex 开源 CrabTrap：给 AI Agent 出口加闸，但这还不是安全答案

Brex 开源了 CrabTrap，定位很直白：把它放在 AI agent 的外部请求出口，当一层 HTTP 代理。Agent 每次要往外发请求，先过这道闸；系统再用静态规则加“LLM 当裁判”决定放行还是拦下。

这事值得看，不是因为“LLM judge”这个说法多新，而是因为它说明行业开始把注意力从“模型会不会想”转回“模型敢不敢替你动手”。在生产环境里，前者常常是体验问题，后者才是事故问题。

CrabTrap 到底拦什么，谁会立刻用得上

CrabTrap 面向的是已经接上真实工具链的 production agents，不是演示用玩具。它盯的是 agent 发出的外部 HTTP 请求，核心动作就是实时 allow 或 block，并记录这次判定是来自静态规则，还是交给 LLM 做语义判断。

从已公开的信息看，它适合的场景很具体：agent 能读 GitHub、能发 Slack、能碰邮件、能调内部 API，但企业不想让它“想干什么就干什么”。比如允许读仓库，不允许删仓库；允许发指定频道，不允许给外部邮箱发信；允许查内部接口，不允许调用高风险写操作。

对工程负责人来说，这类工具最直接的用途不是“做强 agent”，而是先把最贵的事故概率压下去。已经准备把 agent 接入真实系统的团队，会更愿意先加一层网关再上线。还在评估阶段的团队，可能会因此把采购或部署节奏放慢一点，先补控制面，再谈放权。

但前提也很明确：如果你的 agent 现在还停留在问答、摘要、草稿生成，CrabTrap 的价值没那么高。它主要解决的是“会调用工具的 agent”这一层风险，不是所有 AI 应用都需要上来就加这一套。

它补的是出口控制，不是全栈安全

边界必须说死。CrabTrap 主要管的是“这次请求该不该发出去”。这很重要，但也只是一段链路。

它不等于解决模型幻觉。也不等于解决敏感数据泄漏、越权调用、错误授权、糟糕的工具设计，更不等于把 agent 安全变成已完成问题。你可以把它理解成网关式控制，而不是全栈答案。

这也是我觉得它有价值、但不能被吹过头的原因。行业现在有一种偷懒叙事：只要在模型外面再包一层，就像安全已经补齐。其实没有。出口代理能挡住一部分危险动作，但挡不住所有错误意图，更挡不住系统一开始就把权限发得太宽。

古话讲“亡羊补牢”。CrabTrap 属于“补牢”，而不是“别把羊圈修成筛子”。今天很多 agent 系统的问题，不是缺一个裁判，而是权限、工具作用域、审批链路、审计责任本来就没设计好。

和现有安全方案相比，它更像是给 agent 调用链补一层专门闸门。传统 API 网关、WAF、访问控制也能挡一部分风险，但它们通常不擅长处理自然语言驱动的模糊意图。CrabTrap 试图补上的，就是这块“规则难写死、但又不能完全放任”的灰区。不过目前也只能说是补洞思路，不是已被大规模验证的标准做法。

真正的争议，是让 LLM 来当安全裁判靠不靠谱

CrabTrap 最容易被拿来宣传的点，也是它最该被怀疑的点：让 LLM 参与安全裁决，到底稳不稳。

问题不复杂。LLM 可能误杀正常请求，也可能漏掉危险动作。静态规则和模型混着判，还会引入延迟、解释难度和责任归属问题。一次请求被拦了，工程团队要知道为什么；一次危险动作被放过，安全团队也要知道为什么。要是最后只能得到一句“模型认为可行”，那不叫治理，那叫把责任外包给概率系统。

这也是企业场景最现实的约束。能不能拦，不是唯一问题。能不能审计，能不能复盘，能不能稳定复现，决定了它能不能真的进生产。模型做安全裁决听起来灵活，落到合规、SRE 和事故追责上，就会碰到老问题：谁批准的，为什么批准，出了事怎么算。

所以我更关心的不是“LLM judge 聪不聪明”，而是三个更硬的变量：

• 误杀率和漏判率能不能长期压低
• 判定理由能不能被团队审计和复盘
• 这类外挂代理会不会逐步内建到 agent 平台的权限系统里

如果这三件事做不到，CrabTrap 的位置就很清楚：它是务实补洞，不是结构性解决。

这点很像早期互联网和云安全的老路。业务先冲，权限先放，出了事再补防火墙、网关、审计。历史不会原样重演，但经常押同一道韵。今天的 agent 热潮，也有同样的味道：先把执行权交出去，再想办法在出口装闸。

问题就在这儿。闸门当然有用，但如果权限不是内生的、调用边界不是默认收紧的、危险动作不是天然要审批的，那系统迟早还会把风险推回人身上。工具看起来更聪明了，治理方式却还是老互联网那套补丁逻辑。