在企业级 AI Agent 部署场景中，安全护栏的设计始终是核心挑战。传统的方案要么过度限制导致 Agent 无法完成实际任务，要么过于宽松无法有效防御 prompt 注入和异常行为。Brex 近期开源的 CrabTrap 项目提供了一种新的思路：在 HTTP 代理层引入 LLM-as-a-judge 机制，对 Agent 的每一次出站请求进行实时评判。本文将深入解析其架构设计、核心实现细节以及生产环境部署的关键参数。
传统护栏方案的局限性
在讨论 CrabTrap 之前，有必要梳理现有方案的核心痛点。基于 MCP（Model Context Protocol）的网关只能在协议层对 MCP 流量进行策略 enforcement，对于非 MCP 协议的请求完全失效。LLM 提供商自带的 guardrails 与特定模型绑定，策略定制空间有限且不透明。NVIDIA OpenShell 虽然提供了沙盒级别的 egress 控制，但缺乏细粒度的请求级别决策能力。这些方案的共同问题是：要么无法覆盖全部流量，要么决策粒度不足以满足复杂业务场景的需求。
Brex 在部署 OpenClaw 等 Agent 框架时遇到的困境极具代表性。他们的 AI Agent 需要真实的凭证（API 密钥、OAuth 令牌、服务账户）来完成财务、风控等关键业务操作，但 Agent 本身可能产生幻觉性的破坏操作，或者在用户输入被恶意构造后发生 prompt 注入。一旦异常请求离开进程到达后端 API，就会产生真实的业务影响。传统的手动调优 API 权限模式在 Agent 能力快速增长的场景下难以扩展 —— 每增加一个新能力，就需要新增一个手工配置的 API 令牌和审计表面。
传输层代理的架构设计
CrabTrap 的核心创新在于将安全决策下沉到传输层（Transport Layer），使得代理与具体的开发框架、编程语言和 API 实现解耦。部署时只需在 Agent 所在容器的环境变量中设置 HTTP_PROXY 和 HTTPS_PROXY，所有出站流量就会自动流经 CrabTrap 代理。这种设计无需在 Agent 代码中集成任何 SDK 或包装器，也不需要为每个工具单独开发插件，真正实现了对所有网络请求的透明拦截。
对于 HTTPS 流量，CrabTrap 实现了完整的 TLS 中间人攻击（MitM）能力：为自己的 CA 为每个目标主机生成证书，与客户端建立 TLS 连接，然后向上游目标服务器建立独立的 TLS 连接。这种双向 TLS 终止确保了代理可以检查加密流量的内容。部署时还可以在 Agent 容器中配置 iptables 规则，直接阻断非代理目标的所有出站连接，作为额外的防护层杜绝流量逃逸的可能性。
两阶段决策机制
CrabTrap 的请求评估采用静态规则与 LLM 评判相结合的两阶段管道，这种设计在安全性和性能之间取得了良好平衡。第一阶段是静态规则匹配，执行确定性模式匹配（前缀、精确匹配、glob 通配符），可以额外限定 HTTP 方法。静态规则被编译为缓存的正则表达式，执行时间在微秒级别，可以处理 Agent 的大量高频 predictable 请求。关键设计是拒绝规则（Deny Rule）始终优先于允许规则，确保安全策略的确定性。
当静态规则无法匹配请求时，请求进入第二阶段 ——LLM-as-a-judge 评判。评判 LLM 接收完整的请求上下文，包括方法、URL、请求头和请求体，以及为该 Agent 分配的自然语言策略描述。LLM 返回结构化的 JSON 决策，包含 ALLOW 或 DENY 判定以及人类可读的理由说明。这种设计既保留了静态规则的快速路径，又为长尾复杂请求提供了语义理解能力。
根据 Brex 的生产运行数据，LLM 评判触发的请求比例极低。在他们的一个生产用例中，LLM 评判仅在少于 3% 的请求上激活。这说明 Agent 在建立稳定工作模式后，大部分流量都可以被静态规则覆盖，LLM 评判主要处理不熟悉的端点或异常请求形态。
防御 Prompt 注入的特殊设计
将完整的 HTTP 请求发送给 LLM 评判带来了一个独特的安全挑战：请求本身可能包含精心构造的恶意内容，试图通过 prompt 注入攻击来绑架评判结果。CrabTrap 为此设计了多层防御机制。
首先，所有用户控制的内容都以转义后的结构化 JSON 字段形式传递给 LLM，而不是作为原始文本插值到 prompt 中。这种方式从根本上消除了通过 URL、Header 或 Body 内容注入 prompt 的可能性。其次，代理对安全相关的 Header 进行优先级排序，并将总 Header 内容限制在 4KB 以内，防止通过填充大量无用 Header 来实施 prompt inflation 攻击 —— 即通过垃圾数据将策略内容挤出上下文窗口。请求体在 16KB 处截断，并明确告知 LLM 截断事实。对于多部分请求（Multipart Request），代理生成每个部分的结构化摘要而不是发送原始内容，进一步减少了攻击面。
策略生成与评估系统
编写有效的自然语言安全策略是一项专业技能，如同编写费用报销政策一样看似简单实则复杂。一个看似合理的策略描述往往会在实际操作中阻塞不应该被阻止的行为，或者相反地放行了不应该允许的请求。CrabTrap 提供了两大辅助系统来弥合策略编写与实际需求之间的鸿沟。
第一个是策略构建器（Policy Builder），本身也是一个 Agentic Loop 系统。其核心理念是观察现实行为而不是凭空编写规则后祈祷它能匹配现实。策略构建器分析 Agent 的历史流量数据，采样有代表性的网络调用，然后基于观察到的实际行为生成匹配的自然语言策略。根据 Brex 的生产经验，将策略构建器指向几天真实流量产生的策略，在大多数保留请求上与人类判断高度一致。从观察到的行为出发然后做减法编辑，比从空白开始编写策略要有效得多。
第二个是评估系统（Eval System），用于在策略变更上线前测试其效果。CrabTrap 可以重放历史审计条目针对草稿策略进行离线评估，报告策略更新会改变哪些历史请求的判定结果。评估结果可以按方法、URL、原始判定和一致状态进行多维度切片。由于评估过程使用并发 Judge 调用，重放数千条请求可以在几分钟内完成。所有历史请求都记录在 PostgreSQL 中，可通过管理 API 和 Web 仪表板进行索引和查询。
生产环境关键参数
基于 CrabTrap 的设计和 Brex 的生产经验，以下是部署时需要关注的关键工程参数。静态规则应优先覆盖 Agent 的高频已知端点，将 LLM 评判保留给真正的长尾请求。建议为每个 Agent 分配独立的安全策略，而不是试图用单一策略覆盖所有场景，这既符合最小权限原则也便于问题定位。
Header 大小上限建议保持在 4KB，这一阈值足以覆盖绝大多数正常请求的头部数据，同时能有效防止 prompt inflation 攻击。请求体截断阈值 16KB 需要根据业务场景调整，如果 Agent 需要传输较大的 JSON payloads，应评估是否需要调整或采用请求摘要模式。日志存储的 PostgreSQL 表应设计合理的分区策略和索引，考虑到高流量场景下审计数据增长迅速。LLM 评判的超时参数需要仔细调优，既要避免长时间阻塞影响 Agent 响应，也需给 LLM 足够的推理时间做出合理判断。
代理层还应配置适当的监控指标，包括每秒请求数、静态规则命中率、LLM 评判延迟分布、拒绝率趋势等。这些指标不仅是运维观察的基础，也是优化策略规则的重要依据。Brex 特别提到的一个洞察是：代理不仅是一个 enforcement 工具，更是一个 discovery 工具。部署代理后揭示的流量噪声使得团队可以回头优化 Agent 本身 —— 删除不必要的工具、削减浪费时间和 token 的请求类别。
资料来源
本文主要参考 Brex 技术博客文章《CrabTrap: an LLM-as-a-judge HTTP proxy to secure agents in production》（2026 年 4 月 21 日）。