AI 编排框架如今已成为关键的企业安全决策

Google News 在 8 月 6 日发出了一项严峻的企业警告：选择 AI 编排框架，如今也意味着选择攻击者能够从何处触及你的系统。

CSO Online 的标题将这一选择描述为一项关键安全决策。这种表述很重要，因为编排软件已不再只是负责在语言模型之间路由请求。它可以将智能体连接到数据库、浏览器、代码仓库、客户记录和生产工具。

矛盾很直接。开发者希望框架能让智能体更强大、更易部署。安全团队则需要即使模型误解指令、摄入恶意内容或调用错误工具时，边界依然能够得到有效执行。

这种紧张关系已经超越了假设性的威胁模型。NIST 表示，许多智能体仍容易受到间接提示词注入（也称为智能体劫持）的影响。在这类攻击中，恶意指令隐藏在智能体为完成原本合法任务而读取的内容中。

一旦智能体能够采取行动，被篡改的指令就可能演变为系统事件。其结果可能包括未经授权发送消息、文件泄露、记录被修改，或执行危险的基础设施命令。

因此，Google 研究人员及其学术合作伙伴主张，组织必须将智能体作为系统来保护，而不只是改进其底层模型。他们的分析强调最小权限、完全中介、信息流控制，以及模型外部的防篡改强制执行机制。

这一立场挑战了许多 AI 项目当前的采购方式。团队通常会从模型支持、工作流模板、记忆功能和开发速度等方面比较框架。这些维度固然重要，但它们无法揭示谁在授权每项操作，或受损工作流会如何被控制。

编排框架回答了这些问题。它位于概率性的模型输出与确定性的企业系统之间。这个位置使一项架构偏好变成了一道安全边界。

Google News 的警告实际改变了什么

编排层已经成为特权控制平面，即使供应商将其包装为普通的开发者基础设施。

AI 编排框架负责协调模型、智能体、工具、数据源、记忆和工作流状态。它决定由哪个组件处理请求，以及哪些上下文会在组件之间流动。

这一描述听起来偏向运营层面。当框架还会存储凭据、调用工具、委派任务或批准下游操作时，安全后果便会显现。

传统聊天机器人会返回文本供人工审阅。经过编排的智能体则可以检查收件箱、检索合同、更新客户记录并通知另一名员工。每增加一项操作，错误或被操纵指令的潜在影响都会扩大。

因此，关键变化并非某一次单独的产品发布，而是 AI 从提出行动建议，转向执行互联工作流。

NIST 关于劫持的分析清楚描述了其根本弱点。模型通过同一个语言接口接收可信指令和不可信数据，因此可能难以区分命令与仅仅看起来像命令的内容。

设想一个被要求总结传入支持工单的智能体。其中一张工单可能包含隐藏文本，指示智能体检索内部文件并将其纳入回复。能力足够强的模型可能会将这些文本视为任务的一部分。

接下来会发生什么，由编排器决定。受约束的框架可以拒绝文件请求、检查用户授权，或要求人工审批。宽松的框架则可能将注入文本转化为一次成功的工具调用。

这使框架评估与模型评估有了实质性差异。模型基准测试衡量的是模型在测试条件下的表现；编排审查考察的则是，当模型行为出错时，周边系统允许它做什么。

这种区别也改变了责任归属。应用团队不能假定模型提供商会处理所有安全控制。模型供应商也无法在自己不运营的数据库、工单平台、云账户或内部 API 中强制执行权限。

部署编排层的企业掌控着这些连接。因此，它也拥有由此产生的身份设计、权限边界、日志记录要求和事件响应流程。

Google News 并未揭示一种新近发明的漏洞类别。它突出了一种已在安全研究中显现的转变。智能体安全如今取决于模型周边的架构，而不只是模型抵抗恶意提示词的能力。

这一点应立即改变采购问卷。买方需要询问框架如何验证智能体身份、限制凭据、验证工作流，以及记录每一项具有实际后果的操作。

他们还需要证据。一项声称支持基于角色访问控制的勾选项，并不能证明控制措施覆盖了工具、记忆、受委派智能体和后台任务。

最重要的功能不再是框架完成演示的速度，而是当演示变成生产工作流时，框架能否维持既定策略。

为什么 AI 编排框架的安全性与众不同

智能体系统将不确定的推理能力与真实权限结合在一起，带来的风险既非传统应用安全，也非模型护栏能够完全解决。

传统软件遵循工程师能够检查的代码路径。输入依然可能触发漏洞，但预期执行逻辑通常存在于源代码或编译组件中。

智能体的行为不同。模型会在运行时制定计划、根据上下文选择工具，并在观察结果后调整下一步。两项相似的请求可能产生不同的执行路径。

这种可变性使测试变得复杂。安全审查无法只检查一个固定工作流，并假设未来所有路径都会遵循它。编排器必须在应用团队未曾明确编写的路径上执行规则。

仅靠提示词过滤无法提供这种保证。它们试图识别恶意语言，但攻击者可以改变措辞、编码、文档结构或上下文。正常内容也可能看起来像指令。

NIST 在 2026 年的红队测试结果说明了这一难题。研究人员报告称，来自 400 多名参与者的攻击尝试超过 25 万次。每一个接受测试的前沿模型至少都遭到过一次成功攻击。

这些红队测试发现并不意味着每个智能体都必然会被攻破。它们说明，企业不应将模型层面的抵抗能力视为完整的安全边界。

安全的编排设计假定模型有时会做出错误决策，然后通过外部控制措施限制损害。

最小权限便是其中一种控制手段。智能体应只获得完成当前任务所需的权限，而不是其用户或开发者拥有的全部权限。

这一点听起来很熟悉，因为它是一项长期存在的安全原则。当任务动态变化、凭据在委派工作流之间流转时，将其应用于智能体就变得困难。

研究客户投诉的智能体可能需要读取某一个支持案例，但并不需要无限制访问所有客户记录，也不需要导出整个数据库的能力。

完全中介是另一项关键原则。每一项敏感操作都应经过策略检查，即使上游智能体此前已批准更广泛的工作流。

缺少中介时，下游工具可能会继承过多信任。受损的编排器可以发出命令，而连接的智能体会在未经独立验证的情况下接受这些命令。

OWASP 的智能体安全资料将集中式编排视为可能的单点故障。其指导建议采用严格身份验证、签名工作流定义，以及下游智能体的独立范围验证。

这份编排指导将注意力从单个提示词转向了委派权限链。一个薄弱环节就可能影响每个信任它的智能体。

信息流带来了另一项挑战。框架可能正确地授权智能体读取机密信息，却未能控制这些信息之后会流向何处。

例如，研究智能体可以为获得授权的员工检索内部路线图。后续一次工具调用却可能意外将该路线图的部分内容放入外部搜索、分析服务或公开消息中。

框架必须同时追踪访问与流动。获准读取信息，并不自动意味着获准通过任何已连接渠道披露信息。

记忆进一步复杂化了这道边界。智能体记忆可以在交互之间保留有用上下文，但也可能保留被污染的指令、秘密或不准确的结论。

今天遇到的一份恶意文档，可能在数天后影响某个工作流。因此，安全团队需要针对记忆来源、保留、隔离和删除的控制措施。

这些要求解释了为什么框架选择会带来长期后果。在团队围绕共享凭据和不透明记忆构建数百个工作流之后，再加装策略执行机制会变得困难。

试点阶段最快的框架，可能成为生产环境中最难以保障安全的框架。当安全控制措施日后必须插入每一条工具调用和委派路径时，开发便利性就会形成债务。

真正的竞争是能力与遏制之间的较量

首要竞争并非一个框架与另一个框架之间的竞争，而是在扩展智能体能力与智能体失效时维持遏制之间的较量。

框架供应商通过让更多系统可供智能体使用来竞争。它们增加连接器、浏览器控制、代码执行、持久记忆、多智能体委派和自动重试功能。

每项能力都可以提高任务完成率，同时也会创造一个新的环节，要求身份、授权和数据处理规则始终有效。

这带来了一种令人不安的反转：让编排框架更具吸引力的功能，也可能加重其遭入侵后的后果。

浏览器工具正是一个例子。它使智能体能够研究最新信息并操作 Web 应用，同时也使智能体暴露于为操纵自动化阅读器而设计的不可信网页。

代码执行提供了另一个例子。它允许智能体分析数据或修改项目，也可能将模型错误转化为文件变更、凭据泄露或破坏性命令。

多智能体委派通过在专业智能体之间分配工作来提高吞吐量。然而，委派可能掩盖究竟是哪个身份授权了一项操作，以及哪个组件提供了有害指令。

编排框架必须维持这一链条。安全团队需要能够重建原始请求、中间决策、工具参数、返回数据以及最终产生的副作用。

普通应用日志往往只能捕捉到片段信息。某个工具可能记录了一次 API 调用，却没有保留触发该调用的模型上下文。模型追踪记录可能展示推理过程，却无法确认外部系统实际发生了哪些变更。

Google 和多所大学的研究人员将智能体比作操作环境，因为它们结合了规划、记忆、外部工具与执行能力。他们的观点是，强制执行机制应置于模型之外。

一项系统安全分析审视了 11 起真实世界中的智能体攻击。每一起攻击都违反了安全信息流原则，而其中大多数还违反了最小权限原则。

这并不意味着模型无关紧要。更好的模型可以减少错误，并拒绝更多恶意请求。但它们无法为每一个企业系统定义访问策略。

因此，框架应将规划与执行分离。模型可以提出操作建议，而确定性的策略层负责决定该操作是否被允许。

高风险操作需要更严格的处理。汇款、发布内容、删除数据、修改权限和部署代码，都应在自然语言指令之外设置明确控制。

某些操作应要求人工批准。另一些操作则可以在严格限制内自动执行。正确的门槛取决于可逆性、数据敏感度和潜在影响。

这种分层方法保留了有价值的自动化能力。它不会要求人工批准每一次搜索查询或文档摘要。

相反，它承认读取公开网页与导出客户数据并不相同。安全框架应通过可强制执行的策略来体现这种差异。

在审慎实施的前提下，模型无关的架构能够支持隔离控制。组织可以更换模型，而无需重建每一条权限规则和工具集成。

不过，模型可移植性并不会自动带来安全性。一个支持多种模型的框架，仍可能集中管理凭据、隐藏执行追踪，或授予过于宽泛的工具访问权限。

开源也不能作为完整的替代指标。源代码可用性能够改善审查与定制能力，但安全部署仍取决于配置、维护和运营纪律。

专有服务可能提供更强的托管隔离能力，也可能限制人们对强制执行行为的可见性。采购方需要来自架构、测试和合同承诺的证据。

实际比较应聚焦于故障行为。团队应询问：当智能体遵从敌对指令、泄露令牌，或超越自身权限进行委托后，究竟会发生什么。

框架是否会在执行前阻止操作？能否识别受影响的工作流？管理员能否撤销凭据并隔离记忆，而不必停用所有智能体？

一个能完成更多任务、却无法回答这些问题的框架，提供的是能力而非可靠的隔离控制。这种权衡应纳入安全评审，而不只是开发者选型流程。

Google News 头条无法为采购方验证的事项

头条识别出了正确的风险，但无法证明任何框架确实执行了其营销宣传中承诺的控制措施。

围绕 AI 编排的安全主张仍难以比较。供应商使用治理、护栏、可观测性和企业级控制等术语，却缺乏一致的技术定义。

一种产品可能将护栏定义为提示词过滤器。另一种产品则可能在每次工具调用前使用确定性授权。这些控制措施并不能提供等同的保护。

可观测性同样可能含义模糊。一个框架或许会展示令牌用量和延迟，却遗漏凭据传递、记忆写入、策略决策或下游变更。

采购方应要求围绕故障案例进行演示。经过精心打磨的成功工作流，对隔离能力几乎说明不了什么。

一项有价值的测试应从不可信内容开始。团队可以在授权智能体必须处理的文档、电子邮件、支持工单或网页中植入敌对指令。

随后，审查人员应观察系统是否将这些内容与可信指令分开处理，并确认被禁止的工具调用是否会在执行前被拦截。

测试还应审查委托机制。主智能体可能将恶意请求传递给拥有不同权限的专用智能体。

如果下游智能体信任编排器发出的每一条命令，那么该架构只是转移了漏洞。每个智能体都需要独立可强制执行的权限范围。

凭据处理也需要同样严格的审视。长期有效的共享密钥会造成广泛暴露，因为一个被攻破的工作流可能影响无关任务。

具有狭窄权限范围的短期凭据能够减少这种暴露。框架应将它们绑定到特定身份、资源、操作和时间窗口。

安全团队还应检查重试行为。自动重试有助于工作流从临时故障中恢复，但也可能重复不安全操作，或绕过设计不佳的审批流程。

失败的交易不应不断触发变体尝试，直到某次成功绕过策略执行。重试必须继续受到相同的授权与幂等性控制约束。

审计记录需要完整性保护。控制编排层的攻击者不应能够删除或改写调查所需的证据。

日志应流向智能体权限范围之外的系统。它们应通过稳定标识符关联提示词、工具调用、审批、身份变更和外部结果。

资产清单是另一个尚未解决的问题。企业无法治理自己并不知道存在的智能体。

业务团队可能在未进入集中采购流程的情况下部署本地框架、浏览器智能体、自动化服务和软件插件。这类影子部署会分裂策略体系，并掩盖数据流动。

NIST 已向业界和研究人员征集关于如何保护智能体系统的信息，涉及间接提示词注入、被投毒的模型，以及在没有对抗性输入时发生的有害操作。

这项智能体安全倡议反映出该领域尚未定型。标准仍在发展，而组织已在将智能体连接到生产系统。

安全负责人应避免过度宣称确定性。没有任何框架能够承诺提示词注入永远不会成功，或每一项自主决策都始终正确。

可辩护的主张更为有限。外部强制执行、范围受限的身份、隔离和可审计的执行，能够降低故障发生的可能性及其影响。

团队还必须评估自身的实施方式。拥有可靠原语的框架，仍可能因开发者禁用审批、复用管理员凭据或暴露不受限制的工具而变得不安全。

文档质量在这里至关重要。开发者需要明确的模式，用于构建安全连接器、策略测试、凭据轮换、记忆隔离和事件响应。

机构知识同样重要。智能体工作流依赖内部策略、技术文档和过往决策，而这些内容往往分散在彼此割裂的系统中。

受治理的工程知识库可以改善检索纪律，但检索无法取代授权。相关信息仍必须留在其获批的边界内。

因此，怀疑性的结论十分重要。选择正确的框架并不能解决智能体安全问题。它决定的是团队是否具备解决这一问题所需的控制能力。

安全团队接下来应关注的三项信号

下一阶段将由可强制执行的智能体身份、经过独立测试的编排控制，以及可衡量的生产环境采用情况所定义。

第一项信号是软件和 AI 智能体身份与授权标准的进展。

人类身份系统假定用户完成认证后使用获批应用。智能体系统则引入了可委托身份，这些身份能够创建子智能体、调用服务，并在用户不在场时采取行动。

安全团队需要一种可靠方法来识别每个智能体、其所有者、当前任务以及获准的委托深度。他们还需要不会悄然继承人类请求者全部权限的凭据。

应关注那些定义机器可读智能体身份和任务范围授权的标准。主要云平台和企业软件提供商的采用，比标准发布本身更重要。

如果框架开始实施具备可验证委托链的、可互操作的短期凭据，这一信号将增强本文的核心论点。如果身份仍是应用特定的拼凑方案，则会削弱这一论点。

第二项信号是对完整智能体系统进行衡量的独立安全测试，而非只测试孤立模型。

当前评估往往测试模型是否会遵从恶意提示词。生产环境风险还取决于工具权限、记忆、工作流路由、隔离和策略执行。

未来的基准测试应报告攻击是否造成了真实的未授权影响。它们应区分模型生成不安全文本，与编排系统完成被禁止操作之间的差别。

NIST 的大规模测试提供了早期基础。OWASP 的验证工作也将智能体风险转化为覆盖编排和自主操作的可测试控制措施。

正在形成的验证标准为组织进行审计和渗透测试提供了更具体的依据。框架供应商应将其控制措施映射到采购方能够验证的要求之上。

如果独立测试揭示不同框架之间存在有意义的差异，这一信号将增强本文的判断。如果大多数产品在现实攻击条件下仍无法区分，则会削弱这一判断。

第三项信号是企业如何在试点项目之后扩大智能体规模。

当五名开发者运行十个工作流时，框架看起来可能很安全。当数千名员工创建共享工具、数据和记忆的智能体时，治理压力就会升高。

安全团队应追踪生产环境中的智能体数量、活跃工具连接数、被拦截的策略违规行为、人工审批、凭据暴露事件和事件响应演练。

他们还应衡量隔离一个智能体所需的速度。平均遏制时间将比统计提示词过滤器警报数量更有价值。

资产清单覆盖率提供了另一项实用指标。一个声称实现集中治理的企业，应当知道有哪些智能体存在、由谁负责，以及它们能够修改哪些系统。

随着智能体采用不断增长，Google News 将继续报道产品公告和安全警告。读者应透过模型之下的控制平面来判断这些报道。

决定性的问题是运营层面的。框架能否在每一项工具上执行最小权限？能否在委托过程中保留身份？调查人员能否在不信任已被攻破智能体的情况下重建一次操作？

选择编排框架的组织，应在扩展自主性之前开展这些测试。从一份敌对文档、一个委托任务和一次被禁止的工具调用开始。

然后要求框架准确展示操作在哪一步被阻止。如果它无法给出清晰答案，该架构就尚未准备好承担具有重大后果的工作。

即使采购文件将其描述为工作流基础设施，安全决策也已存在。应将编排器视为特权控制平面，测试其故障行为，并让高影响操作始终处于可验证策略之后。