AI 智能体安全危机：代码签名为何失效？揭秘工具投毒的架构盲区

揭露 AI 智能体安全的核心隐患：为何既有供应链管控难以阻挡工具投毒与行为偏移？

在企业级 AI 场景下，AI 智能体（Agents）能依据自然语言指令，从共享注册库中自行挑选并调用工具。然而，一个严峻问题正逐渐显现：当前缺乏任何机制去核验这些工具的自然语言描述是否真实可信。💡

此类安全漏洞绝非虚构。当一位资深 AI 架构师在 CoSAI（安全 AI 工具库）提交 Issue#141 时，该问题正式被确认。工具注册表投毒（Tool Registry Poisoning）并非单点故障，而是贯穿工具全生命周期的多重风险。

过去十年，我们建立了完善的软件供应链控制体系，涵盖代码签名、软件物料清单（SBOM）、SLSA 溯源及 Sigstore。将这些技术迁移至智能体工具注册表看似顺理成章，但实际效果却远不足够。

传统安全措施（如代码签名）主要回答：“该工件是否确为其宣称之物？”

而智能体真正需要的是：“该工具是否按描述运行，且仅执行描述内的操作？”

现有控制手段完全无法解决行为完整性难题。

即便通过了所有工件完整性检测的工具，仍可能潜藏致命威胁：

[译者注]：这好比“挂羊头卖狗肉”，传统安检仅核实了“羊头”标签的真伪，却未发现后台已替换为腐肉。

为填补这一空白，需在模型上下文协议（MCP）客户端（智能体）与 MCP 服务端（工具）间增设一个验证代理（Verification Proxy）。

该代理在每次工具调用时执行三项核心验证：

这是一种机器可读的声明（类似 Android 应用的权限清单），明确列出工具可访问的外部端点、读写数据及产生的副作用。它作为签名凭证的一部分，在运行时不可篡改且可被验证。

结论：单一层面无法提供万全之策。溯源验证难以应对发布后的攻击，而若无溯源验证，运行时验证则缺乏比对基准。架构设计上必须两者兼备。

本文深刻揭示了 AI 时代安全边界的变迁。在传统软件工程中，我们习惯于“信任静态工件”，但在 AI 智能体自主决策的时代，“动态行为的可预测性”已成为新的安全基石。

反观国内当前的 AI 智能体开发热潮，众多企业仍沉迷于“功能快速堆叠”，对 MCP 等协议的安全扩展关注不足。若仅依赖大模型的“自我审查”或简单代码签名，无异于沙上建塔。安全不应是事后补丁，而应是架构设计的首要原则。在享受智能体带来的效率红利时，必须同步构建“运行时行为监管”的防护网。

求点赞 👍 求关注 ❤️ 求收藏 ⭐️你的支持是我更新的最大动力！