智能体安全新思路：观察行为而非制定规则

Mark Do 暂无评论阅读 5 次

智能体安全新思路：观察行为而非制定规则

传统智能体安全面临的挑战

OpenClaw已成为应用最为广泛的智能体框架之一，但尚未在企业规模中得到充分验证。智能体需要真实的凭证——API密钥、OAuth令牌、服务账户——才能有效工作，而Brex发现传统安全护栏无法约束这些智能体使用凭证的行为。

为克服这些局限，Brex构建了一个名为CrabTrap的内部平台。这个开源HTTP/HTTPS代理会拦截所有网络流量，检查策略规则，并使用大语言模型(LLM)作为判断者，决定是否批准智能体的请求。

我们注意到网络层是一个未被充分利用的执行点，Brex联合创始人兼CEO佩德罗·弗朗切斯基(Pedro Franceschi)表示。每个智能体发出的请求都是拦截、推理和制定策略决策的机会。

转向网络传输层控制

智能体安全差距的明显解决方案(至少最初)是设置护栏，早期工作大多集中在范围工具、按权限操作和人机循环审批上。弗朗切斯基指出，随着智能体的演进，每个新功能都意味着需要调整或公开更多API以供审计。

任何具有多种工具并可访问开放互联网的智能体系统都会立即给开发者带来两难：你让智能体越强大，它就越危险；而让它越安全，它的实用性就越低，他说道。

解决这一权衡的现有方案都存在缺陷：细粒度API令牌只能在边缘提供帮助，但仍可能被滥用并限制功能；语义护栏(如上下文、技能或提示引导)容易被提示注入绕过，特别是对于连接互联网的智能体。

弗朗切斯基表示，当智能体仅获得只读访问权限或有限工具集时，它们可以被”去除危险性”，但此时它们无法完成有意义的工作。另一方面，授予广泛的写入权限和大量工具可能导致幻觉和实际生产后果。

模型上下文协议(MCP)网关在协议层执行策略，但仅适用于使用MCP的流量。同时，来自LLM提供商的护栏与单个模型绑定，并且可能对企业特定策略的定制不透明。而Nvidia OpenShell等强大工具提供的更多是”每沙盒出口控制”。

基于实际行为的策略构建

CrabTrap将确定性静态规则与LLM判断者相结合，用于处理超出已知模式的请求，弗朗切斯基解释道。判断者仅在”不熟悉端点或异常请求形状的长尾部分”激活，对于成熟的智能体，这通常只占请求的不到3%。

更紧迫的问题是如何知道某个策略是正确的？使用静态规则，推理准确性相对直接。但使用LLM判断者时，系统是非确定性的，用户需要确信该策略能批准正确的请求并阻止其他请求。

我们的关键见解是从观察到的行为而非从头开始编写策略来构建策略，弗朗切斯基说。从实际行为开始并根据现实世界的学习进行精简，证明比从空白页开始”有效得多”。

Brex团队构建了一个策略构建器(本身就是一个智能体循环)，在影子模式下运行底层智能体，分析历史网络流量，采样代表性调用，并起草一个与智能体实际行为匹配的自然语言策略。

评估与反馈机制

在此基础上，他们构建了一个在策略生效前测试变更的评估系统。CrabTrap将历史审计条目与草稿策略进行比较，并报告需要进行的精确变更。用户可以按方法、URL、原始决策和协议状态对结果进行切片。

所有这些都通过并发判断调用来运行，因此重放数千个请求”只需几分钟，而不是几小时”，弗朗切斯基说。Brex还开发了一个实时反馈循环：完整的审计轨迹存储在PostgreSQL中，可通过管理API和仪表板查询。在资源持续被拒绝的情况下，系统可以通知人类或智能体提出策略更新以供审查。

核心挑战与解决方案

当然，构建过程并非没有挑战。一个主要问题是延迟：在智能体和每个出站API请求之间放置一个LLM听起来会使系统陷入停滞，他说。

然而，事实证明问题没有预期的那么严重。这有两个原因：LLM判断者只激活一小部分请求(前述的3%)。智能体很快会形成可预测的流量模式；一旦被观察到，高容量模式就会变成静态规则。其次，通过使用小型快速模型(如Claude Haiku)，即使判断者被激活，增加的延迟也是”微不足道的”，弗朗切斯基说。这可以通过本地模型和提示缓存进一步减少。

更困难且不那么明显的挑战是提示注入，他说。判断者接收完整的HTTP请求，所有内容都由用户控制，因此，精心设计的URL、标头或请求主体可能会操纵判断者的决策。

Brex通过在将请求发送到模型之前将其构造为JSON对象来解决这个问题，因此所有用户控制的内容都被”转义而不是作为原始文本插值”，弗朗切斯基说。