你公司的 AI 编码 Agent 正在阅读一篇文档—— 它看到 pip install internal-tool，它看到 npm install auth-fix-plugin。 它没有问这个包是谁的、有没有注册、是不是假的。 它直接执行了。

这就是 2026 年 AI 安全的最新战场：llms.txt 供应链攻击。

研究：6,214 个域名，120 个突破口

一家以色列安全初创公司的研究员——包括 Alon Hertz——干了一件既聪明又吓人的事。他们扫描了 6,214 个活跃域名，涵盖国防承包商、Fortune 500 企业、大型科技公司。

目标只有一个：llms.txt。

这是一个由 AI 社区推动的「AI 版 robots.txt」。网站用它向 AI Agent 提供结构化的机器可读摘要：该读什么、该装什么、该信任哪些 API。

结果触目惊心：

• 他们找到了 8,265 个 llms.txt / llms-full.txt 文件
• 其中 120 个文件（分布在 120 个不同网站）指向了不存在的代码包或已过期的域名
• 总共有 227 条安装指令（pip install、npm install、npx）指向无人认领的包

研究员注册了其中几个无人认领的包名，托管了一段验证信标代码。结果——

一小时内，就收到了第一个 Fortune 500 公司的回连信号。

不是几天、不是几周。是一个小时。

攻击链拆解：四层信任崩塌

为什么这招如此致命？因为它不是传统的漏洞，而是 Agent 时代特有的信任链危机。

L1: llms.txt 的「权威幻觉」

当一个 AI 编码 Agent 遇到 llms.txt 文件时，它看到的不是一个「建议」，而是权威文档：

• 文件通过 HTTPS 传输
• 文件位于公司官方域名下
• 文件使用专为 AI 设计的标准化格式
• 文件由公司自身或其信任的合作伙伴发布

Agent 没有理由怀疑它。 llms.txt 的存在目的就是权威——它是为了告诉 AI「该怎么做」而设计的。当它说 pip install internal-tool 时，Agent 不会去检查 internal-tool 在 PyPI 上是否真的属于这家公司。

L2: 无人认领的包——写于 AI 时代之前的「定时炸弹」

这 227 条指令是如何进入 llms.txt 的？研究员推测有多种来源：

• 人为错误：很多错误条目在 AI 时代之前就已存在于网站的普通文档中，后来被导入 llms.txt
• AI 幻觉：有些内容是 AI 生成的，而 AI 本身无法区分「合法指令」和「虚构指令」
• 域名过期：文档中引用了公司内部域名，但域名已过期未续费

无论来源，这些指令就像定时炸弹——包名在注册表里空着，谁先注册谁就能接管。

L3: Agent 自动执行——Fortune 500 秒变攻击入口

研究员注册包名后，信标代码被放置在 PyPI/npm 上。当 AI 编码 Agent 执行 pip install 指令时：

1. 包管理器从 PyPI 下载包
2. 包中的安装脚本自动执行
3. 信标代码向研究员服务器发起回连请求
4. 进程链记录了父进程身份——Claude、Codex、Hermes

这些 Agent 运行在世界最强大的公司内部网络中。EDR 和代理防火墙没发出任何警报——因为这看起来就是一次正常的开发者 pip install 操作。源是 pypi.org（每个公司代理都放行的域名），父进程是公司自己安装的编码 Agent。

没有任何异常。没有任何警报。

研究员写道：「每一层信任都是完整的——除了没人想到要检查的那一层。」

L4: 真实世界的攻击已在进行

最令人不安的发现是：这不是理论攻击。

研究员在 clerk.com——一个合法的身份验证服务商——的 llms.txt 文件中，发现了一条指令：

npx clerk-next-fix-auth-protection

这条指令指向的 npm 包 @clerk/eslint-plugin 在当时是无人认领的。任何受其信任的 AI Agent 读到这条指令，都会自动安装该恶意包。

「Clerk 案例是最干净的证明。这条指令看起来完全像是官方发布的一样——因为它就在官方自己的指令文件里。唯一缺失的是注册表里的名字。」

Clerk 已修复该问题，但如果 Agent 在此之前已经安装了 @clerk/eslint-plugin，其中的恶意代码已经执行。

不止于 llms.txt：数据与代码的边界正在消失

这场攻击的真正深刻之处在于：它揭示了一个根本性的范式转移。

一直以来，数据（data）和代码（code）之间有一条清晰的边界。数据是你可以安全读取的；代码是需要你决定是否执行的。浏览器知道 HTML 是数据，JavaScript 是代码。操作系统知道文档是数据，二进制是可执行程序。

但 AI Agent 打破了这个边界。

「Agent 不会区分网页和命令。它读到的一切都是输入，每个输入都是潜在的指令。」

这意味着整个已发布的语料库——所有 Agent 正在被训练去消费的数据——在静默地变成一个执行面。我们应用在代码上的完整性保障，几乎没有一项被扩展到这些文档上。

研究员特别指出：这个问题远比 llms.txt 大得多。指令——无论是显式还是隐式的——几乎存在于 Agent 遍历的每个角落。README.md、GitHub Wiki、企业知识库、技术博客——任何含有安装指令的文本都可能成为攻击向量。

防御方案：Agent 供应链安全的五道防线

面对这种「数据即代码」的新型攻击，传统安全手段力不从心。以下是五道防线：

1. 命名空间验证（第一道防线）

在允许 Agent 执行 pip install / npm install 之前，先验证包名是否属于可信组织：

• 检查 PyPI/npm 上的包名是否与公司官方命名空间匹配
• 对内部包使用私有注册表，配置 Agent 不从公共源拉取名为 internal-* 的包
• 利用包注册表的 API 查询包的上传者组织

2. 沙箱化执行（第二道防线）

不要让 Agent 拥有直接执行 shell 命令的权限。配置沙箱：

• 使用 sandbox 或容器化环境执行 Agent 的安装命令
• 设置出站流量白名单（只允许特定域名）
• 使用类似 MCPZERO 的渐进式工具发现机制——不是所有文档中的指令都自动获得执行权限

3. llms.txt 内容审计（第三道防线）

如果你的公司使用 llms.txt，请将其纳入常规安全审计：

• 定期扫描 llms.txt 中所有 pip install、npm install、npx、curl 指令
• 验证每个引用的包名在注册表中确实属于你的组织
• 对已过期或未注册的域名立即移除或更新

4. EDR 规则增强（第四道防线）

传统的 EDR（端点检测与响应）无法识别这种攻击，因为进程链看起来「正常」。需要新增检测规则：

• 监控 pip install 和 npm install 在 AI Agent 进程下的调用
• 对首次安装的包名做品牌/命名空间分析
• 标记从公共注册表拉取但包名暗示内部用途的行为（如包名包含公司名但发布者非公司官方账号）

5. 供应链治理文化（第五道防线）

技术手段永远不够。需要改变开发团队对 AI Agent 的认知：

• 教育开发者：Agent 不是不可质疑的——它从任何文档中读取的指令都应该像 PR review 一样经过审查
• 建立 Agent 行为政策：明确 Agent 可以在什么条件下执行安装命令
• 操作手册落地：将上述检测规则嵌入 CI/CD 管线和监控系统

写在最后

Dan Goodin 在 Ars Technica 上的报道引用了研究员的一段话，我反复读了好几遍：

「在 prompt injection 攻击中，有人故意植入恶意指令。
而在这里，指令本身可以完全是良性的，来自合法的来源——一家真实公司的官方文档——编写时没有任何恶意参与者。
危险来自后来：当它指向的包或域名被遗弃，然后被别人认领时。」

这正是 llms.txt 供应链攻击最可怕的地方。受害者的信任链没有任何一环是伪造的。 HTTPS 证书是真的。域名是真的。公司是真的。文档是官方写的。唯一的问题——没人跟踪那个包名后来发生了什么。

这种攻击不需要入侵者「攻破」任何系统。他们只需要注册一个已过期的域名，或认领一个无人使用的包名，然后等着 AI Agent 自己来敲门。

对比我们之前分析的 《Agentjacking：一个假 Sentry 错误报告就能劫持你的 AI 编码 Agent》，这次的攻击面更广：

在数据与代码边界模糊的时代，每一个站点上的 pip install 都是一个潜在的初始访问向量。每一次 Agent 的自动化执行，都可能演化成一场供应链入侵。

企业 AI 安全的第一课：别让你的 Agent 盲目相信它读到的一切。

📌 延伸阅读：《Agentjacking 横空出世！一个假 Sentry 错误报告就能劫持你的 AI 编码 Agent》 — Agent 安全系列的又一重要篇章