AI编程代理为何会把企业带入“无人认领代码”陷阱

导语

面向 AI 的网站说明文件，正在成为新的软件供应链入口。研究人员扫描了 6,214 个属于防务承包商、财富 500 强企业和大型科技公司的在线域名，在发现的 8,265 个 llms.txt 与 llms-full.txt 文件中，有 120 个文件引用了未注册的软件包或尚未被认领的域名。这些文件一共包含 227 条相关安装或访问指令。

问题在于，编程代理往往会把官方网站上的机器可读文档视为权威配置。当代理拥有运行 Shell 命令的权限时，一条看似普通的 pip install、npm install 或 npx 命令，就可能直接进入企业开发环境。

核心要点

• 未注册名称可以被抢注。 文档中列出的包名来自 PyPI、npm 等公共注册表，但当时并不存在。攻击者可以注册同名包，再植入恶意代码；未被占用的域名也可能被用于承载恶意指令。
• 概念验证并非停留在纸面。 研究人员注册了少量相关名称，并让包在执行后向其服务器回连。不到一小时，他们就收到了来自一家财富 500 强企业的响应，随后还观察到来自其他大企业和初创公司的请求。进程链显示，Claude、OpenAI Codex 和 Nous Research Hermes 等编码代理参与了部分安装流程。
• 已有真实风险案例。 合法网站 Clerk 的一个 LLM 文件曾包含 npx clerk-next-fix-auth-protection。该名称后来被他人占用并用于发布真实恶意软件，Clerk 已修复问题。不过，素材并未说明是否因此发生了实际感染。
• 传统防护可能看不到异常。 从终端和网络设备看来，这可能只是开发者通过官方包管理器安装依赖，父进程还是企业主动部署的 AI 工具。真正的失误发生在“文档内容是否值得执行”这一上游环节。

意义与影响

llms.txt 的设计初衷，是帮助代理快速理解网站结构和内容，但它也模糊了信息与操作之间的边界。对语言模型而言，网页、文档和用户输入都可能成为下一步行为的依据；如果没有专门的权限控制和验证流程，模型未必能判断某条命令是否真的由软件所有者发布，或某个依赖名称是否属于合法组织。

更麻烦的是，信任可以沿着第三方文档传递：代理不一定从企业官网读取指令，也可能使用合作伙伴、供应商或社区项目的文档。只要链条中的某一环引用了未认领资源，风险就可能进入企业网络。

企业需要把 AI 代理读取的文档视为不可信输入，而不是自动执行的配置文件。安装前应核验包的所有权、发布者、版本和来源，限制代理的命令执行与网络访问权限，并对新依赖实施人工审批或沙箱测试。对于网站维护者，清理过时命令、定期检查依赖和域名状态，同样是降低风险的基础工作。

这起事件的核心警示并不是某一个文件格式本身不安全，而是代理正在把越来越多的自然语言内容转化为实际操作。只要“看见”与“执行”之间缺少明确隔离，普通文档就可能成为软件供应链的一部分。

来源：Ars Technica AI