Prompt injection in .md context files
Every other input an agent receives is treated with some suspicion. Context files are the one category it is built to trust and follow. That asymmetry is the whole problem.
Every other input an agent receives is treated with some suspicion. Context files are the one category it is built to trust and follow. That asymmetry is the whole problem — and it means the defences the industry has spent two years building do not apply here at all.
The structural point
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 now measurable rather than assumed. 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 agents read the file and did what it said. The same paper reports that a tool named in a context file was invoked 1.6 times per task on average, against fewer than 0.01 times when it was not mentioned — a gap of at least 160×.
Which means the security question is 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.
The distinction that changes the answer
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 web page, an email or a document, and hidden text inside it tries to pass itself off as instruction. The whole 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. Nobody has to smuggle instructions past a boundary, because the file is the instructions.
The defences for one do nothing for the other
| 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 |
So the model-layer defences the industry has spent two years building do not apply here. The controls are organisational: permissions, review, and knowing who changed what. That is unglamorous, and it is the entire answer.
The surface
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.txtautomatically. It regenerates on publish, from content nobody reviewed as instructions. - Broad edit permissions. A
brand.mdon a shared drive typically inherits the drive's permissions, which for most marketing teams means the whole department plus two agencies. - Nested files resolving nearest-first. The AGENTS.md specification states that agents read the nearest file in the directory tree, so the closest one takes precedence. A file introduced deeper in the tree overrides the reviewed one at the root, without touching it.
- Linked resources you don't control. A third-party page linked from your context file passes review in March and says something else in September. Nothing on your side changes, and nothing on your side notices.
- Supply chain. A vendored dependency, a shared template repo, an agency's boilerplate — each can carry a context file that arrives with the material.
Note what almost none of these require: a compromise. Four of the five are ordinary permissions and ordinary automation, working exactly as designed.
The evidence
What the crawl data shows
There is one empirical signal worth reporting, and it comes from an unlikely place. 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.
The intended readers haven't arrived. The researchers have.
Read those together. 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 security research community got here early, which is the best available outcome for a new file format. 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.
How it actually goes wrong
Four realistic scenarios
None of these require an attacker with unusual access. Each has an ordinary organisational cause.
The regenerated llms.txt
Marketing ships a new landing page through the site builder. The platform regenerates llms.txt on publish, pulling in the new page's copy — including a testimonial block that 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, written for a different toolchain and never reviewed by the receiving team.
Then: agents working in that subtree follow the nested file, not the root one — 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 agency's 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 that 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 their site 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 had any control over.
What to do
Controls that work
- Treat context files as code.Version control, pull requests, review before merge. If a file instructs an agent, it belongs under the same discipline as anything else that instructs a machine.
- Restrict write access explicitly.Not inherited from a drive or a repo default. Name who can change the file, and make that a shorter list than the people who can read it.
- Alert on change.A diff notification to the owner on every commit. This is the control that catches all four scenarios above, and it costs a webhook.
- Keep llms.txt descriptive.Links and descriptions only, nothing instruction-shaped. The moment the file tells its reader what to do, it has become a channel rather than a map.
- Link only to resources you control.Same-origin where possible, a domain you own otherwise. A link is a promise about content you may not be able to keep.
- Review anything generated on your behalf.If a platform produces the file, someone reads what it produced. Auto-generation is a convenience, not an approval.
A named human owner per file. Not a team, not a function — a person, recorded in the file itself. Every control above has a step that requires someone to look at something, and each one fails silently without a name attached. This is the control most often missing and the cheapest to add: one line at the top of the file.
You can check the first four mechanically. Our context file checker flags instruction-shaped content in llms.txt, third-party links, and missing boundaries in AGENTS.md — in the browser, with nothing uploaded, which matters for exactly this category of file.
Controls that don't
Scanning file contents for known injection phrasings. The effective version of this attack does not look like an attack. It looks like a plausible additional instruction — a preferred tool, a recommended vendor, an extra step before publishing. There is no string to match on, because the payload is indistinguishable in form from the legitimate content. And per the research above, naming a tool is sufficient to get it used.
Trusting a platform's auto-generation. The platform is optimising for coverage, not for the fact that its output is read as instruction. It has no view on which of your pages should be authoritative.
Assuming an unlinked file is unreachable. Convenient, and half-true. 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.
The frame
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 above 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 — a policy, a price list, a set of approved claims. 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. It is deciding which files carry authority, writing an owner into each one, and putting the change of an instruction file on the same footing as the change of a policy. More on how we think about that in the AUX heuristics, and on what an agent can actually do once it reaches your systems in the Agent Operability Audit.
Read next & further reading
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. The instruction-following figures are quoted from the paper's own text rather than from secondary coverage, and the prompt-injection-survey finding is a research crawler — reported as such, deliberately, because overstating it would undercut the argument. No exploit payload is named or described.