The Documentation Was Genuine. The Package It Authorized Belonged to Someone Else.

On 26 August 2026, security researcher Alon Hertz published an account titled Data Became Code, describing a piece of infrastructure almost every large company now maintains without thinking of it as infrastructure at all: the llms.txt file. Modeled loosely on robots.txt, an llms.txt or llms.full.txt page is a plain text guidance document a company publishes at its own domain, written for AI agents rather than search crawlers, typically summarizing its product, pointing at its real documentation and naming the packages and commands a developer, or an agent working on a developer's behalf, should use to get started.

Hertz's team scanned 6,214 live domains drawn from a larger corpus of roughly 15,000 companies, weighted toward Fortune 500 firms, defense contractors and large technology vendors, and resolved 8,565 llms.txt and llms.full.txt files across them. Reading those files at scale, the team found more than 237 artifacts the documentation told an agent to install or connect to, packages named on PyPI, npm, RubyGems, NuGet, crates.io and Packagist, plus domains and subdomains, that nobody currently controlled. Some were expired .dev and .io domain registrations. Some were abandoned Render, Vercel, Fly and Netlify subdomains, free for anyone to claim. Most were simply package names a real product's real documentation told an agent to run, that had never been registered under that name by the vendor or by anyone else.

A four minute callback, and a second within the hour

To test whether the gap was theoretical, Hertz's team registered a small subset of the unclaimed names it had found and published packages containing nothing beyond an inert callback: a signal home on install, with no destructive payload and no further action. Hertz states the team then tested how little a prompt needed to say. Five frontier model configurations and two agentic coding CLIs each ran the identical instruction one hundred times: build and run a small project using a named vendor's own SDK, following that vendor's own documentation. The prompt named only the vendor. It did not link to the vendor's documentation, did not mention llms.txt and did not name a package. Locating the vendor's own docs and following the install instruction inside them is, after all, exactly what a coding agent is built to do on its own.

The first callback from a Fortune 500 network's own infrastructure arrived in under four minutes. A second, distinct Fortune 500 callback followed within the hour. Additional callbacks, from further enterprises and smaller companies, followed afterward. Hertz is quoted describing the underlying assumption plainly: agents treat vendor documentation as ground truth and do not question it, and neither, in practice, do the humans supervising them.

What the callback's own parent process chain showed

Each inert package Hertz's team hosted recorded the chain of parent processes that had spawned its own install, evidence of what actually launched the command rather than a claim about it. Ars Technica's own independent account of this research, corroborated here across multiple independently phrased searches rather than read directly since arstechnica.com was not reachable from this session, reports that those parent process chains traced the installs to coding agent sessions built on Anthropic's Claude, OpenAI's Codex and Nous Research's Hermes. This record treats that attribution as evidence that sessions built on those three products were among the agents whose own autonomous documentation discovery and install behavior produced a confirmed execution, not as a claim that every configuration, every version or the default behavior of any one of the three autonomously installs an undocumented dependency. Hertz's own account states the method used five frontier configurations and two agentic CLIs in total; this record could not establish from material available to it the complete list beyond the three products Ars Technica's reporting names.

Two counts, kept separate rather than reconciled

Hertz's own account and Ars Technica's independent reporting state different totals for the same underlying scan, and this record preserves both rather than picking one or averaging them into a single figure a reader could mistake for agreed fact. Both accounts agree on the domain count: 6,214 live domains. From there they diverge. Hertz's own account states 8,565 llms.txt and llms.full.txt files resolved and more than 237 unclaimed artifacts referenced as install or setup destinations. Ars Technica's independent reporting, corroborated here through search rather than a direct read of arstechnica.com, states 8,265 files resolved, 120 distinct sites among them carrying at least one unclaimed reference, and 227 install commands or unclaimed references in total.

This record could not establish, from material available to it, which of several plausible explanations accounts for the gap: a later filtering pass that removed some files or artifacts between Hertz's own count and what Ars Technica was shown, a distinction between counting files and counting the install commands or references extracted from them, an updated dataset revision, or a simple reporting correction in one account or the other. What can be stated is that the two figures are not interchangeable and that this record does not treat either as the corrected version of the other. The discrepancy does not weaken the finding it sits next to: two independent accounts of the same scan agree that thousands of live domains carried agent facing documentation, and agree, at counts differing only in scale, that a three figure number of install destinations inside that documentation pointed at names nobody currently controlled.

A separate, real occurrence: Clerk's own documentation, and a package Clerk never published

Everything above describes a controlled research corpus: names Hertz's team claimed itself, filled with inert callbacks it built. Distinct from that corpus, and evidenced independently of it, Hertz's research separately identifies a live instance of the same mechanism already sitting in production documentation. Clerk, an authentication vendor, publishes its own llms.txt and llms.full.txt files, confirmed by this record at clerk.com/llms.txt and clerk.com/docs/llms-full.txt. Reporting on Hertz's findings, corroborated here through search rather than a direct fetch of the underlying pages, states that Clerk's documentation instructed an agent to run a command, clerk-next-fix-auth-protection, by name. That exact command exists as a binary Clerk ships scoped inside its own eslint-plugin package. Run through npx without that scoped package already installed, the bare, unscoped name is what npm actually resolves, and Clerk had never published a standalone package under that name. A third party had. The package that name resolved to, cataloged as MAL-2026-11069 under CWE-506 for embedded malicious code by an automated malicious package record this record could not fetch directly at osv.dev but corroborates through search as consistent with OpenSSF Package Analysis and Amazon Inspector derived tooling, carried an install hook that transmitted the installing machine's username, hostname, working directory and a timestamp to an external server. Reporting states the malicious package's own versions were numbered 7.7.7 and 8.8.8, conspicuously high for a name with no legitimate prior release history. Reporting further states Clerk's security team was notified, responded quickly, corrected the documentation and stated plainly that the package had been registered by a third party outside Clerk's own control, abusing the same npx confusion Hertz's broader research names as a pattern. Whether the malicious package remains live, removed or quarantined on the npm registry at the time of this record's own publication, and how many installations it received before or after Clerk's correction, are not established by material available to this session and are recorded here as unknown rather than assumed.

Why this is not dependency confusion with a new name, and not a claim that llms.txt itself is unsafe

It would be a mistake to read this as one more instance of dependency confusion, the pattern where an internal package name collides with a public registry name an attacker claims first. That pattern turns on a private name becoming publicly resolvable. Nothing here is private. Every name in Hertz's corpus and in Clerk's own documentation was a name a vendor's genuinely published, genuinely public documentation told an agent to install. The failure is not that a name leaked. It is that the documentation's own authority over the instruction, install this, was silently treated as authority over whatever currently answers to the name the instruction contains, and nothing independently checked whether those were the same thing.

It would be an equally serious mistake to read this as evidence that llms.txt itself is unsafe, or that any vendor publishing one has made an error. The mechanism this record describes does not depend on the llms.txt convention specifically. It depends on a documentation surface, of any kind, naming an external, independently owned resource, and on nothing in the path from that name to an executing agent independently confirming that the resource currently answering to the name is still controlled by the party the documentation implied. A vendor's ordinary web documentation, read by a human developer who copies and pastes an install command, carries the identical gap; llms.txt simply removes the human's own, often unreliable, habit of recognizing an unfamiliar package name before running it.

Hertz's own account is explicit on a further point this record preserves without softening: none of this required a compromised vendor website, a phishing message, or an instruction that was malicious, or even unusual, at the moment it was published. Every agent in the controlled corpus found a genuine vendor's genuine documentation on its own, using nothing more than the vendor's name, because finding a vendor's own docs and following them is precisely the behavior a coding agent is built to exhibit. The instruction did not need to be attacked. It only needed to outlive, unchanged, whichever the resource it named eventually became.

The Authority Provenance ledger

Task principal. The developer, or the organization on whose behalf the agent was run. In Hertz's own controlled methodology, a one sentence instruction naming only a vendor: build and run a project using that vendor's SDK, following that vendor's own documentation.

Instruction source. The vendor's own llms.txt or llms.full.txt file, or its ordinary documentation, discovered by the agent itself. No URL to that file was ever supplied in Hertz's own controlled prompt; the agent located it because locating a named vendor's own documentation is inside its ordinary operating behavior.

Instruction publisher. The vendor whose domain the documentation was published on. Genuine in every instance this record verifies: Hertz's own corpus and Clerk's own documentation alike.

Reference. The package name, domain or subdomain the documentation's install instruction named. clerk-next-fix-auth-protection in Clerk's own case; a package, domain or subdomain name in each of the more than 237 artifacts Hertz's broader corpus identifies as unclaimed.

Resolver. Whichever package registry or DNS system interprets the reference at install time: PyPI, npm, RubyGems, NuGet, crates.io, Packagist, or ordinary domain resolution, depending on the artifact.

Resolved principal. Whoever currently controls what the reference actually resolves to. In the unclaimed cases this record and Hertz's own research describe, nobody, until a researcher or an unrelated third party claims the name. In Clerk's own case, a third party wholly unaffiliated with Clerk.

Artifact identity. The specific package version that executes. An inert callback with nothing else inside it, in Hertz's own controlled demonstration. Versions 7.7.7 and 8.8.8 of a package carrying an exfiltrating install hook, in Clerk's own case.

Execution principal. The host user account running the agent's own install command, inside the network the agent was operating in, a Fortune 500 network's own infrastructure among the confirmed callbacks.

Effect. In Hertz's own controlled corpus, a confirmed, evidenced install and execution inside real corporate networks, deliberately limited to an inert phone home signal by the researchers' own design. In Clerk's own case, reported transmission of the installing machine's username, hostname, working directory and a timestamp to an external server.

Limit that failed. Nothing in the path from the documentation's own genuine authority to install a named resource to the agent's own execution of whatever that name currently resolves to independently confirmed that the resolved principal was the instruction publisher, or anyone the instruction publisher had authorized.

Approval. None specific to the resolved artifact's own identity. The task principal's own instruction authorized following the vendor's documentation in general terms; nothing approved, or could have approved, a specific package version or publisher identity nobody involved had yet resolved.

Challenge. None confirmed by evidence available to this record. Neither the controlled corpus nor Clerk's own reported case describes an install time check that verified the resolved package's own publisher identity against the documentation's own publisher before executing it.

Revocation. Not applicable to Hertz's own controlled corpus, which the researchers themselves built and disclosed. In Clerk's own case, reported as corrected: Clerk's security team updated its documentation after disclosure, and this record's own verified copy of clerk.com/llms.txt and clerk.com/docs/llms-full.txt reflects genuine, currently published guidance rather than the specific line reporting describes as corrected.

Recovery. Unknown for Clerk's own case beyond the documentation correction itself; whether the malicious package remains live, removed or quarantined on the npm registry, and how many installations it received, are not established by material available to this session. Not applicable to Hertz's own controlled corpus beyond the researchers' own disclosure.

What this adds to how Moona Intelligence reads a trusted instruction

This corpus already tracks, in several other records, the difference between a resource being reachable and a resource being authorized, and the difference between a claim of authority and verified authority. This record adds a third, related distinction rather than folding into either. Nobody in Hertz's own corpus, and nobody in Clerk's own reported case, claimed anything false. The vendor's documentation was not lying, and it was not compromised. What failed sits one step further along the same chain: the documentation's own genuine authority to instruct an install was treated as though it extended automatically to whichever principal currently controls the specific artifact the instruction happens to name, a fact the instruction's own publisher does not control and, once time passes, cannot guarantee. A name is not a durable identity. What currently answers to it can change without the instruction that named it ever being edited, republished or reviewed again.