A stealth-stage security startup in Israel spent part of this month scanning 6,214 live domains. It was hunting through a file type that almost no security team audits. What it surfaced is a supply chain exposure that sits entirely outside the reach of conventional endpoint tooling.
The target was a pair of emerging conventions: llms.txt and llms-full.txt. Think of them as the AI-era counterpart to robots.txt. Sites publish them so machines can read a clean summary of the content and structure. Coding agents treat them as setup documentation.
The scan surfaced 8,265 of these files across the domain set. Of those, 120 files, each on a separate site, referenced package names or domains that had never been registered. Between them, those files carried 227 install commands pointing at things nobody owned. Any attacker could have claimed them.
The proof of concept phoned home in under an hour
The team registered a handful of the unclaimed names to see what would happen. They hosted harmless packages that called back to a server on execution. The first beacon landed within the hour. It came from a Fortune 500 company.
Several dozen more arrived over the following period. Some came from startups. Others came from additional Fortune 500 firms, and the original domain set had included defense contractors and Big Tech properties.
The beacon logged the parent process chain behind every install. That detail is what turns the finding from theory into evidence. It named the software doing the work: Anthropic's Claude, OpenAI's Codex, and Nous Research's Hermes. Ars Technica, which first reported the research, said none of the three companies replied to a request for comment before publication.
One of the cases was already weaponized
Not every finding was a controlled test. On the legitimate domain clerk.com, the researchers found an LLM file containing the command npx clerk-next-fix-auth-protection.
The choice of npx matters here. Unlike a standard install, npx can pull a package into the npm cache and run its exposed binary without ever writing it into the project manifest. There is no dependency record left behind to review later.
Someone had already claimed the empty slot and filled it with live malware. Clerk has since fixed the file. The company noted that agents which had already installed a binary from its official eslint plugin package were not exposed. Whether any machines were actually infected remains unclear.
Why the security stack never fired
The most uncomfortable part of the research is not the malware. It is that every trust signal pointed the right way.
An agent encountering one of these files sees HTTPS, an official corporate domain, a standardized format built for AI consumption, and a publisher the organization already works with. Nothing in that chain looks wrong. The file is meant to be authoritative, so the agent does not stop to verify whether the referenced package actually exists in the registry.
Detection tooling fares no better. To an EDR agent or a corporate proxy, the activity resembles a developer pulling a package from a registry the company already allows, with a sanctioned coding assistant as the parent process. There is no anomaly to flag because the failure happens upstream of anything the endpoint can see.
Alon Hertz, one of the researchers, argued in an interview that the underlying trust model is broken, because agents accept vendor documentation as ground truth and their human supervisors rarely question it either.
He also drew a distinction worth holding onto. A prompt injection requires someone to plant a hostile instruction deliberately. Here the instruction can be entirely benign when written, published in good faith by a real company. The danger appears later, once the package or domain it references is abandoned and a stranger picks up the name.
The origin of the faulty entries is still murky. Some predate the current wave of AI tooling and appear to have been typed by humans into older documentation. Others may have been generated by models that hallucinated a package name, or that copied bad instructions without being able to tell good from bad.
For engineering leaders, the practical takeaway is narrow but urgent. Any document an agent is permitted to read, and any command it is permitted to run, now belongs in the threat model. Vendor documentation has quietly become an execution surface, and it carries none of the integrity guarantees that real code does.
