Cover image for AI Harnesses Are Just Middleware, and Middleware Trust Bugs Are Older Than Your Career

Cor E

这是没人愿意听的事实：我们早就知道如何攻破那些组件盲目信任彼此输出的系统。我们知道这个已经二十五年了。只是给它起了个新名字，然后就把教训忘了。

背景

「AI 编排层」就是编排用的胶水。拿一个 LLM，用一大堆连接器、插件和工具调用脚手架把它包起来，让它真正能做事（查询数据库、调用 API、写文件），这就是编排层。Dark Reading 的文章一针见血地指出一个显而易见的结构问题：这些组件形成了一条信任边界链，而其中很多组件根本不去验证邻近组件交过来的东西。

如果你觉得这句话似曾相识，那很正常。反序列化漏洞、通过内部服务调用实现的 SSRF、「受信任」上游解析器引发的 XML 实体注入——整个应用安全史就是一部「组件 A 假定组件 B 已经做完验证」的演变史。每当一种新架构模式足够火爆、还没来得及被威胁建模就吸引了生产流量时，我们就会重新发现这个模式。

新的部分不是信任边界问题。新的部分是，链条中间坐着一个概率性文本生成器，它可能被自己的输入「忽悠」去做奇怪的事情，而且它现在直接接入了工具执行。

炒作核查

被夸大的说法：把这包装成某种需要 AI 专用防御的新型 AI 特有攻击类别。这不是。它只是披着 LLM 外衣的集成安全问题。一旦你让插件和连接器在组件间传递数据却不做验证，你就遇到了把任意一组微服务用隐式信任粘在一起时会遇到的同样问题。攻击面是老问题；载荷投递机制（提示驱动的工具调用）才是新的。

被低估的部分：编排层在没人做基本的组件边界威胁建模的情况下就被快速上线了，因为大家都在抢着发布 Agent，而不是 Agent 周围的管线。没人想成为那个花了三个 sprint 在工具调用间做模式验证的团队，而竞争对手已经发布了炫酷的 demo。这种压力真实存在，而且不会消失。

谁会从把这称为「全新 AI 威胁类别」中获益？说实话，所有卖东西的人。厂商获得了一个新的紧迫感叙事，以及推销新工具的理由，而不是「请按我们在 2015 年就告诉你的方式验证接口」。安全团队获得了一条更容易证明预算的项目，而不是「改进我们的 SDLC 卫生」。没人会从这个无聊但正确答案中获益：用对待任何多组件分布式系统的严谨度来处理，把 LLM 的输出视为它跨越的每一处边界上的不可信输入，因为它确实如此。

影响

如果你正在构建或部署编排层，实际的结论并不光鲜。编排器、连接器和插件之间的每一次跳转都是一个接口，而接口需要契约：模式验证、输出清理、每个工具调用实际允许执行的最小权限范围。不要因为 LLM 这么说，就让一个插件的输出直接进入另一个工具的执行上下文。这不是 AI 安全问题，这是输入验证问题，只是恰好把 LLM 当成了不可信输入的来源，而不是表单字段。

对安全团队来说，这提醒我们「模型已对齐」和「流水线安全」是两个完全不同的主张，而很多组织目前只在检查前者。红队测试模型的输出不如红队测试模型产生内容后交给下一个组件时会发生什么更重要。

对整个行业来说：编排层架构的扩散速度快于任何关于组件间如何互相认证或验证的共享标准。这才是真正的差距。不是缺乏对信任边界存在的认知，而是缺乏对在这个特定技术栈中验证它们应该是什么样子的共识。

开放性问题

如果我们已经有了二十年关于软件组件间隐式信任的惨痛教训，为什么每一种新架构模式都会获得五年的宽限期才有人应用这些教训？

—— Cor，Skyblue Soft

来源