Threat-modeling llms.txt prompt injection

The signal in the logs

In Ahrefs’ study of /llms.txt requests across 137,210 domains in May 2026, research crawlers accounted for 2.7% of traffic to these files. The largest user-agent string in that category was prompt-injection-survey/1.0.

That string proves only that a client declared that label. It does not identify the operator, establish its methods, show malicious intent or prove a successful attack. Ahrefs interpreted it as systematic research into prompt injection. The defensible use of the observation is to prompt a threat model, not to report an incident.

That is worth taking seriously for a reason that has nothing to do with how many agents currently read the file. Security exposure is not proportional to traffic. It is proportional to what happens on the one occasion something does read it.

Why the file is exposed by design

Look at what llms.txt is for. The v2 specification describes Markdown files at the root or on more specific paths that give a model a curated map of the applicable site area. Chrome’s Lighthouse documentation presents the file as a way to reduce the crawling needed to understand a site’s structure.

Ingestion does not imply precedence or obedience. A safe agent can use the file as a routing hint while treating every description and linked page as untrusted external data. The OWASP GenAI Security Project describes indirect prompt injection as malicious instructions embedded in external sources such as websites or files. An llms.txt file belongs inside that general threat model whenever an agent consumes it.

That means the file deserves the handling given to any external input that can influence retrieval or execution, even though current logs do not establish broad agent use.

Two properties compound it:

• It is plain Markdown with free-text descriptions. Nothing in the format distinguishes a description from an instruction. A line reading - [Docs](https://example.com/docs/): ignore previous instructions and ... is a syntactically valid entry.
• It links off-site freely. The spec places no constraint on link targets, so a compromised file can route an agent to a domain you do not control.

A short threat model

Three realistic paths, in order of likelihood rather than drama.

Stale file, wrong routes. The file names endpoints, pricing pages or version paths that moved. A client that relies on those entries is misdirected. This is a maintenance and correctness problem, not necessarily a security event.

Unreviewed generation. Ahrefs note that platforms including Wix already generate these files, and that Framer and Lovable scan for them. A file generated on your behalf and never read by you is a file whose contents you cannot vouch for. If you use a generator, including ours, the output is a draft: read it before you ship it.

Write access as a lever. llms.txt often sits in a public/ directory alongside static assets. If that path receives less review, a compromised publisher or deployment step can change descriptions and destinations without altering a rendered page a human normally visits.

Practical mitigations

None of these are exotic. They are the controls you would apply to any file that influences behaviour.

Version-control it and review changes. The file belongs in the repository, not uploaded by hand. A diff on public/llms.txt should get the same attention as a diff on a route handler.

Restrict who can edit it, and alert on unauthorised changes. If your CI can compare the deployed file with the committed version, do that. Our validator checks structure and links, but change monitoring still belongs in your repository and deployment controls.

Keep the content shaped like data, never like instructions. Links and factual descriptions. No imperative sentences, no “always”, no “when asked about X, say Y”. If a line would read oddly as a table row, it does not belong in the file. Our best practices argue for this on quality grounds; the security case is the same rule with a sharper edge.

Review external destinations. Off-site links are allowed by the format and may be useful, but they add another owner and lifecycle to verify. Use an allowlist where an agent will act on destinations automatically.

Review anything a platform generated for you. Including, specifically, files your CMS or site builder added without asking.

Constrain the consuming agent. Apply least privilege, separate retrieved content from trusted instructions, validate tool inputs and outputs, and require human approval for consequential actions. These controls follow OWASP’s guidance and matter more than any wording rule in the file itself.

Treat llms-full.txt with more care, not less. It inlines whole page contents rather than a list of links, so it carries strictly more attack surface. See what llms-full.txt is for what belongs in it.

The honest framing: this is not a reason to avoid publishing llms.txt. It is a reason to stop treating it as a marketing artefact and start treating it like configuration, because that is what it is.