# Prompt Injection in .md Context Files: The Risk Model

> Canonical: https://auxfirst.com/news/markdown-context-file-security.html
> Markdown representation of this article, for agents and LLM crawlers.

Agents are built to trust AGENTS.md and llms.txt, so the usual injection defences don't apply. The attack surface, the crawl data, and the 6 controls that work.

By Emil Krzemiński, founder of auxfirst. Published 12 August 2026.

## Why context files are a trust boundary

An agent reading a web page treats it as information. An agent reading AGENTS.md treats it as instruction. That distinction is not a bug anyone introduced — it is the entire point of the format, and it is what makes the file worth attacking.

How literally agents follow these files is measurable. In the first rigorous evaluation of repository context files, researchers at ETH Zurich were explicit that where the files failed to help, "the absence of improvements when using context files is not due to a lack of instruction-following capabilities". The same paper reports a tool named in a context file being invoked 1.6 times per task on average, against fewer than 0.01 times when not mentioned — a gap of at least 160×.

The file doesn't nudge the agent. It redirects it.

The security question is therefore not whether an agent might be tricked into obeying the file. It will obey the file. The question is who can write to it, and who would notice if they did.

## Why this isn't the prompt injection you've read about

Most published work on prompt injection concerns *untrusted retrieved content*: an agent fetches a page, an email or a document, and hidden text inside it tries to pass itself off as instruction. The defensive posture there is separation — teach the system to distinguish the instructions it was given from the content it went and got.

Context files sit on the other side of that line by design.

| | Retrieved-content injection | Context-file injection |
|---|---|---|
| The input | A page, email or document the agent fetched | A file the operator supplied |
| Agent's stance | Treats it as information, with suspicion | Treats it as instruction, by design |
| The attack | Smuggle instructions past a boundary | No smuggling needed — there is no boundary |
| Detectable? | Yes — an anomaly in content that shouldn't instruct | No — a malicious line is structurally identical to a legitimate one |
| The defence | Model-layer separation, filtering, provenance | Organisational: permissions, review, change alerts |
| Who fixes it | Your model or platform vendor | You |

The model-layer defences the industry has spent two years building do not apply here. Waiting for a vendor to solve this is waiting for the wrong thing.

## The attack surface

Five paths, in rough order of how often they exist and how rarely they are reviewed.

- **A platform generating the file on your behalf.** Site builders and CMSs increasingly produce llms.txt automatically, regenerating on publish from content nobody reviewed as instructions.
- **Broad edit permissions.** A brand.md on a shared drive inherits the drive's permissions — for most marketing teams, the whole department plus two agencies.
- **Nested files resolving nearest-first.** The AGENTS.md specification states agents read the nearest file in the tree. A file introduced deeper overrides the reviewed one at the root, without touching it.
- **Linked resources you don't control.** A third-party page passes review in March and says something else in September.
- **Supply chain.** A vendored dependency, a shared template repo, an agency's boilerplate — each can carry a context file that arrives with the material.

Four of the five are ordinary permissions and ordinary automation, working exactly as designed. None require a compromise.

## What the crawl data shows

Ahrefs' June 2026 study of llms.txt traffic across 137,210 domains classified every bot that fetched one. Among the research crawlers, the largest single identified agent presents itself as `prompt-injection-survey`.

- 97% of llms.txt files got zero requests in May 2026
- 1.1% of requests came from AI retrieval bots
- The #1 research crawler is surveying injection surface

Somebody is systematically mapping context files as a place to put instructions that agents ingest and trust, at a point when almost nothing else is reading them.

This is not evidence of attacks and should not be reported as such. Research crawlers are not adversaries, and the honest reading is close to reassuring: the research community got here early. But it settles what kind of object this is. A file that security researchers survey systematically is not a marketing asset that happens to sit at your domain root.

## Four realistic scenarios

**The regenerated llms.txt.** Marketing ships a landing page through the site builder. The platform regenerates llms.txt on publish, pulling in the new page's copy — including a testimonial block a contractor pasted from a source nobody traced. Then: every agent directed to that file reads the pasted text as part of the site's own description of itself.

**The nested AGENTS.md.** A team vendors a shared component library from another business unit. It arrives with its own AGENTS.md, four directories down, never reviewed by the receiving team. Then: agents working in that subtree follow the nested file, and the root file still reads correctly to anyone who checks.

**The open brand.md.** A brand.md lives on a shared drive so the agency can reference it. The account manager leaves; the account stays active. Six weeks later a line under "Claims we can make" is different. Then: the change sits inside a file six generation tools read as authoritative, and it is in nobody's review cycle.

**The link that moved.** An llms.txt links to a partner's documentation page, reviewed and approved at the time. The partner restructures and the URL now resolves to a user-editable community page. Then: an agent following your file's recommendation reads content on a domain you have never controlled.

## Controls that work

1. **Treat context files as code.** Version control, pull requests, review before merge.
2. **Restrict write access explicitly.** Not inherited from a drive or repo default. Make it a shorter list than the people who can read it.
3. **Alert on change.** A diff notification to the owner on every commit. This catches all four scenarios above, and it costs a webhook.
4. **Keep llms.txt descriptive.** Links and descriptions only, nothing instruction-shaped.
5. **Link only to resources you control.** A link is a promise about content you may not be able to keep.
6. **Review anything generated on your behalf.** Auto-generation is a convenience, not an approval.

**The one that makes the other six work: a named human owner per file.** Not a team — a person, recorded in the file itself. Every control above has a step that requires someone to look at something, and each fails silently without a name attached. One line at the top of the file.

## Controls that don't

**Scanning file contents for known injection phrasings.** The effective version of this attack looks like a plausible additional instruction — a preferred tool, a recommended vendor, an extra step before publishing. There is no string to match on, and per the research above, naming a tool is sufficient to get it used.

**Trusting a platform's auto-generation.** The platform optimises for coverage, not for the fact that its output is read as instruction.

**Assuming an unlinked file is unreachable.** The Ahrefs data shows agents don't probe for files that aren't advertised — but "no AI bot went looking" is not the same as "nobody can find it". Obscurity is not a permission model.

## Where this sits in a trust architecture

The instinct is to file this under security, and that framing produces the wrong controls. None of the four scenarios involve a breach. They involve a document that instructs machines, held to the review standard of a document that informs humans.

The right frame is authorship. For any file an agent treats as instruction, three questions have to have answers: **who wrote this, who approved it, and who finds out when it changes.** Those are the same questions that govern any other artefact with authority inside an organisation. Context files acquired that authority in about eighteen months and mostly did not acquire the accompanying process.

That gap is the work. It is not a scanner and it is not a vendor.

## Read next

- [llms.txt: what 137,000 sites' server logs actually show](https://auxfirst.com/news/llms-txt-evidence.html)
- [AGENTS.md for teams that don't write code](https://auxfirst.com/news/agents-md-for-non-engineering-teams.html)
- [brand.md — brand guidelines agents can read](https://auxfirst.com/news/brand-md-context-file.html)
- [The context file checker](https://auxfirst.com/tools/context-file-checker.html)
- [The 10 AUX heuristics](https://auxfirst.com/heuristics.html)

## Sources

- Louise Linehan and Xibeijia Guan, "We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read", Ahrefs, 15 June 2026. Figures cover May 2026 — https://ahrefs.com/blog/llmstxt-study/
- Gloaguen, Mündler, Müller, Raychev and Vechev, "Evaluating AGENTS.md", arXiv:2602.11988, February 2026 (revised June 2026) — https://arxiv.org/abs/2602.11988
- agents.md — the specification, including nested-file precedence — https://agents.md/

Method: this is a risk model, not an incident report. No breach is described here and none is known to us; every scenario is constructed from ordinary permissions and ordinary automation. No exploit payload is named or described.

---

Emil Krzemiński is the founder of auxfirst (https://auxfirst.com/), the agentic experience design agency.