A scan of corporate AI documentation found 227 commands that pointed to package names or domains nobody controlled. That is the figure developers should sit with: a stale setup line in an official-looking file can become executable infrastructure once a coding agent is allowed to browse documentation and run a shell. Researchers claimed a handful of those empty names, and a Fortune 500 system called their test server within an hour, according to Ars Technica's report.
The research covered 6,214 live domains associated with defense contractors, large technology companies and Fortune 500 businesses. Across 8,265 llms.txt and llms-full.txt files, 120 sites contained at least one reference to an unregistered package or domain. The 227 figure counts the resulting install commands and links, rather than 227 known compromises. The researchers did not disclose the affected companies, and Ars reported no evidence that every dangling reference was exploited.
This matters because llms.txt is moving into ordinary web tooling. Google's Lighthouse documentation describes it as an optional, emerging convention for giving language models and agents a machine-readable summary of a site. A file that was meant to reduce crawling and help an assistant find the right documentation can also preserve old commands in a format agents are encouraged to read.
The fault starts in documentation
A dangling package name has a simple failure mode. A company publishes pip install internal-tool or npm install vendor-helper, but the named project does not exist in the public registry. Anyone who notices the vacancy can register that name later. The instruction remains on the legitimate company's HTTPS site, while the code now comes from a different owner. Ars found that some bad references predated the current AI boom and appeared in older, human-written material before being copied into files for language models.
That chain resembles dependency confusion, although the discovery route is different. SLSA's threat model defines dependency confusion as a public package shadowing a name intended for an internal registry. Here, documentation itself supplies the unintended package name. In both cases, the package manager sees a syntactically valid request and resolves it from a registry; the missing ownership check happened before the download.
The distinction matters during an incident review. A generated answer that mentions a nonexistent library is misinformation. A documentation file that directs an agent with shell access to install that library creates an execution path. The reported callbacks came from agents associated with Anthropic's Claude, OpenAI's Codex and Nous Research's Hermes, identified through the parent-process chain recorded by the researchers' beacon. Ars said the three companies had not responded by publication time, so the result does not establish which product settings, approval modes or local policies were in use.
The test reached real corporate systems
The researchers registered several unclaimed names and published harmless packages that phoned home when executed. They received a callback from a Fortune 500 company within an hour, followed by a few dozen callbacks from large companies and startups. That proves code execution in the tested environments. It does not, by itself, show data theft, persistence or compromise by the research packages, all of which were designed as beacons, according to the account published by Ars.
One public example had already moved beyond a harmless proof. A file on Clerk's legitimate site included the command npx clerk-next-fix-auth-protection. The name was later registered and used for a malicious npm package. Clerk removed the bad instruction, Ars reported, while noting that users who had installed Clerk's legitimate ESLint plugin were not exposed through that particular path. Whether the confusion produced infections remains unknown.
The package record supplies firmer detail than the web scan alone. OSV entry MAL-2026-11069 lists versions 7.7.7 and 8.8.8 of clerk-next-fix-auth-protection as malicious. Its analysis says the package shipped no functional main file. Instead, preinstall and postinstall hooks sent the installer's username, hostname, working directory and a timestamp to an anonymous external endpoint over plain HTTP. OpenSSF Package Analysis also classified the package as malicious because it executed commands associated with harmful behavior.
npx makes that documentation line especially sensitive. The official npm documentation says the command can fetch a remote package into npm's cache, place its executable on PATH and run it. Current npm releases prompt before installing a missing package unless that prompt is suppressed with --yes or --no. An unattended agent, wrapper or policy that automatically confirms the request removes the pause a developer would normally see.
HTTPS authenticates the wrong thing
A valid certificate proves which site served a document. It says nothing about who controls every package name mentioned inside that document. The same gap applies to a vendor's old blog post, a copied README and a partner's integration guide. In the reported scan, the dangerous instruction could arrive from the company's own llms.txt file or through documentation an agent treated as a trusted dependency.
Conventional endpoint monitoring also receives an awkward signal. A coding tool deliberately launched by the company starts a standard package manager, which connects to npm or PyPI over an allowed route. Each step can look normal in isolation. The questionable decision is the selection of the package, and that choice occurred inside the agent's reading and planning loop before the process reached the endpoint. The researchers' process-chain evidence shows why a clean HTTPS origin and a familiar registry cannot substitute for package identity.
The broader design problem is excessive authority. OWASP's guidance on excessive agency traces damaging agent actions to excessive functionality, permissions or autonomy. Its recommendations include limiting available tools, replacing open-ended shell access with narrower functions, reducing downstream permissions and requiring a person to approve high-impact actions. Those controls apply even when the triggering text was an innocent mistake rather than a planted prompt injection.
A practical containment plan
Documentation owners can start by treating install lines as maintained code. Every package and domain referenced in llms.txt, llms-full.txt, READMEs and setup pages needs an owner, a registry location and a periodic existence check. The scan found 120 affected files among 8,265 examined, which is small enough to miss in ordinary content review and large enough to justify an automated test. A broken link checker that ignores package commands will leave half the problem untouched.
Agent operators have a separate job. Shell execution should happen in a disposable environment without production credentials, private SSH keys or broad network reach. An approval gate should display the exact package name, registry, version and command before the first install. That follows OWASP's advice to minimize permissions and require human approval for consequential actions; a prose instruction telling the model to be careful is weaker than removing the permission from the tool.
Package policy can reduce the remaining risk. Teams can allow only approved registry scopes, pin versions and verify that a package's source and build provenance match an expected project. SLSA recommends checking provenance against recorded expectations for dependency-confusion cases, so a public artifact that merely occupies the right name is rejected when its source identity differs. SLSA also notes that provenance does not fully solve lookalike-name typosquatting, leaving package-name review and registry monitoring necessary.
Logs should connect the decision to the process. Record which document the agent read, the command it proposed, who approved it, the package digest and the network destinations reached during installation. The researchers could attribute their callbacks to Claude, Codex and Hermes because their beacon captured the spawning process chain, according to Ars. An internal audit needs at least that much context to distinguish an engineer's intentional install from an agent following a stale page.
The immediate unknowns are material. Ars's report does not name the 120 affected sites, include a full reproducible dataset or show how many callbacks occurred under each agent's approval configuration. Vendor responses and evidence of any real infections beyond the OSV-listed Clerk package would change the risk estimate. Until those details arrive, the concrete test is narrower: audit the instructions agents read, and prevent a package name in a web document from becoming sufficient authorization to execute its code.