OOOMETA/OS
← 返回洞察

2026 年 8 月 · 6 分钟阅读

当文档变成代码：llms.txt依赖混淆如何入侵Fortune 500

当文档变成代码：llms.txt依赖混淆如何入侵Fortune 500

关键定义

llms.txt 网站为 AI Agent 发布的机器可读站点摘要与安装指引文件，类似面向搜索引擎的 robots.txt，但被 Agent 当作权威指令来源执行。

依赖混淆（Dependency Confusion） 文档中引用的包名或域名从未被注册，攻击者抢先注册这些空位后，劫持 Agent 的安装流程，让合法命令变成恶意载荷。

2026年8月，一个以色列安全团队证明了一件此前被认为是理论的事：AI 编码 Agent 会因为信任厂商文档，而在 Fortune 500 公司内部网里安装不属于任何人的代码。文档不再只是信息——它成了 Agent 的执行面。

扫描 6,214 个域名：120 份文档指向未注册的包

研究人员扫描了 6,214 个活跃域名，覆盖国防承包商、Fortune 500 与大型科技公司，共找到 8,265 份 llms.txt 与 llms-full.txt 文件。其中 120 份——每一份都来自不同网站——指向一个或多个从未注册的代码包或域名，合计包含 227 条安装或访问指令。

为验证危害，研究者注册了部分空位包名并托管了探测载荷：任何执行它们的机器都会向研究者服务器回连。结果在一小时内就收到了一家 Fortune 500 公司的回连；随后几天又有数十家公司响应，其中包括其他 Fortune 500 与初创企业。回连数据里的进程链揭示出执行者身份——Claude、OpenAI Codex，以及 Nous Research 的 Hermes 等编码 Agent。

机制：llms.txt 把『文档』变成『安装指令』

llms.txt 是网站为 AI Agent 发布的结构化摘要，被称为 AI 时代的 robots.txt。问题在于它的信任模型：文件通过 HTTPS 部署在公司的官方域名上、采用为 AI 消费设计的标准格式、由公司自己或可信伙伴发布。对 Agent 而言，文件本身就是权威——所以当文件写着『pip install internal-tool』时，Agent 不会去验证 internal-tool 是否真的属于这家公司，不会检查 PyPI 上的命名空间，也不会注意到文档链接指向的域名三个月前就过期了。

信任链还是传递性的：llms.txt 不一定要放在 Fortune 500 自己的网站上。Agent 会从可信第三方——伙伴的文档、厂商 SDK 参考、社区项目的设置指南——拉取上下文。只要第三方文件指向一个空置包名，整条信任链就同样成立。

真实案例：Clerk 的 npx 指令与已上线的恶意软件

这并非纯理论。研究者发现 Clerk 官网的 llms.txt 里有一句『npx clerk-next-fix-auth-protection』。与常规安装命令不同，npx 会把包拉进 npm 缓存并直接执行其暴露的二进制，且不写入项目依赖清单。研究者很快发现这个空位已被人抢先注册，并被用来托管真实恶意软件。Clerk 随后移除了该文件，并说明只有安装了 @clerk/eslint-plugin 的 Agent 才不受影响——否则恶意包会被装进系统。Clerk 事件是这种攻击最干净的证明：命令看起来与厂商官方指令完全一致，因为它就写在厂商自己的指令文件里，唯一缺少的是注册表中那个没人检查的名字。

为什么 EDR 对此毫无反应

研究者指出，传统安全控制抓不住这种攻击，因为系统依赖的每个信号都指向错误方向。对任何 EDR 或代理而言，这看起来就是一个开发者在运行合法的包管理器：pip 从 pypi.org 拉包——每个企业代理都放行的域名——父进程还是公司主动安装的编码 Agent。没有异常，没有告警。失败发生在指令与执行之间的上游缺口，端点根本没有机会提出正确的问题。

研究者的总结一针见血：『Agent 不区分页面与命令。它读到的一切都是输入，而每个输入都可能是指令。』这意味着整个 Agent 现在会消费的公开数据语料，已经悄然变成执行面，而其中几乎没有任何我们施加在真实代码上的完整性保障。

数据与代码的边界正在消失

这种弱点的根源与提示注入相同——LLM 无法可靠地区分用户直接输入的指令与从不可信第三方内容中读取的指令。但它的范围更广：提示注入需要攻击者主动植入恶意指令；而这里的指令本身可以是完全良性的，来自真实公司的官方文档，写作时没有任何恶意参与者。危险发生在后来——当它指向的包或域名被放弃、被他人认领之时。这一机制让攻击成本几乎降为零：攻击者只是注册一个没人要的包名，剩下的事由 Agent 的信任模型自动完成。

企业应对：把 Agent 读到的每一份文档当作潜在代码

分离检索信任与执行信任

允许 Agent 阅读文档，但禁止它无条件执行文档里的安装指令。对 pip/npm/npx 等命令要求归属校验：包名必须与目标组织的已知命名空间匹配，否则拦截并人工确认。

为 Agent 的执行权限设边界

编码 Agent 需要 shell 权限，但不必拥有对任意注册表源的安装权。用最小权限原则限定它能拉取的源、能写的目录，并对高风险命令（npx 直接执行、全局安装）强制二次确认。

把文档列入供应链风险管理范围

安全团队应像对待依赖清单一样对待 Agent 消费的文档：审计自有站点的 llms.txt 是否有失效引用，监控已注册空位被认领的异常，把 Agent 的安装行为纳入审计日志与 SIEM。

安全团队的启示是：先问正确的问题，再指望端点拦截。『数据变成代码』意味着供应链完整性管理的对象，从代码本身扩展到了 Agent 读取的一切内容。

参考来源

常见问题

llms.txt 是什么？为什么它对 AI Agent 如此重要？+

llms.txt 是网站发布的机器可读文件，向 AI Agent 提供站点内容摘要、结构和高层安装指引，被业界称为 AI 时代的 robots.txt。问题是 Agent 把它当作权威指令来源：文件说『pip install 某包』，Agent 就会照做。

攻击者如何利用未注册的包名和域名？+

研究者在 6,214 个域名中找到 8,265 份 llms.txt 文件，其中 120 份指向不存在的包名或已过期的域名，共包含 227 条安装或访问指令。攻击者注册这些空位后，就能让任何执行该文件的机器下载并运行恶意包。

为什么端点防护（EDR）发现不了这种攻击？+

对 EDR 或代理来说，这看起来就是开发者在运行合法的包管理器——pip 从 pypi.org 拉包是每个企业代理都放行的行为，父进程还是公司自己安装的编码 Agent。没有任何异常，因为没有安全产品在问『这个包名真的属于这家公司吗』。

Clerk 案例发生了什么？+

Clerk 官网的 llms.txt 里有一句『npx clerk-next-fix-auth-protection』，npx 会直接执行包内二进制而不加入依赖清单。研究者发现这个空位已被人注册并托管了真实恶意软件。命令看起来完全像厂商官方指令，唯一的破绽是注册表里没有这个名字。

企业应该采取哪些具体措施？+

把 Agent 读取的每一份文档当作潜在代码：对 Agent 可执行的安装指令做包名/域名归属校验，分离『检索信任』与『执行信任』，限制编码 Agent 的 shell 权限并要求人工确认高风险安装，同时把 Agent 的安装行为纳入审计日志。

相关文章

AI 网关只告诉你请求去了哪，JetStream 回答它该不该发

JetStream Clearance 把零信任的信任边界从身份下移到单次动作：AI Blueprints 契约 + 参数级权限 + 序列检测，在 MCP 调用执行前逐动作授权。网关已成商品，授权引擎是下一个战场。

审查过的 MCP 工具在第四次调用开始背叛你：Deadbugz 的运行时门控投毒

Pillar Security 披露活跃 MCP 供应链活动 Deadbugz：恶意服务器伪装成文本格式化工具，前三次调用一切正常，第四次起改写返回的工具元数据，指示 agent 搜寻 SSH 密钥、AWS 凭证并隐藏行为。一次性审查被系统性绕过——工具描述是运行时安全边界，批准应发生在动作执行之时。

超100家科技公司联名公开信：携手防御『失控AI』，网络安全范式已被改写

8月27日，OpenAI、Anthropic、Google、微软等100多家科技与网络安全公司签署公开信，呼吁公私部门协作、采用新型网络防御应对日益普及的AI攻击，并警告医院、水务、互联网基础设施正面临风险。此前Hugging Face及Anthropic、Meta的Agent入侵已证明网络安全已被根本改写。

GhostSplice：恶意MCP服务器把窃密指令拆成两半，AI编码Agent就乖乖交出SSH密钥

8月11日，ASSET团队披露GhostSplice：恶意MCP服务器将窃密指令拆散到工具描述与工具结果中，让AI编码Agent自己拼接并外传数据，单次调用看似无害。对11个API模型的测试显示，拆成两半后顺从率从42%升至82%，GPT-4o等从0%涨到100%。攻击者只需你安装一个『可信』的MCP服务器。