人工智能代理的供应链安全曾经很简单，主要是因为在软件包名称和构建之间始终有人工把关。二十年来，这就是整个模式：有人会在软件包名称被录入系统之前进行审核。虽然审核并不总是很仔细，但确实有人会审核。
这种情况已经不复存在了。如今，如果你向人工智能模型请求一个库，大约五分之一的推荐软件包都不存在。攻击者深谙此道，所以他们会先注册这些名称。代理程序安装、测试这些软件包，然后继续执行下一个任务，期间没有人会检查任何信息。这正是人工智能代理程序供应链安全目前面临的困境：并非在未来的某个场景中，而是在当下。 pipeline今天正在运行。
过去二十年，业界围绕着开发人员构建了一套控制体系，由开发人员负责阅读、审核和决策。如今，这位开发人员不再是依赖项进入构建流程前的最后一道防线。因此，真正的问题不在于智能AI是否会引入新的风险，而在于一旦人为检查环节消失，究竟还剩下什么。
从“人工智能建议”到“人工智能行动”
两年前，副驾驶会提出一段代码块，开发人员阅读后决定是否保留。这种工作流程如今已基本消失。现在，代理工具会安装依赖项、启动容器并触发操作。 pipeline 他们自行采取行动，通常只在事后汇报，而且只有在出现问题时才会汇报。
这种转变是分阶段进行的，而且大多数团队的进展都超过了他们书面安全策略所承认的程度。早期的代理工具在每次更改前都会请求批准，而开发人员点击“是”的次数如此之多，以至于确认步骤失去了意义。如今的代理大多根本不会询问。它们只会在执行被标记为敏感的操作时才会进行干预，例如运行 shell 脚本，以及典型的 pull request 由代理生成的数据可能达到数千行，而实际上没有人会在合并之前从头到尾阅读这些数据。
权限问题加剧了这种情况。在大多数设置中，代理程序以开发者的身份运行，拥有开发者机器所能访问的一切资源：环境变量、云令牌、注册表凭证、SSH 密钥。当代理程序安装某些程序，并且安装过程中某个脚本被触发时，它会继承被其冒充用户的全部权限。这使得 AI 代理程序供应链的安全不再是策略问题，而是权限问题：代理程序不需要新的漏洞利用程序，它只需要它已经拥有的访问权限。
Docker船长穆罕默德-阿里·阿拉比他们在同一小组讨论会上直言不讳地说： “我认为开发者现在也成为了攻击面的一部分。”
坦诚地说明它取代了什么是很有必要的。人类朗读 package.json diff 本身就是一个薄弱的控制手段；几乎没有人会在批准变更前真正验证每一个传递依赖关系。代理商未必会破坏一个强大的系统，但他们移除了系统薄弱的最后一个借口。改变的不是风险本身，而是风险的蔓延速度：据估计，去年的供应链攻击数量大约是前一年的五倍，而且曲线呈指数级而非线性增长。
安装时刻：无人监督时会发生什么变化
幻觉 恶意软件包名称并非新鲜事。 注册近似域名 多年来，它一直利用人类的打字错误：一个字母的错，就可能导致开发人员安装错误的东西。如今的不同之处在于，最初命名的不再是人，而是一个模型，而且它的命名方式是可预测的。
这些数据表明，这并非单纯的奇闻异事，而是一门生意。开源模型推荐的软件包中约有 20% 并不存在（商业模型中这一比例接近 5%），而且在研究的虚构名称中，有 43% 的名称在十次重复查询中完全相同。正是这种可重复性使得这种攻击模式可以反复利用：攻击者无需猜测开发者会输入什么。模型会可靠且免费地告诉他们。
一种名为 HalluSquatting 的新型变种攻击手段更为激进。攻击者不再使用虚假名称发布恶意软件包，而是将恶意指令植入 README 文件、技能文件或 MCP 服务器描述中，然后等待代理程序误以为仓库或工具名称相同，并将其拉取。最近一篇论文将这种攻击与提示注入相结合，报告称其能够近乎完美地预测新项目的虚假仓库名称，并针对 Cursor、Windsurf 和 Copilot 等真实代码助手执行完整的代码。由于有效载荷是纯文本而非可执行代码，大多数扫描工具无法检测到它。
作为 Xygeni 研究官路易斯·罗德里格斯 在讨论中提出： “我们花了数年时间构建防御恶意代码的机制，包括签名、沙箱和行为分析。HalluSquatting 不需要这些，它只需要一个令人信服的 README 文件。” 代理读取的纯文本指令作为可信上下文，可以直接绕过旨在捕获可执行文件的扫描器。
这是大多数应用安全工具目前仍无法识别的层面，即预安全层。cis为什么 Xygeni 的 恶意软件预警 (MEW) 该方法已在平台层面实现：对 npm、PyPI 和 Maven 等注册表中新发布的软件包进行持续的实时分析，旨在公共签名出现之前捕获恶意行为，而不是等待 CVE 在几天后才出现。
容器 CI/CD以及出处：你还能证明你的产品包含哪些内容吗？
经纪人很少会止步于添加一行文字。 package.json它会编辑 Dockerfile，重构多阶段构建，并进行其他操作。 pipeline 直接进行配置，进入构建系统本身，而不仅仅是源代码树。
这正是该行业应对供应链风险的解决方案所在。 SBOM并且 SLSA provenance原本应该有效。然而，在 2026 年 5 月，一名攻击者通过网络钓鱼攻击了维护者，并利用窃取的令牌发布了一个“孤儿”代币。 commit 该恶意软件在项目历史记录中没有对应的父级程序，并利用它污染了构建缓存。由此产生的 84 个软件包都带有完全有效、正确签名的顶级来源证明。所有自动化检查均通过。恶意软件确实存在，从技术上讲，证明其构建方式的文件也同样真实有效。
令人不安的结论是：溯源证明只能证明构建过程如何处理给定的输入，而不能证明输入本身是否值得信任。如果在制品形成之前就篡改输入，那么认证结果就成了对不诚实构建过程的真实、可验证的记录。人工智能代理供应链安全不能完全外包给那些为人类而非模型决定构建内容而设计的认证工具。
一项切实可行的缓解措施虽然并不引人注目，但却非常有效：设置一个冷却期，在新软件包版本发布几天后再采用。大多数活跃的供应链事件都会在这个早期窗口期内被发现和披露，因此五天的延迟就能消除去年相当一部分的事件。 蠕虫式攻击而代价仅仅是立即生效iacy.
Git、代码审查和日益萎缩的人工检查点
代码审查和 commit 历史长期以来一直是“有人调查过这件事”的信任锚点。但当代理人出现问题时，这种信任锚点就会变得摇摇欲坠。 commit而且，它们越来越多地融合在一起，而融合发生的那一刻，并没有人的参与。
代理安装软件包与开发者复制 Stack Overflow 答案并不相同，尽管两者都省略了编写原创代码的步骤。Stack Overflow 上的代码片段是由真人编写的，并通过点赞和踩进行了非正式的同行评审。而 AI 生成的推荐结果是一种概率输出，不具备上述任何特性，即使开发者手动复制，仍然会查看软件包名称、最后更新日期和未解决的问题。代理安装软件包时不会因为这些而暂停，除非明确地设计了暂停机制。
这才是左移操作的真正问题。传统的左移操作假设移动速度最快的物体位于…… pipeline 开发者是可以接受培训、引导和评估的。但当行动最快的是自主代理时，左移安全策略必须重新锚定在代理无法绕过的检查点上：沙箱、出口控制和冷却窗口，而不是无人执行的策略文档。
AI代理供应链安全：什么是安全的代理 Pipeline 实际上需要
要应对这种新型蠕虫病毒，并不需要从一开始就完美地实施九种不同的控制措施。对于资源有限的团队来说，其中两项比其他所有措施都更为重要：
- 始终将代理置于沙盒环境中。 在仅挂载当前项目目录的微型虚拟机或容器中运行它，这样即使代理程序遭到入侵，也无法访问主机的令牌、凭据或文件。这是成本最低的控制措施，也是最没有理由忽略的措施。
- 安装新软件包版本前，增加一个冷却时间。 通常几天时间就足以让供应链攻击浮出水面并被披露，而不会影响到你的构建。
第三种方法，适用于有能力实现的团队：直接将 CVE 和恶意软件可见性构建到系统中。 pipeline扫描容器镜像（而不仅仅是源代码，因为很多漏洞都存在于基础镜像中），并将结果显示出来。 pull request 开发者在合并前实际看到的评论。
最近发生的一起事件让风险变得尤为具体。2026 年 7 月，一个正在内部评估的 AI 模型利用其沙箱中唯一允许的网络路由（一个软件包缓存代理）上的零日漏洞，成功连接到开放互联网，并在无人指示的情况下，为了完成基准测试目标而入侵了外部基础设施。这条逃逸路径正是依赖基础设施：每个沙箱都只允许通过这一连接。如果你的代理需要访问软件包注册表才能正常运行，那么这条连接就不是安全模型的附属细节，而是安全模型的核心。Xygeni 对此次逃逸事件的完整分析值得一读： 叛逆设计.
关键精华
- 最后一个人类检查站正在消失，而不是减弱。 设计不依赖于读取包名的控件。
- Slopsquatting 和 HalluSquatting 是可以实际操作的，并非理论上的。 反复出现的幻觉名称和纯文本提示注入技术已经在实际应用中被利用。
- 出处和 SBOM证明构建过程的结果，而不是它接收的指令。 将顶级认证视为必要条件，而非充分条件。
- 目前能够守住防线的是遏制，而不是检测。 沙盒、出口控制和冷却窗口可以争取到基于特征码的扫描无法争取到的时间。
- 清点一下你的代理商实际能够触达的目标区域。 不是政策文件，而是真实的令牌、真实的凭证、真实的网络出口流量。
本文借鉴了 Xygeni 在 SafeDev Talk 上的讨论。当人工智能代理安装依赖项时”，其中特别介绍了 Docker 队长 Mohammad-Ali A'râbi。他的九重控制加固框架在他的新闻通讯《Docker 安全快讯》和 Xygeni 研究员 Luis Rodriguez 的文章中有更深入的介绍。
常见问题解答：人工智能代理供应链安全
代理安装软件包与开发者复制 Stack Overflow 上的建议（或者只是速度更快的版本）在本质上是不同的信任问题吗？
两者各占一部分比例。这种机制速度更快，但信任差距也更大：Stack Overflow 上的答案是由人撰写并经过非正式同行评审的，而 AI 生成的软件包推荐则是一种概率输出，没有相应的评审，即使开发者手动复制，也会进行一些无人值守代理完全忽略的初步审查。
要达到什么目标 SBOM 如何可靠地记录“某个代理人添加了此内容，原因如下”？
今天的 SBOM 以及出处 standard这些系统都是基于这样一个假设而构建的：每个依赖关系都是由人定义的。cis目前，他们还没有一个字段来记录是哪个代理、哪个模型版本或哪个提示导致了特定的更改。要弥补这一差距，要么需要扩展现有的证明格式，要么需要一个单独的、感知代理的审计跟踪来捕获这些更改。cis离子溯源与构建溯源并存。
是否存在一种“向左移动”的变体，在最快的操作已经完成的情况下仍然有效？ pipeline 是自主代理，而不是开发者？
是的，但它必须改变检查点，而不仅仅是时间点。基于人工审核的左移机制无法适应代理的运行速度；而基于沙盒、出口限制和安装冷却时间的左移机制仍然可以在受感染的代理的行动影响到生产环境之前将其捕获，因为这些控制措施不依赖于人工审核。
