August 2026 · 6 min read
When Docs Become Code: llms.txt Dependency Confusion
Key Definitions
llms.txt A machine-readable site summary and setup guide that websites publish for AI agents — like robots.txt for search engines, but treated by agents as authoritative instructions to execute.
Dependency Confusion When a package name or domain referenced by documentation was never registered, an attacker claims the empty slot and hijacks the install flow, turning a legitimate command into a malicious payload.
In August 2026, an Israeli security team proved what had been theoretical: AI coding agents will install code that belongs to no one inside Fortune 500 networks simply because a vendor document told them to. Documentation is no longer just information — it has become an execution surface for agents.
6,214 domains scanned: 120 documents pointing to unclaimed packages
The researchers scanned 6,214 live domains belonging to defense contractors, Fortune 500s, and big tech companies, finding 8,265 llms.txt and llms-full.txt files. Of those, 120 — each on a different site — pointed to one or more code packages or domain names that were never registered, containing 227 install or access commands in total.
To prove the danger, they registered some of the unclaimed names and hosted probe packages that made any executing machine phone home. A Fortune 500 company responded within an hour; over the following days, a few dozen more followed — more Fortune 500s and startups. The beacon's process chain revealed who had executed them: coding agents including Claude, OpenAI's Codex, and Nous Research's Hermes.
The mechanism: llms.txt turns 'documentation' into 'install instructions'
llms.txt is a structured summary sites publish for AI agents, often described as the robots.txt of the AI era. The problem is its trust model: the file is 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. To the agent, the file is the authority — that is its entire purpose. So when the file says 'pip install internal-tool', the agent doesn't pause to verify internal-tool belongs to the company, doesn't check the PyPI namespace, and doesn't notice the doc link points to a domain that expired three months ago.
The trust chain is transitive too. The llms.txt doesn't 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 that third party's file points to an unclaimed package, the chain works the same way.
Real case: Clerk's npx instruction and live malware
This is not purely theoretical. Researchers found the legitimate site clerk.com hosting an llms.txt that said 'npx clerk-next-fix-auth-protection'. Unlike a conventional install command, npx fetches a package into npm's cache and executes its exposed binary without adding it to the dependency manifest. Researchers soon discovered someone had claimed the empty slot and was hosting live malware. Clerk has since resolved the issue. The Clerk case is the cleanest proof: the command looked exactly like something the vendor would ship because it was in the vendor's own instruction file — every layer of trust was intact except the one nobody thought to check.
Why EDR doesn't blink
Traditional security controls can't catch this because every signal the system relies on points the wrong way. To any EDR or proxy, this looks like a developer running a legitimate package manager: pip 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 endpoint never had a chance because it was never asking the right question.
The researchers put it bluntly: 'An agent doesn't distinguish between a page and a command. Everything it reads is input, and every input is a potential instruction.' The entire corpus of published data 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.
The boundary between data and code is collapsing
The root cause is the same as prompt injection — LLMs can't reliably draw a boundary between authentic user instructions and content found on untrusted third-party sources. But this weakness is broader. Prompt injection needs an attacker to deliberately plant malicious instructions. Here the instruction can be completely benign and come from a legitimate source — a real company's own documentation — 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. That makes the attack nearly free: the attacker just registers a package nobody wanted, and the agent's trust model does the rest.
What enterprises should do: treat every document an agent reads as potential code
Separate retrieval trust from execution trust
Let agents read documentation, but never let them execute install instructions from it unconditionally. For pip/npm/npx commands, require ownership validation: the package must match a namespace the organization actually knows, or block it for human confirmation.
Bound the agent's execution permissions
Coding agents need shell access, but not unrestricted install authority. Use least privilege to limit which registries they can pull from and which directories they can write, and force second confirmation for high-risk commands such as direct npx execution or global installs.
Bring documentation into supply-chain risk management
Audit the documents agents consume the way you audit dependency manifests: check your own llms.txt for dead references, monitor for claimed-empty slots being registered, and feed agent installation activity into audit logs and SIEM.
The lesson for security teams: ask the right questions upstream instead of hoping the endpoint catches it downstream. When 'data becomes code', supply-chain integrity management extends from the code itself to everything an agent reads.
References
- Ars Technica: Claude, Codex, and Hermes installed unowned code inside corporate networks (2026-08-27) — https://arstechnica.com/security/2026/08/claude-codex-and-hermes-installed-unowned-code-inside-corporate-networks/
- Researcher disclosure: Data Became Code: We Ran Code Inside Fortune 500s Using Files They Published for AI Agents — https://medium.com/@alonhertz1/data-became-code-we-ran-code-inside-fortune-500s-using-files-they-published-for-ai-agents-0cd67ffbbffc
- llms.txt specification — https://llmstxt.org/
FAQ
What is llms.txt and why does it matter so much to AI agents?+
llms.txt is a machine-readable file sites publish to give AI agents a summary of content, structure, and setup instructions — often called the robots.txt of the AI era. The problem: agents treat it as authoritative. When the file says 'pip install some-package', the agent does it.
How do attackers exploit unregistered package names and domains?+
Researchers scanned 6,214 domains, found 8,265 llms.txt files, of which 120 pointed to non-existent packages or expired domains — 227 install or access commands in total. Attackers register those empty slots, so any machine executing the file downloads and runs the malicious package.
Why don't endpoint defenses (EDR) catch this attack?+
To an EDR or proxy it looks like a developer running a legitimate package manager: pip from pypi.org is a domain every corporate proxy allows, and the parent process is the coding agent the company installed on purpose. No anomaly, no alert — no product ever asks whether the package name actually belongs to the company.
What happened in the Clerk case?+
Clerk's llms.txt contained 'npx clerk-next-fix-auth-protection', and npx executes a package's binary directly without adding it to the dependency manifest. Researchers found the slot had been claimed and was hosting live malware. The command looked exactly like something the vendor would ship because it was in the vendor's own instruction file.
What concrete steps should enterprises take?+
Treat every document an agent reads as potential code: verify package/domain ownership before allowing install commands, separate retrieval trust from execution trust, restrict coding agents' shell privileges with mandatory human confirmation for high-risk installs, and log agent installation actions to audit trails.
Related Articles
Ransomware Used Cursor's Agent: Refusal Isn't Authorization
Aurora ransomware used Cursor's agent for hundreds of ops by claiming a 'test'. Refusals live in model reasoning — enterprises need verifiable authorization.
100+ Tech Firms Sign Open Letter to Defend Against Rogue AI
100+ firms (OpenAI, Anthropic, Google, Microsoft) sign an open letter urging new cyber defense and public-private collaboration against rogue-AI attacks.
GhostSplice: MCP Servers Split Instructions to Steal Keys
ASSET Aug 11: malicious MCP servers split an exfiltration instruction across tool calls so no single call looks malicious; compliance jumped from 42% to 82%.
AI Agent Incident Response: When the Playbook Breaks
CSA: the OpenAI-HF intrusion showed a detection-to-response gap — alerts fired but didn't escalate, and AI refused exploit-code forensics.