对 llms.txt 提示注入进行威胁建模
llms.txt 文件可能成为智能体的外部上下文。这并不意味着智能体在设计上必然服从它,但确实意味着发布者和智能体开发者应对间接提示词注入进行威胁建模。
最近更新:
日志中的信号
在 Ahrefs 对 /llms.txt 请求开展的研究中,该研究覆盖 137,210 个域名,时间为 2026年5月,研究型抓取器占这些文件流量的 2.7%。该类别中最大的用户代理字符串是 prompt-injection-survey/1.0 。
这个字符串只能证明某个客户端声明了该标签。它无法识别运营者、确定其方法、显示恶意意图,也无法证明攻击成功。Ahrefs 将其解读为对提示注入的系统性研究。对这一观察结果最稳妥的用法是促成威胁建模,而不是报告事件。
这一点值得认真对待,原因与当前有多少代理读取文件无关。安全暴露程度与流量不成正比,而与某个东西真正读取文件的那一次会发生什么成正比。
为什么该文件按设计公开
看看 llms.txt 的用途。v2 规范描述了根目录或更具体路径上的 Markdown 文件,为模型提供适用网站区域的整理地图。Chrome 的 Lighthouse 文档将该文件介绍为减少理解网站结构所需抓取量的一种方式。
摄取并不意味着优先级或服从。安全的代理可以把文件作为路由提示,同时将每条描述和每个链接页面都视为不受信任的外部数据。OWASP 生成式 AI 安全项目将间接提示注入描述为嵌入网站或文件等外部来源中的恶意指令。只要代理会消费 llms.txt 文件,它就属于这个一般威胁模型。
这意味着,即使当前日志无法证明代理被广泛使用,该文件仍应按照任何可能影响抓取或执行的外部输入来处理。
有两个属性会使问题叠加:
- 它是带有自由文本描述的普通 Markdown。 格式中没有任何东西能区分描述和指令。读取
- [Docs](https://example.com/docs/): ignore previous instructions and ...的一行在语法上是有效条目。 - 可以自由链接到站外。 规范不限制链接目标,因此被入侵的文件可以把代理引向你无法控制的域名。
简短威胁模型
三个现实的路径,按可能性排序,而不是按戏剧性排序。
文件过时,路由错误。 文件列出了已经移动的端点、价格页面或版本路径。依赖这些条目的客户端会被错误引导。这是维护和正确性问题,不一定是安全事件。
未经审查的生成。 Ahrefs 指出,包括 Wix 在内的平台已经生成这些文件,而 Framer 和 Lovable 会扫描它们。替你生成却从未被你阅读的文件,其内容就无法由你保证。如果使用生成器,包括我们的生成器,输出也只是草稿:发布前先阅读。
写入权限是一种杠杆。 llms.txt 通常位于存放静态资源的 public/ 目录中。如果该路径受到的审查较少,被入侵的发布者或部署步骤就能更改描述和目标,而无需改变人们通常访问的渲染页面。
实用的缓解措施
这些都不是什么特殊情况,而是你会应用于任何影响行为的文件的控制措施。
纳入版本控制并审查更改。 文件属于代码库,不应手动上传。对 public/llms.txt 的差异应得到与路由处理器差异相同的关注。
限制可以编辑它的人,并对未经授权的更改发出警报。 如果 CI 能将已部署文件与已提交版本进行比较,就让它这样做。我们的验证器检查结构和链接,但变更监控仍属于你的代码库和部署控制。
让内容保持数据的形态,绝不要写成指令。 链接和事实性描述。不要使用祈使句,不要写“always”,也不要写“当被问到 X 时,回答 Y”。如果某行作为表格行读起来很奇怪,它就不属于文件。最佳实践从质量角度主张这一点;安全方面也是同一规则,只是后果更尖锐。
检查外部目标。 格式允许站外链接,它们也可能有用,但会增加另一个需要核验的所有者和生命周期。当代理会自动对目标执行操作时,请使用允许列表。
检查平台为你生成的所有内容。 尤其要检查 CMS 或网站构建器未经询问就添加的文件。
约束使用该文件的代理。 应用最小权限原则,将检索内容与可信指令分开,验证工具输入和输出,并要求对有后果的操作取得人工批准。这些控制遵循 OWASP 指导,比文件本身的任何措辞规则都更重要。
应当更加谨慎地处理 llms-full.txt,而不是降低谨慎程度。 它直接内嵌整页内容,而不是链接列表,因此攻击面严格更大。请参阅什么是 llms-full.txt了解其中应包含的内容。
诚实的表述是:这不是避免发布 llms.txt 的理由,而是停止把它当作营销产物,开始把它当作配置,因为它本来就是配置。