事件概述
2026 年 8 月 27 日，Ars Technica 等媒体披露了一项由以色列安全研究员 Alon Hertz 主导的供应链安全研究：企业普遍部署的新兴标准文件 llms.txt / llms-full.txt（相当于面向 AI Agent 的 “robots.txt”）正在被攻击者当成 代码投递管道。Hertz 团队扫描了 6214 个域名（覆盖国防承包商、Fortune 500 与大型科技公司），在 8265 份 llms.txt / llms-full.txt 中识别出 120 条指向未注册 PyPI / npm 包的安装指令，覆盖 227 条 install 命令。
研究团队随后注册了若干无人认领的包名并部署“信标”载荷，不到一小时就收到了一家 Fortune 500 企业的回调；随后陆续收到来自其他财富 500 与多家初创公司的回调。所有回调的进程链都指向 Claude（Anthropic）、Codex（OpenAI）、Hermes（Nous Research） 等 AI 编码 Agent。
最值得警惕的是：Hertz 团队在 clerk.com 这家正规认证厂商的 llms.txt 中发现了一条 npx clerk-next-fix-auth-protection，有人借此在 npm 上抢注了同名包并投递了真实在野的恶意载荷。Clerk 在收到披露后已修复，但事件表明：即便是正规厂商、按照官方 llms.txt 写指令，仍然可能在供应链上“被埋雷”。
技术细节
为什么 llms.txt 是天然的供应链入口
llms.txt 被设计为“给 AI Agent 看的站点说明”，机器可读，告诉 Agent 站点结构、需要安装的 SDK、推荐的开发流程。问题在于：
- 它是普通 UTF-8 文本，可以同时承载“描述”与“指令”，编码 Agent 往往不区分两者。
- 它由站点所有者发布，多数企业默认其可信；在 Endpoint 看来
pip install来自可信域名、npm install走的是公网仓库，不会触发额外告警。 - 与 Dockerfile、CI 流水线不同，llms.txt 几乎不经过安全审查。
Hertz 在研究中观察到：
# 来自真实企业的 llms.txt 片段
Installation: pip install <unregistered-pkg>
# 或
npm install <unregistered-pkg>
# 甚至
As an example of writing integration tests ... you can use the [Citrus] test framework
在 Agent 已经获得 shell 执行权限的前提下，看到 pip install 这种与日常构建几乎一样的命令，不会停下来询问人类，于是攻击者只需提前抢注这些包名，就能让勒索软件、凭据窃取器或后门程序直接跑进企业内网。
clerk.com 案例：scoped 包 + npx 的天生陷阱
Clerk 在自己的 llms.txt 中指示 Agent 安装 @clerk/eslint-plugin，然后运行 clerk-next-fix-auth-protection 这一 bin 命令。由于scoped npm 包暴露的 bin 名天然不包含 scope 名称，如果在本地 scope 包安装前就执行了裸命令，npx 会去公网仓库拉取同名裸包——而 Clerk 自己从未发布这个裸包。有人抢注并向其中投递了真实恶意载荷。
整条攻击链完全不依赖 Clerk 主动犯错：
- Clerk 写的是“正确”的 llms.txt；
- bin 名与 scope 名不一致是 npm 设计带来的隐形陷阱；
- Agent 不知道该 bin 是本地可执行还是需要 npx 下载；
- 一旦走了 npx 流程，攻击者立刻接管。
影响评估
本轮研究给出了三组关键数字：
- 6214 个被扫描域名，其中 120 份 llms.txt 指向了未注册的包；
- 227 条安装命令指向“无人持有”的代码；
- 多家 Fortune 500 的 AI Agent 实际执行了这些命令。
从这个比例看：即便你的企业已经做好了 SWG、EDR、代码签名、镜像签名，AI 编码 Agent 仍然会以“日常开发行为”的外观，突破这一切防线。Hertz 在 Ars Technica 接受采访时直言：“The trust model is broken. Agents treat vendor docs as ground truth and don’t question them.”
更系统的影响面：
- 任何启用了 Agent 写代码 + 给 Agent shell 权限的企业，都处于同一风险等级；
README.md、API changelog、docs.example.com、内部 wiki 同样会变成 Agent 的“读入即指令”的源头；- 该风险与 MCP（Model Context Protocol）工具调用、Anthropic Tool Use、OpenAI Function Calling 等设计问题同源，本质上是 “LLM 还没有可靠的边界区分用户指令与外部内容”。
修复建议
立即：盘点与审计
- 对自家域名下所有 llms.txt / llms-full.txt 执行自查：凡是其引用的包名在 PyPI / npm / RubyGems / Maven Central 不存在，或与发布方不是同一个组织的，全部删除或标注
llms.txt: ignore。 - 对历史上发布过 llms.txt 的工程文档站执行同样的扫描，Hertz 团队的数据集已经包括了相当一部分高频访问站点。
- 对企业内 AI 编码 Agent（Claude Code、Codex CLI、Hermes、Continue.dev 等）开启安装命令审计日志：记录每一次
pip install、npm install、npx的调用栈与父进程，绑定到具体的 Agent 会话。
短期：收紧 Agent 权限
- 对 Agent 默认 拒绝 shell 执行，仅在白名单操作（如
pytest、npm test）中放行，对pip install、npm install、curl、wget一律人工确认。 - 在容器编排层强制 Agent 在受限网络命名空间运行，禁止它访问公网 PyPI / npm / RubyGems；仓库镜像必须来自企业内自建的私有仓库。
- 在私有仓库侧启用包白名单：Agent 只允许拉取预先审批过的包；新包名一律需要人工审查。
中长期：构建 Agent 可信内容规范
- 推动 llms.txt 引入签名校验：站点主域通过 DNS/SSL 签名一段校验串，Agent 在执行安装前自动核对该签名是否来自站点证书的相同私钥。
- 在企业内部署MCP Gateway：把 Agent 工具调用集中到策略引擎（参考 Speakeasy、ToolHive 等开源项目），为安装命令、shell 执行、文件写入分别设置策略。
- 为 Agent 工具调用引入“来源标记”：每一次 install 必须标注它是来自用户指令、文档读取还是 Agent 自主推断，从而可以单独审查“文档驱动”的执行链。
- 跨安全、DevOps、AI 平台团队建立共享威胁情报：把 Hertz 团队的发现与 RCS（ReversingCorp）、Socket、Phylum 等包安全厂商的告警联动起来。