In August 2026, researchers showed that a documentation file meant for AI agents is enough to get unowned code running inside corporate networks. No phishing. No poisoned GitHub Action. The agent read a vendor's own llms.txt, treated it as setup instructions, and installed whatever package name was sitting there.
That is a supply-chain failure. It is also a prompt-injection failure wearing a different shirt.
What they found
An Israeli research team scanned 6,214 live domains at defence contractors, Fortune 500 companies, and big tech. They found 8,265 llms.txt and llms-full.txt files. One hundred and twenty of those files, each on a different site, pointed at a code package or a domain name that was not registered.
They registered a handful of the empty names, put a beacon behind them, and waited. A Fortune 500 company called home within an hour. Dozens more callbacks followed, from other Fortune 500 firms and from startups. Parent-process chains showed the installers: Anthropic's Claude, OpenAI's Codex, and Nous Research's Hermes.
Dan Goodin reported the work for Ars Technica. The researchers' own write-up is the source for the counts and the process trees. Anthropic, OpenAI, and Nous Research had not commented by the time Ars published.
Why the agent did it
llms.txt is supposed to be the AI equivalent of robots.txt: a machine-readable map of a site. Agents are trained to trust it. It arrives over HTTPS, on the vendor's domain, in a format built for them. When the file says to install a package, the agent has no second channel that says check the registry namespace first.
Alon Hertz, one of the researchers, put it plainly: agents treat vendor docs as ground truth, and the humans supervising them usually do too.
The 120 files held 227 install-or-visit commands aimed at names that did not exist. Some of those entries predate the AI boom and were written by people. Others look like they were generated by models that hallucinated a package name and nobody checked whether it was real.
This is already being used
The researchers found a live llms.txt on clerk.com that told agents to run an installer one-liner. Unlike a normal package install, that path can fetch a package into the cache and execute it without adding it to the project manifest. Someone had claimed the empty name and was hosting malware.
Clerk has since cleaned it up. They also noted that environments which already had a legitimate Clerk ESLint package in place were not in the same position. It is still unclear whether the malicious name produced real infections. It is clear that the window existed, on a real vendor domain, with a command that looked like something the vendor would ship.
That is the point. The file was authentic. The domain was authentic. The missing control was whether this registry name actually belonged to the vendor.
What to do this week
Audit your own llms.txt and llms-full.txt. If they mention a package, a GitHub repo, or a domain, confirm you still own it. Claim empty names that look like yours, or delete the line.
Do not let coding agents run install commands from third-party documentation without a human in the loop. Vendor docs, SDK references, and partner setup guides are untrusted input once an agent can execute them.
Treat llms.txt the way you treat a Dockerfile copied from the internet. HTTPS on a pretty domain is not an integrity guarantee.
If you already hunt supply-chain issues in CI, add the agent path: which tools can shell out, which docs they fetch, and whether those docs still point at names you control.
How this sits next to prompt injection
Prompt injection is someone planting an instruction in content the model will read. Here the instruction can be old, boring, and written in good faith. The danger shows up later, when the package name expires and someone else takes it.
The boundary that used to exist between documentation and code does not survive an agent that can run a shell. Everything it reads is input. Every input can become an action. The integrity controls we put on the packages we pin in lockfiles were never applied to the docs we let agents browse.
That is the surface. It is not theoretical. Fortune 500 networks already executed the research beacons. At least one vendor file pointed at live malware. If your agents can install from the open web, this is in scope.
The abandoned-name problem is not new. We covered it on the LiteLLM PyPI compromise and the TeamPCP campaign. What is new is that the installer is an agent with a shell, not a developer pasting a README.
Takeaways
- llms.txt is treated as setup instructions. If it names a package or domain nobody owns, an agent with a shell will follow it.
- Claude, Codex, and Hermes already did this inside real networks. One vendor file pointed at live malware.
- Audit your own llms.txt, claim or delete empty names, and keep a human in the loop before agents run installs from third-party docs.
