AI coding agents are following installation instructions in corporate documentation files and, in some cases, pulling in software packages that the companies never registered or controlled.
Researchers led by Alon Hertz at an Israel-based stealth security startup scanned 6,214 live domains tied to Fortune 500 companies, Big Tech firms, fintechs, and defense contractors. They examined thousands of llms.txt and llms-full.txt files and found 120 websites containing references to unregistered packages or domains. Across those files sat 227 installation commands pointing to unclaimed targets on registries such as PyPI and npm.
llms.txt is an emerging machine-readable Markdown file that websites place at their root, much like robots.txt for search engines. It gives AI systems a clean summary of a site’s content, documentation, APIs, and sometimes setup steps. The file itself does not run code. The risk appears when an AI coding agent reads an install instruction such as “pip install some-package” or “npx some-command” and has permission to execute package-manager commands.
Hertz and colleagues registered a handful of the abandoned package names and uploaded inert “phone-home” packages that simply reported when they ran. No persistence, no data theft, no malware.
The first callback from inside a Fortune 500 company arrived in under four minutes. Another followed within about an hour. Over time the researchers saw callbacks from a few dozen organizations, including additional large enterprises and startups. Process tracing linked some of the installations to coding agents including Anthropic’s Claude, OpenAI’s Codex, and Nous Research’s Hermes.
“The trust model is broken,”
Hertz said.
“Agents treat vendor docs as ground truth and don’t question them and neither do the humans supervising them.”
Anthropic, OpenAI, and Nous Research had not responded to requests for comment by the time of the initial reporting.
While scanning, the team found a live example involving Clerk, a popular authentication vendor. Clerk’s agent-oriented documentation instructed agents to run npx clerk-next-fix-auth-protection. That bare name had never been published as a standalone package. Someone else registered it and filled it with malware that collected the installer’s username, machine name, working directory, and timestamp, then sent the data to an external server. The package is catalogued as MAL-2026–11069. Clerk was notified and fixed the documentation issue.
This real-world case is distinct from the researchers’ harmless proof-of-concept packages.
To an endpoint detection tool or corporate proxy, the activity looks ordinary: an approved coding agent running a legitimate package manager against a trusted registry over HTTPS. The failure sits earlier in the chain no one verified that the package name in the official documentation was actually owned by the organization that published the file.
The researchers emphasize this is not evidence of broad “hacking” or widespread compromise of Fortune 500 networks. It demonstrates code execution and a genuine supply-chain weakness that traditional controls were not designed to catch.
Audit every AI-facing documentation file, especially llms.txt and llms-full.txt. Verify ownership of every referenced package and domain. Restrict autonomous installations by coding agents. Sandbox the agents. Monitor package-manager activity triggered by AI tools. Treat documentation as a security-sensitive asset that requires the same change control applied to code.
The boundary between data and executable instructions has shifted. Organizations that publish guidance for AI agents need to treat that guidance with the seriousness once reserved only for software itself.
