你的AI助手可能正在被人利用

你有没有注意到，现在大家都在聊 prompt 注入、模型投毒、训练数据被污染这些问题。但有一个威胁，悄悄藏在角落里，关注的人还真不多——

文档过期，也能成为攻击入口。

最近有个研究团队发现了点有意思的事。他们去翻了翻 llms.txt 和 llms-full.txt 这类机器可读的文档格式，就是那种用来让 AI 理解网站结构的东西。结果一查，好家伙——在几千个属于国防承包商、财富500强和科技巨头的域名里，找到了 120个文件指向的包名或域名早就失效了。

这攻击方式说起来也简单：攻击者根本不用黑进去，他就等着就行。

攻击是怎么实现的

咱们来设想一个场景：

有个开发者在用 AI 编程助手搭建项目。AI 读取了公司内部的 llms.txt 文件，想看看怎么安装依赖。它看到一个叫 cool-utils-lib 的包——然后，因为这 AI 助手有权限直接跑包管理命令，它就顺手给安装了。

问题在哪呢？

这个包名从来就没被人注册过。直到攻击者注册了它。

研究人员在实验里还真就这么干了。他们把这些废弃的包名抢注了，上传了一些只负责"打电话回家"（记录谁访问了）的无害包，然后坐等。

结果相当惊人：包发布不到一小时，就有一家财富500强公司中招了。接下来几天陆陆续续，又有"几十个"组织踩了坑。

当然，这是实验环境，包是无害的，也没有真的影响到生产系统。但这件事说明白了——这种攻击路径是真实可行的，攻击面是真实存在的。

为什么AI助手让这事变得更糟

关键在于，传统的安全思维有个前提：做决定的是人。

给你一份写得不太对的说明书，你可能会照着做，但人也经常会说"这好像不对吧"、会问问题、会发现明显不对劲的地方。

但 AI 助手不一样。它把文档当成"可以直接执行的真理"。你的 llms.txt 写着"运行 npm install legacy-widget"，它就直接执行——不会去问这个包现在还在不在、是谁的、是不是对的。

研究人员测试了好几个主流 AI 助手——Claude、OpenAI Codex、Hermes，全都有这个问题。这不是某家厂商的问题，而是系统性的：不维护的文档 + 有执行权限的AI助手 + 可以被抢注的废弃包名，三个凑一块，就成了。

怎么防？

研究人员的建议挺实在的：

1. 定期检查你的 llms.txt 文件

如果你给 AI 发布可读的文档，那文档里的包引用就得跟代码依赖一样对待。确认每个提到的包、域名、命令，指向的都是真实有效的资源。文档里一个小 typo，可能就变成别人能抢注的"基础设施"。

2. 给助手加审批流程

别让 AI 助手自动执行 shell 命令或者安装依赖。加上需要人工确认的步骤。文档是参考资料，不是操作手册。

3. 盯着包注册表里有没有山寨货

可以考虑对跟你内部依赖相似的包名设置告警。早点发现，就能早点自己抢注。

说在最后

这件事提醒我们一件事：AI 辅助开发来了，但我们的习惯还没跟上。

以前开发者自己干活，文档就是个参考。现在 AI 助手跟你一起干活，文档变成了一个 API。而 API 嘛，就得做校验、做版本管理、做安全审查。

好消息是，这不是什么无解的问题。不像很多安全漏洞，这儿的修复方案很简单——文档写清楚，信任打个折，验证多来点。难的是养成习惯：把 AI 能读的文档，当成生产级代码一样认真对待。

往后 AI 编程助手越普及，这类研究只会越来越多。攻击者不一定要直接打你的模型、偷你的数据。有时候，他们就安安静静地躺在你的文档里，等一个 typo 上钩。