Discovery File Poisoning: how public metadata becomes agent policy

Discovery file poisoning is an indirect prompt-injection pattern carried by boring-looking metadata. The attacker places policy-shaped language inside files such as robots.txt, llms.txt, llms-full.txt, sitemap.xml, humans.txt, security.txt, /.well-known/ resources, web app manifests, or RSS/Atom feeds. These files may be valid, useful, and expected to exist; the dangerous move is when text inside them asks the agent to suppress findings, trust a callback, treat a route as canonical, forward credentials, change scanner behavior, or accept metadata as authority.

Agents read discovery files early because they need to decide what a site is, where the docs live, which routes matter, and what metadata should shape retrieval. That first-read position makes the files feel upstream of the workflow: a clean robots.txt can point to a sitemap, a sitemap can point to docs, an llms.txt can point to a larger bundle, and a security or .well-known file can look closer to ownership or disclosure policy. The risk is not that discovery files exist; the risk is that agents collapse discovery, retrieval, and authority into one context block and let public metadata override local policy.

In practice, discovery file poisoning shows up as comments, custom directives, sitemap annotations, linked sidecars, documentation bundles, ownership hints, security disclosure text, manifest extension fields, or feed entries that sound like instructions to an AI system. A robots.txt may tell AI scanners not to report private routes. An llms.txt or llms-full.txt may bury agent-facing policy in documentation text. A sitemap.xml may route the agent toward a poisoned policy page. humans.txt, security.txt, /.well-known/ resources, web app manifests, and RSS/Atom feeds may smuggle fake verification, escalation, severity, update, or disclosure guidance into workflows that were only supposed to collect metadata.