llms.txt 漏洞：AI 代理如何通过文档文件自动安装恶意代码
8 月 27 日周四，Ars Technica 发布了一篇调查报道，令所有使用 AI 编程代理的开发者都应重新审视自身安全。以色列一家隐身初创公司的研究人员扫描了 6,214 个属于《财富》500 强企业、国防承包商和大型科技公司的域名——发现了 120 个 llms.txt 文件，它们导致 AI 代理自动从 PyPI 和 npm 安装不存在的软件包。
问题的核心简单而恐怖：llms.txt 本质上是「面向 AI 的 robots.txt」——一个用 Markdown 编写的站点地图文件，帮助代理快速理解文档结构。但该规范完全没有任何认证、签名或完整性校验机制。如果文件中包含 pip install 不存在的包 或 npm install 不存在的包，而代理恰好拥有执行命令的权限——它就会直接安装文件中写的任何内容。
攻击原理
研究人员共发现 8,265 个 llms.txt 和 llms-full.txt 文件（许多网站两者都部署）。其中 120 个文件——分布在 120 个不同域名上——包含指向注册表中不存在的包或域名的引用。攻击者只需注册这些名字，上传恶意代码即可。
为验证攻击可行性，研究人员亲自注册了几个「空闲」名称，放入仅会向其服务器发送「我已启动」信号的无害包。不到一小时，他们收到了来自一家《财富》500 强企业的回调。随后又陆续收到数十个回调——来自其他巨头和初创公司。进程遥测数据精确记录了是哪些代理执行了安装：Claude Code、OpenAI Codex 和 Nous Research 的 Hermes。
最恶劣的案例 — clerk.com
在合法网站 clerk.com 的 llms.txt 中，赫然写着 npx clerk-next-fix-auth-protection。不同于普通的 npm install，npx 可将包下载到 npm 缓存并直接执行其二进制文件，而不将其加入项目依赖清单。有人抢先注册了这个空闲名称，并上传了真正的恶意软件。Clerk 事后修复了问题，但该攻击模式已在生产环境中出现。
为什么这不仅仅是「模型 Bug」
这既非幻觉，也非沙箱逃逸。文件托管在公司官方域名上，通过 HTTPS 分发，采用专为 AI 消费设计的标准化格式。代理没有任何理由怀疑它——文件本身就是权威。问题在于 llms.txt 规范（由 Answer.AI 的 Jeremy Howard 于 2024 年 9 月提出）完全缺失安全条款：无签名、无来源验证、无包校验。
信任链具有传递性：llms.txt 不必放在《财富》500 强企业自家网站上——它可以放在合作伙伴的文档、供应商的 SDK 参考、社区项目的设置指南中。如果代理信任该第三方，而第三方指向了未注册的包——攻击链照样生效。
现在该做什么
- 审计。 检查你的
llms.txt和llms-full.txt。确保文件中提到的每个包、域名和 URL 真实存在、受你控制、且有明确的维护者。删除那些你凭记忆无法解释的依赖引用。 - 在代理与注册表之间部署代理层。 拦截新包（slopsquatted 包按定义全是新包），对任何依赖的首次发布强制 24–72 小时冷却期，安装前验证
provenance（SLSA/Sigstore）。 - 不要给代理
--yolo、--dangerously-skip-permissions、--trust-all-tools等参数。 这些参数存在的意义是让开发者承担责任。如果代理在未经你确认的情况下安装包——你已把基础设施的钥匙交给了它。
核心结论
「让网站对代理可读」的竞赛，刚刚与「利用软件供应链」的竞赛正面碰撞。这不是某个模型或某个厂商的过错——这是一个没人当成可执行代码看待的标准的设计缺陷。在行业强制要求验证代理在网上读到的内容之前，每一个有问题的 llms.txt 都是通向你网络的潜在入口。
想在隔离环境中测试你的 AI 工作流安全性？NeuralSpace 让你运行代码生成并在隔离环境中测试代理——体验聊天 或 代码模式。