Security researchers say an emerging form of AI-facing website documentation can become a software supply-chain trap: an autonomous coding agent may follow a stale package name or expired domain listed in a company’s llms.txt file, then install or run attacker-controlled code under its existing permissions.
The finding, reported first by Ars Technica, shifts attention from malicious prompts to a more ordinary failure of web maintenance. In the reported tests, researchers registered unclaimed names referenced in agent-readable documentation and hosted code that contacted a server they controlled when run. They subsequently received callbacks from corporate environments, including a Fortune 500 company. That is evidence of code execution in particular tested settings, not proof that the companies’ networks were broadly compromised.
The issue is not a flaw assigned to one model maker or package registry. It is a trust-boundary problem created when an agent is allowed to browse documentation, install dependencies or issue shell commands—and treats instructions published from an official vendor site as reliable operational guidance.
How a stale documentation link becomes executable
llms.txt and llms-full.txt are emerging conventions through which websites offer machine-readable summaries, documentation links and technical guidance to AI systems. They are not a universal, formally standardized part of the web. But a coding agent asked to use a vendor’s SDK may find such a file as it looks for installation instructions, then act on the package or domain reference it contains.
The reported attack chain has several steps. A vendor’s agent-facing file names a package, download location or supporting domain; the reference is abandoned, misspelled, moved or otherwise no longer controlled by its original owner; an attacker claims the available package name or domain; and an authorized agent retrieves and executes the resulting content. The crucial final step requires the agent to have permission to use a package manager or shell. A dead reference by itself cannot execute anything.
This resembles dependency confusion and typosquatting, familiar problems in npm, PyPI and other ecosystems. The difference is the lure. Rather than relying on a developer to mistype a package name or choose an untrusted dependency, the attacker’s reference is reportedly reached through documentation on a vendor’s own domain. For software agents built to turn documentation into working code, that provenance can carry considerable weight.
Tom’s Hardware reported that the team’s test involved Python and Node packages, and that a request to build and run a project with a vendor SDK could lead an agent to the bad reference without a user mentioning llms.txt or supplying a malicious link. That behavior is particularly relevant to agentic development tools, whose value proposition is to take multistep action rather than merely suggest code in a chat window.
What the reports establish—and what they do not
Ars Technica said the researchers scanned 6,214 live domains associated with defense contractors, Fortune 500 companies and major technology firms. It reported 8,265 llms.txt or llms-full.txt files and said 120 sites pointed to at least one unregistered name. The researchers registered selected names and used callback code to determine whether installations occurred; Ars reported an initial Fortune 500 callback within an hour, followed by dozens from companies and startups.
Later accounts add detail but do not fully align on the measurements. Tom’s Hardware and CyberPress put the file count at 8,565 and describe 237 or more problematic references, including nonexistent, mistyped and outdated entries. Those numbers may be counting different things: files are not sites, and a site can contain multiple package or domain references. The accounts do not explain the 300-file discrepancy, however, so neither total should be treated as a settled census.
Callback timing also differs. Tom’s Hardware described a callback after four minutes, while Ars Technica reported one within an hour. This could reflect separate runs, but the available reporting does not establish that. Tom’s Hardware further attributed to the researchers model-test results showing some frontier configurations running the test code at rates of 90% or more, with a Claude Opus 4.8 medium-effort configuration at about 30%. Without a public technical paper, underlying prompts, agent permissions, configuration details and raw results, those comparisons remain reported claims rather than independently reproducible benchmarks.
The same limitation applies to a claimed Clerk-related case described by CyberPress, involving an unscoped npm package and installer metadata collection. CyberPress reported that Clerk was notified and fixed the reference, but no vendor advisory or underlying researcher report is available in the published accounts cited here. The more firmly supported conclusion is narrower: researchers say their controlled callback code was executed by agents in some corporate environments after the agents encountered claimed references in official-looking AI guidance files.
Documentation is now part of the build perimeter
Security teams have long treated dependency manifests, CI pipelines and package registries as supply-chain assets. Agent-facing documentation deserves similar handling when coding systems can use it to decide what to download and run. OWASP’s guidance on LLM supply-chain risk already frames third-party models, data and components as dependencies that can introduce compromise or manipulation. This case extends that logic to the instruction layer that connects an agent to those components.
For organizations publishing llms.txt files, the practical audit is straightforward but potentially extensive: inventory every package identifier, URL and domain; verify ownership and availability across the relevant registries; remove obsolete instructions; and make documentation changes subject to the same review expected for build configuration. A redirect to a gone-away domain, or an old unscoped package name, is no longer merely broken documentation if an agent can operationalize it.
For organizations deploying coding agents, the stronger control is limiting action rather than assuming source-domain trust. Package installation and shell execution should run in constrained environments, use allowlists or lockfiles where possible, and require review for novel dependencies. The research suggests that the question is not only whether an agent can recognize a malicious webpage. It is whether the organization has granted it enough authority to turn stale public text into a build instruction.
