AI智能体正在考验零信任安全的极限

当企业开始用编排器管理一支AI智能体任务小组，让它们协作完成风险评估、客户画像、撮合匹配和信息提取时，一个看似基础却极其棘手的问题浮出水面：我们凭什么相信这些智能体真的执行了我们的指令？证据又在哪里？

IEEE Spectrum刊载的这篇来自贝尔法斯特女王大学（QUB）的研究文章，把零信任架构（ZTA）引入智能体治理的讨论。零信任的核心原则是"永不信任、始终验证"，但当被验证的对象变成会自主行动、会相互调用、甚至会在不同任务间迁移的AI智能体时，这套原则的落地远比想象中困难。

上下文恢复攻击：删掉的数据还能被"召回"

研究团队描述了一种典型风险场景：为了防止智能体因历史数据而产生决策偏差，系统会设置检查点，提示智能体删除相关的历史上下文。但后续的提示词可能诱导智能体把本应删除的信息重新"召回"，甚至被套出更多内容——这就是上下文恢复攻击。

这类问题暴露了零信任在智能体场景下的核心矛盾。ZTA依赖策略执行点（PEP）来维持系统信任，但PEP本身必须被信任，于是问题变成：谁来验证验证者？文章直言，把单一实体放在那里、期望它能扩展到覆盖所有智能体交互，是对问题空间的低估。

另一个被点名的风险是"氛围编程"——用AI模型辅助开发软件时，把整个代码库交给组织外部的不可信实体，可能导致漏洞在多个层面蔓延。

上下文窗口是大型语言模型在单次推理中能够直接访问的信息总量，包括系统提示、对话历史、检索到的文档等。由于模型本身没有持久记忆，所谓"删除"往往只是从当前上下文窗口中移除相应文本，而非从模型参数或外部存储中彻底清除。攻击者可以通过精心构造的后续提示，利用模型对上下文的补全倾向，诱导其根据残留线索重建或推断出已被移除的信息。这种机制使得"指令遵循"与"信息遗忘"之间存在本质张力：模型被要求忘记某段内容，但其生成过程仍可能受到该内容在训练或先前交互中形成的统计关联影响。因此，在智能体系统中，仅靠提示层面的删除指令无法构成可验证的遗忘保证，需要引入外部审计与状态隔离机制。

2到3秒内完成去认证攻击

贝尔法斯特女王大学的内部实验给出了一个直观的时间尺度：在智能体编排下，流行的去认证攻击可以快到2到3秒完成。这意味着留给系统反应和决定打补丁的时间窗口几乎为零。

文章由此引出异步自治下的信任难题。智能体要围绕共同目标协作，你怎么确保它们全部对齐，并理解各自目标存在的延迟？团队的研究路径是先证明问题存在，再展示当必须在异步自治边界内证明信任时，影响和规模可以有多大。

他们提出的缓解方向包括维护AI物料清单（AI-bill of material），或利用分布式账本技术，通过可追溯性和不可篡改性提供信任的底层基础设施，让智能体活动及其信任向量与平台无关。

去认证攻击（de-authentication attack）原本是无线网络中的一种拒绝服务手法：攻击者伪造管理帧，向接入点或客户端发送解除认证通知，强制断开合法连接。在智能体编排场景下，这一攻击面被显著放大——智能体之间通过API、消息队列或共享状态频繁握手与授权，一旦某个环节的认证状态被恶意重置，编排器可能误判节点失联并触发重新分配或降级策略，进而引发连锁反应。攻击速度之所以能压缩到秒级，是因为智能体间的信任建立往往依赖短期令牌或会话凭证，且自动化编排逻辑对状态变化的响应极快，缺乏人工复核的缓冲。防御思路包括对关键认证事件实施速率限制、引入带外确认通道，以及维护令牌撤销列表以阻断重放。

水平异常：在一个任务里守规矩，不代表处处可信

文章特别提到一个尚未被充分探索的概念——水平异常。它指的是智能体在不同设置下与不同来源交互时表现出的差异。一个智能体在某个特定任务或应用上行为正确、符合架构预期，并不意味着它在所有关联组件上的操作都可被信任。

如何识别这类异常、以及在不顺从不合规智能体的前提下能采用哪些方法，文章坦承仍是开放问题。

与之相关的是成本权衡。在低容错、非追踪型智能体工作流的系统中，实时信任并验证每一次查询在计算上代价高昂，直接导致内存与执行之间的常见取舍。而一旦发生零日攻击，过度依赖只有单一信任层的智能体生态，可能让整个生态在故障时暴露——就像骨干网络不可用时没有自主性一样，也没有放置信任的层面。

AI物料清单（AI-BOM）借鉴了软件物料清单（SBOM）的思路，旨在为AI系统建立一份可追溯的组件清单，涵盖模型权重、训练数据集、依赖库、微调配置、推理框架版本以及智能体所调用的外部工具与API。在智能体治理语境下，AI-BOM的价值在于将"信任"从对单一实体的静态判断，转变为对整条供应链的动态溯源：当某个智能体行为异常时，可以沿物料清单逐层定位是模型版本、数据污染还是工具接口被篡改所致。分布式账本技术则进一步为这份清单提供不可篡改的时间戳与跨组织共享能力，使不同宿主之间的信任向量可以对齐。两者结合，有望缓解"谁来验证验证者"的困境——验证依据不再是某个中心化PEP的自我声明，而是可独立核验的溯源记录。

供应链风险：一个智能体失控不再是小事

文章对失败成本的判断值得企业警惕：半信任到低信任治理下的智能体带来短期高收益，但系统失败时的恢复成本尚未被探索，而且不会是被控制住的问题。

举例来说，仅仅因为一个智能体失控引发的供应链问题，如今不再是一项可控的小任务，而需要横扫受影响智能体的所有触点。这意味着无论智能体数量多少、触发代理智能体的能力多强，都有必要为所有智能体部署计算代价高昂的追踪器。

研究团队的假设是，AI主权与信任需要协同治理，因为溯源责任很大程度上落在智能体的宿主身上。这里有一个关键区分：遗漏信息与遗漏指令是两回事，在可信问责上影响截然不同。

真正的零信任存在吗？

文章回到根本问题：真正的零信任架构存在吗？

现实症结在于，这些系统未能采纳历史上依赖状态建模来治理信任的方法。在智能体自治程度高的无状态系统中，对信任溯源的收敛性和可靠性显著下降。政策可以被信任吗？如果可以，如何管理才不至于落入基于策略的访问与控制陷阱？

在贝尔法斯特女王大学的Cyber AI hub项目中，团队正与信任为前提的行业合作，这些组织把信任作为由内部策略管理的护栏，重点通过策略保护系统，而非信任第三方智能体服务商。具体做法包括围绕服务模型设置约束、通过日志追踪和管理智能体活动、维护令牌撤销列表以防重放攻击。

文章还提到信任的形式化验证：理解模型鲁棒性有助于建立信任，平衡对抗准确率与经认证的对抗鲁棒性，可以帮助判断模型的可信程度。据该团队引用的一项研究工作，对抗蒸馏被用于提升认证鲁棒性。

留给业界的问题很直接：在真实世界部署智能体时，我们能否接受不完美的方案？如果能，多少影响可以被控制，剩下的部分又该由谁负责？

核心要点

• 智能体编排下的去认证攻击可在2到3秒内完成，防御窗口极窄
• 上下文恢复攻击可让被要求删除的历史信息重新被套出，暴露指令遵循验证的空白
• 单一策略执行点难以扩展到覆盖全部智能体交互，零信任的"谁来验证验证者"问题突出
• 水平异常表明智能体在单一任务上的正确行为不能外推为全局可信
• 分布式账本、AI物料清单、形式化验证被视为构建信任溯源的可能路径