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

The finding announced August 26, 2026

Researchers at a stealth startup in Israel scanned 6,214 live domains belonging to defense contractors, Fortune 500 companies, and Big Tech firms. Of the 8,265 llms.txt and llms-full.txt files they found, 120 of them, each on a different site, pointed to one or more code packages or domain names that were not registered. The files contained 227 commands to install non-existent packages or view unclaimed domains across registries including PyPI, npm, RubyGems, NuGet, crates.io, and Packagist.

The llms.txt convention is an emerging standard 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 processes an llms.txt file, it treats the installation instructions as authoritative and executes them 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. Process logs revealed 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. 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 researcher Alon Hertz 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

• •
  Audit llms.txt files: Organizations hosting llms.txt or llms-full.txt files should verify that every referenced package name is registered to the expected owner and every domain is active and controlled.
• •
  Restrict agent shell permissions: AI coding agents should not have unrestricted shell execution permissions. Require human approval before installing any package referenced in external documentation.
• •
  Implement package allowlists: Use package installation policies that restrict agents to a vetted allowlist of registries and package names.
• •
  Monitor outbound connections: Watch for unexpected outbound connections from agent environments, particularly to package registries outside of normal development workflows.
• •
  Treat documentation as untrusted input: The same integrity controls applied to code dependencies should extend to documentation files that agents consume as instructions.