一句话看懂：安全研究人员通过篡改企业发布给 AI 阅读的 llms.txt 文件，成功诱导 Claude、Codex 和 Hermes 等编码代理在真实企业网络中执行恶意包。这不是漏洞利用，而是 AI 代理过度信任文档内容导致的供应链风险。
事件核心：发生了什么
以色列一家隐身初创公司的研究员 Alon Hertz 发现了一个不需要零日漏洞的攻击路径。企业为了让 AI 系统更好地理解网站内容，通常会发布名为 llms.txt 或 llms-full.txt 的纯文本文件。研究人员扫描了 6,214 个与国防承包商、财富 500 强和大型科技公司相关的活跃域名，在 8,265 个此类文件中，发现 120 个文件（每个来自不同站点）引用了未被注册的包名或域名。更具体地说，共有 227 条安装命令指向了无人拥有的代码。
研究人员随后注册了其中部分未认领的名称，并托管了执行时会回传信号的恶意包。结果在一小时内，就有一家财富 500 强公司触发了回调。日志显示，触发动作来自 Anthropic 的 Claude、OpenAI 的 Codex 和 Nous Research 的 Hermes 等 AI 编码代理。目前公开信息显示，Anthropic、OpenAI 和 Nous 在 Ars Technica 报道发布前未予置评。
为什么重要
这件事的核心问题在于信任模型的崩塌。编码代理的工作流程是：读取企业官方域名上的文件，将其视为可信指令，然后直接执行 pip 或 npm 命令。域名可信、包管理器可信、代理本身也可信，这条链路恰好成为攻击面。llms.txt 常被比作“面向 AI 的 robots.txt”，但它与 robots.txt 的本质区别在于：代理可以在同一工作流中从“读取”直接跳到“运行命令”。
一个更现实的案例佐证了风险：身份验证公司 Clerk 官网的 llms 文件中包含命令 npx clerk-next-fix-auth-protection。由于 npx 可以拉取包到缓存并执行其暴露的二进制文件，若本地缺少依赖，该命令会去公共注册表查询这个裸包名。而该名称已被他人认领并托管恶意软件。Clerk 表示若本地已有 @clerk/eslint-plugin 则无威胁，但 Ars Technica 证实该问题已解决。Clerk 本身不需欺骗用户，弱点就藏在正常文档和公共注册表的空白之间。
对用户/开发者/创作者的影响
对于部署 AI 编程助手的开发团队，这意味着任何写入官方文档的“安装提示”都可能成为被利用的入口。编码代理不具备人类开发者那种“看到陌生包名会停顿并怀疑”的上下文判断力，它们会以对待开发者粘贴命令的同等级信任去执行文本内容。企业需要重新审视文档中出现的所有安装命令，尤其是那些指向公共注册表、却又未显式声明来源的裸包名。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对于使用 Claude、Codex 或 Hermes 的个人开发者，建议在 CI/CD 流程中启用包来源锁定（如 lockfile + registry 白名单），并关注代理工具是否提供了“仅阅读、不执行”的严格模式。目前公开信息显示，三家模型提供商均未对此事发表正式回应。
值得关注的后续
第一，llms.txt 的采用率仍然很低。2026年3月 ProGEO.ai 的研究显示，财富 500 强中仅 7.4% 发布了该文件，但风险已经提前到来。第二，公共 npm/PyPI 注册表上的“名称抢注”问题是否会引发新的治理或验证机制，值得关注。第三，Anthropic、OpenAI 和 Nous 是否会调整代理产品的默认信任策略，例如对文档内的安装命令增加域名匹配校验或人工确认步骤，将是下一步观察重点。
