llms.txt Supply Chain Attack: AI Coding Agents Install Unowned Packages Inside Corporate Networks

The finding published August 27, 2026

Researchers at a stealth startup in Israel, including Alon Hertz, published the findings on Medium, and Ars Technica reported them on August 27, 2026. The researchers scanned 6,214 live domains belonging to defense contractors, Fortune 500 companies, and Big Tech firms and resolved 8,565 llms.txt files. According to Ars Technica, 120 of the files, each on a different site, pointed to one or more code packages or domain names that were not registered, and those files contained 227 commands to install non-existent packages or view unclaimed domains on PyPI, npm, and other registries. The researchers' own post counts more than 237 unclaimed artifacts, spanning PyPI, npm, RubyGems, NuGet, crates.io, and Packagist, plus expired domains and abandoned hosting subdomains.

The llms.txt convention is an emerging convention for providing machine-readable summaries of website content. It functions as the AI equivalent of robots.txt, designed to help AI agents navigate and understand a site's documentation. When an AI coding agent with permission to run shell commands treats an llms.txt file as authoritative setup documentation, some agents download and run the referenced packages without independent verification.

How the attack works

The attack chain is straightforward. A misconfigured llms.txt or llms-full.txt file contains installation instructions referencing a package name that is not registered on the relevant registry. For example, one file contained the prompt "pip install [redacted]" and another contained "npm install [redacted]." Because the package name is unregistered, any attacker can claim it on the registry and push arbitrary code.

When an AI coding agent with shell execution permissions processes the file, it treats the instruction as ground truth and runs the install command without checking whether the package actually belongs to the company. The agent does not verify the namespace on PyPI. It does not notice that a documentation link points to a domain that expired months prior. It executes the command.

To test the exploit, the researchers registered a handful of the unclaimed package names and hosted beacon code that called back to their server. A Fortune 500 company responded within an hour. Over time, a few dozen more callbacks followed, from additional Fortune 500 companies and startups. The beacon recorded the chain of parent processes that spawned each install, identifying Claude, OpenAI's Codex, and Nous Research's Hermes as the coding agents involved.

The clerk.com case: active malware already in the wild

At least one active attack was already exploiting this vector before the researchers published. The researchers found an llms.txt file hosted on the legitimate website clerk.com that contained the command npx clerk-next-fix-auth-protection. Unlike a conventional installation command, npx can fetch a package into npm's cache and execute its exposed binary without adding it to the project's dependency manifest.

Someone had already claimed the once-empty package slot and used it to host live malware. The package is catalogued as MAL-2026-11069 in the OSV database, which records install hooks that send the installer's username, hostname, working directory, and timestamp to an external server. Clerk has since resolved the problem. The company noted that if an agent had already installed a binary included in the package @clerk/eslint-plugin, there was no threat. Otherwise, the malicious package would be installed. It is unclear whether the confusion resulted in actual infections.

Why existing defenses miss this

The researchers described why endpoint detection and network proxies fail to catch this attack pattern. To any EDR or proxy, the activity looks like a developer running a legitimate package manager: pip install from pypi.org, a domain every corporate proxy already allows, with the coding agent the company installed on purpose as the parent process. No anomaly. No alert.

The failure happens upstream, in the gap between the instruction and the execution. The agent sees a file served over HTTPS, on the company's official domain, in a standardized format designed for AI consumption, published by the company itself or a partner it trusts. The agent has no reason to question any of it. Every layer of trust is intact except the one nobody thought to check: whether the package name in the registry actually belongs to the company that wrote the documentation.

The trust chain is transitive. An llms.txt file does not have to sit on the Fortune 500's own website. Agents pull context from trusted third parties: a partner's docs, a vendor's SDK reference, a community project's setup guide. If the agent trusts that third party, and that third party's file points to an unclaimed package, the chain works the same way.

Root cause: the data and code boundary

The root cause is the same as prompt injection. LLMs cannot draw a reliable boundary between authentic user instructions entered directly into a prompt and content they find on untrusted third-party sources. In a prompt injection, someone deliberately plants malicious instructions. In the llms.txt case, the instruction itself can be completely benign and come from a legitimate source with no malicious actor involved at the time it was written. The danger comes later, when the package or domain it points to is abandoned and someone else claims it.

As the researchers described it: "An agent doesn't distinguish between a page and a command. Everything it reads is input, and every input is a potential instruction. Which means the entire corpus of published data that agents are now wired to consume has silently become an execution surface, and almost none of it carries the integrity guarantees we apply to actual code."

Defensive recommendations

A Cloud Security Alliance research note on the disclosure, published September 7, 2026, recommends the following:

• •
  Audit llms.txt files: Publishers of llms.txt or llms-full.txt files should check every install command, package reference, and domain name against the corresponding public registry or DNS record, and defensively register any referenced package that is not held under the organization's own namespace.
• •
  Require human confirmation for installs: AI coding agents with shell or package-manager privileges should not run install commands sourced from external documentation without a human confirmation step.
• •
  Check registry metadata before installation: Packages an agent proposes to install should be checked against registration date, publisher identity, and download history. Software composition analysis can flag recently registered packages with no prior download history.
• •
  Commit and verify lockfiles: Lockfiles committed to source control and verified against known-good hashes prevent a substituted package from silently replacing an expected dependency.
• •
  Treat agent-facing text as supply chain input: Any text an agent may convert into an executed command, including llms.txt files, README files, and MCP tool descriptions, needs the review, provenance, and change control already applied to code and dependencies.