工具更新缺口：代码变更后，智能体仍继续信任该工具

这是什么？

2026年11月1日，上海交通大学和Inria的研究人员在arXiv（cs.CR）发表了《Beyond Prompt Injection: The Tool Update Gap in LLM Agent Security》。论文指出，智能体框架只在首次集成时建立对工具的信任，之后即使工具的实现发生变化，仍继续信任它。这一缺口使常规软件更新变成了进入智能体的供应链通道。

这是关于设计层面弱点的研究，并非针对某个具体产品的已披露漏洞。

工作原理

智能体依赖外部工具调用服务和访问网络资源，而这些工具会通过更新不断演进。更新后的代码在模型的上下文窗口之外执行，因此以这种方式发起的攻击无需触及提示词：不存在以模型为中心的防御能够看到的对抗性指令。

作者构建了名为ETUDE（Exploiting Tool Updates for Direct Execution）的概念验证。它从一个良性工具出发，在后续更新中加入恶意行为，同时保持工具的合法功能正常。他们在七个商业和开源智能体框架（包括Gemini CLI、Codex CLI和Claude Code）上评估了三种攻击负载。报告结果：攻击成功率为97.6%，而合法任务仍有95.9%能够完成，因此被入侵的工具看起来运行正常。他们还指出，现有防御提供的保护较弱。

本文不复现任何攻击代码或负载细节。

为什么重要

大多数智能体安全研究关注模型读取的内容：提示词、检索到的文档、工具描述。这一结果把问题转移到工具在运行时实际做了什么。它与此前的工作互为补充，例如MalTool（2026），该研究发现传统恶意软件扫描器和针对智能体的防御在检测恶意工具代码方面都表现不佳。综合来看，对于持续变化的工具，仅在安装时进行一次审查是不够的。

防御措施

论文的核心建议是：每当工具的实现发生变化时就重新验证信任，而不只是在首次集成时。实践中：

• 固定版本。 以固定版本或哈希安装工具；不要在智能体运行环境中自动更新。
• 变更即复审。 将每次工具更新视为一次新的审批事件，对代码和声明的权限做差异比对。
• 隔离执行。 在沙箱中运行工具代码，对文件、网络和凭据采用最小权限。
• 监控行为。 记录工具的网络调用和文件访问，并在更新后出现新的目标地址或异常数据量时告警。
• 不要只依赖提示词层面的过滤。 它们看不到在上下文窗口之外运行的代码。

状态

项目	详情
来源	arXiv:2611.01976 v1，2026年11月1日提交
性质	针对7个智能体框架的学术概念验证
厂商补丁	不适用；属于设计层面的缺口。建议的控制措施是每次更新时验证