More than 100 corporate websites are hosting documentation files that instruct AI coding agents to automatically download and execute unowned code, opening a dangerous new supply-chain attack surface that researchers have already demonstrated against Fortune 500 companies. The vulnerability stems from an emerging web standard called llms.txt — a machine-readable file format designed to help AI agents navigate and understand website content — and the tendency of AI coding assistants to trust these files implicitly, installing whatever packages they reference without verification. Researchers at an Israeli stealth startup scanned over 6,200 live domains belonging to defense contractors, Fortune 500 companies, and Big Tech firms, discovering 120 files pointing to unregistered code packages or domain names. When the researchers registered a handful of those unclaimed names themselves and hosted beacon code, a Fortune 500 company called home within an hour. Dozens more callbacks followed, from additional Fortune 500 firms and startups alike, with process logs revealing that Anthropic’s Claude, OpenAI’s Codex, and Nous Research’s Hermes were the agents that had executed the unowned installations.
What Are llms.txt Files and Why Do They Matter for Security
The llms.txt and llms-full.txt file format is an emerging convention that websites use to provide machine-readable summaries of their content and high-level structure. Think of it as the artificial intelligence equivalent of the robots.txt standard, which instructs search engine crawlers how to index a site. Where robots.txt tells Googlebot which pages to crawl or avoid, llms.txt tells AI agents — particularly coding assistants and autonomous agents — where to find documentation, code examples, API references, and package dependencies that the site recommends. Google Lighthouse, the widely used web development tool, already includes an audit for llms.txt files, pointing to the format’s growing institutional acceptance. Correctly configured examples from Cloudflare show these files listing documentation paths, code repositories, and even recommended package installations that agents can fetch when they need to integrate with a service or understand an API.
The security problem is straightforward: when an llms.txt or llms-full.txt file on a legitimate corporate website references a code package or domain that is no longer registered, any AI agent that reads that file and follows its instructions will attempt to download and install that code. If an attacker registers the expired domain or package name first, they can serve malicious code directly into the corporate network where the agent is running. The agent treats the vendor documentation as ground truth, executes the installation without question, and neither the agent nor the human supervising it performs any verification of where the code actually came from or whether it matches the intended package.
The Research Methodology Behind the Discovery
Researchers at an Israeli stealth startup conducted a systematic scan of 6,214 live domains belonging to defense contractors, Fortune 500 companies, and Big Technology firms. The scan sought to discover how many of these organizations were hosting llms.txt or llms-full.txt files, and critically, how many of those files contained references to code packages or domain names that were either unregistered or had lapsed registration. The scan uncovered 8,265 llms.txt and llms-full.txt files across these domains — many sites host both formats — and of those, 120 files, each on a different website, pointed to one or more code packages or domain names that were not currently registered by anyone.
To test what actually happens when an AI agent encounters such a file, the researchers registered a small number of the unclaimed domain names and package names themselves. On each registered endpoint, they hosted packages that would cause any machine executing the installation to reach back to a researcher-controlled server. This beacon technique allowed them to observe, in real time, which organizations were running agents that automatically followed the instructions in llms.txt files, what the parent process chains looked like, and which AI coding assistants were responsible for each installation.
Within One Hour: A Fortune 500 Company Executes Unowned Code
The first callback arrived less than 60 minutes after the researchers registered the unclaimed names and set up their beacon infrastructure. A Fortune 500 company — the researchers declined to name specific firms to avoid disclosing active vulnerabilities — had an AI agent running inside its corporate network that read an llms.txt file from a legitimate vendor site, found a reference to an unregistered package, and automatically installed the code that the researchers had placed there. That installation triggered a network call back to the researcher’s server, confirming not only that the code had been executed but also revealing the chain of parent processes that had spawned the installation.
Over the following days and weeks, dozens more callbacks arrived. Some came from other Fortune 500 companies. Others came from startups. The beacon data painted a clear picture: AI coding agents are actively monitoring llms.txt files across the web, and when those files contain installation instructions — even for packages that don’t exist — the agents attempt to fulfill those instructions without any security validation whatsoever. The process logs were especially revealing, showing the specific agent processes that had triggered each installation.
Claude, Codex, and Hermes Identified in the Process Chains
The researchers’ beacon recorded the full parent process chain for each callback, ultimately identifying three specific AI coding assistants that had been involved in installing the unowned code: Anthropic’s Claude, OpenAI’s Codex, and Nous Research’s Hermes. These are not obscure experimental tools — Claude is Anthropic’s flagship large language model with millions of users, Codex is the coding engine behind GitHub Copilot and OpenAI’s broader developer ecosystem, and Hermes is a popular open-source model from Nous Research that is widely used in autonomous agent deployments. The presence of all three in the callback data suggests that the problem is not limited to a single vendor or platform but rather reflects a systemic trust model that treats vendor-supplied documentation as authoritative without any sandboxing, verification, or least-privilege controls on what code those documentation files can instruct the agent to install.
Anthropic, OpenAI, and Nous Research did not respond to requests for comment by the time of publication, leaving open questions about whether these companies are aware of the scope of the issue, whether they have internal mitigations in testing, or whether they consider the behavior a feature rather than a bug. The absence of public statements from any of the three vendors is itself notable, given the severity of what the researchers demonstrated and the direct naming of their products in the findings.
The Trust Model Is Fundamentally Broken, Researchers Warn
Alon Hertz, one of the researchers involved in the study, offered a stark assessment of the underlying vulnerability. The trust model is broken, Hertz wrote, because agents treat vendor documentation as ground truth and do not question it — and neither do the humans supervising them. This observation cuts to the heart of why the llms.txt attack surface is so dangerous. The entire premise of AI coding assistants and autonomous agents is that they can autonomously execute multi-step workflows, install dependencies, configure environments, and integrate APIs with minimal human intervention. The llms.txt convention was designed to make those workflows faster and more reliable by giving agents a standardized way to discover what a vendor offers. But the convention includes no mechanism for agents to verify that the packages referenced in those files are authentic, up-to-date, and controlled by the vendor they claim to represent.
Hertz further noted that agentic AI usage is exploding, and agents are spreading across every layer of the enterprise — software-as-a-service, cloud infrastructure, and endpoint devices. As the number of deployed agents multiplies, so does the supply-chain surface area that attackers can target, and today’s security guards simply do not cover it. Traditional software supply-chain security focuses on verifying the integrity of packages from package registries like npm, PyPI, and Maven Central, and on scanning for known vulnerabilities in dependencies. But the llms.txt attack vector bypasses all of those controls entirely because the code never goes through the standard package management pipeline. The agent downloads whatever the documentation file tells it to download, regardless of whether the target domain or package name is currently owned by the vendor or by an attacker who registered it first.
How the Attack Vector Works in Practice
The practical mechanics of the attack are straightforward, which is precisely what makes it so threatening. A typical scenario proceeds in several stages. First, a vendor hosts an llms.txt or llms-full.txt file that references code packages or API endpoints that are essential for integrating with their service. Over time, the vendor may stop maintaining that documentation, or the domain registration for a referenced package may lapse, or the vendor may simply have included a placeholder that was never properly claimed. Second, an attacker scans the web for llms.txt files containing unregistered domain names or package references. Third, the attacker registers those unclaimed names and hosts malicious code at the expected location. Fourth, when any AI agent operating inside a corporate network reads that vendor’s llms.txt file and follows its instructions, the agent downloads and executes the attacker’s code — all within the trusted boundary of the corporate network, with the agent’s privileges, and without generating any of the usual security alerts that would accompany a suspicious download.
In the researchers’ proof-of-concept demonstration, the malicious code was a benign beacon that simply called home to report that the installation had succeeded. In a real attack, the code could do anything the agent’s permissions allow: exfiltrate data, install backdoors, pivot to other systems, modify configuration files, deploy ransomware, or establish persistent access for later use. Because the agent executes the installation using its own privileges, the code runs with whatever access the agent has been granted — which in many corporate deployments includes access to source code repositories, cloud infrastructure credentials, internal APIs, and sensitive databases.
The Scope of Exposure: More Than 100 Sites and 6,200 Domains Scanned
The researchers scanned 6,214 live domains to arrive at their findings. That number is not random — it represents a focused effort to examine the most consequential targets: defense contractors, Fortune 500 companies, and Big Technology firms. Of those 6,214 domains, the researchers found 120 that hosted llms.txt or llms-full.txt files containing at least one reference to an unregistered code package or domain name. Each of those 120 sites represents a potential entry point for an attacker who registers the unclaimed reference before any AI agent encounters it. And the 6,214 domains themselves are a small fraction of the total number of corporate websites that now host llms.txt files. The convention is still emerging, but its adoption is accelerating rapidly, driven by Google Lighthouse audits and by the increasing expectation that websites should be machine-readable for AI agents. As adoption grows, so does the number of files that contain stale, incorrect, or abandoned package references.
The researchers did not attempt to determine how many of the 120 vulnerable sites were actively being exploited in the wild, nor did they test whether the unregistered references on those sites had ever been claimed by malicious actors. Their proof-of-concept was designed to demonstrate the existence of the vulnerability and to measure how quickly AI agents would exploit it if attackers did register the unclaimed names. The answer to that question was clear: within one hour, a Fortune 500 company’s agent had already executed the beacened code.
What Is an llms.txt File and How Does It Differ from robots.txt?
An llms.txt file is a text file placed at the root of a website, similar to robots.txt, but designed for AI agents rather than web crawlers. While robots.txt tells search engines which URLs to avoid crawling, llms.txt tells AI agents where to find documentation, code examples, API references, configuration recommendations, and package dependencies. The llms-full.txt extension provides a more detailed version with the complete content of the documentation rather than just links and summaries. The intended purpose is admirable: as AI agents become more capable of autonomously integrating with web services, a standardized file format that tells them exactly what to install and how to configure it can dramatically reduce integration friction. But that same efficiency becomes a liability when the file contains stale or unregistered references, because agents follow the instructions without independent verification, treating the vendor’s documentation as authoritative ground truth.
Robots.txt has its own security considerations — attackers can use it to discover hidden directories or to manipulate crawler behavior — but it does not instruct search engines to download and execute code. Llms.txt does exactly that: it instructs agents to install software packages, download code repositories, and configure system settings. The leap from “what pages should I crawl” to “what code should I execute” represents a fundamental escalation in the trust placed in a plaintext file, and the security industry is only beginning to grapple with the implications.
Why Existing Security Controls Fail Against This Attack Vector
Traditional software supply-chain security tools focus on scanning dependencies that enter the organization through established package registries. Developers run dependency scanners that check for known vulnerabilities, verify checksums, and maintain software bills of materials. But the llms.txt attack vector bypasses all of those controls because the code is not fetched from a package registry at all. The agent downloads the code directly from the domain or package name referenced in the llms.txt file, which may be a completely unknown domain that no security tool has ever cataloged. There is no intermediate registry, no checksum verification, no signing key validation, and no approval workflow. The agent simply fetches whatever the documentation tells it to fetch and executes it.
Network security controls are similarly ineffective because the agent is already inside the corporate network, running on a trusted machine with legitimate credentials. The agent’s network traffic to download the malicious package will typically pass through the corporate firewall without triggering any alerts because the agent is a trusted application and the download is outgoing to an external domain that has not yet been blacklisted. By the time the domain is identified as malicious, the code has already been executed and the damage — if the attacker chose to cause any — would already be done.
Human oversight also fails because the entire point of AI coding agents is to reduce the need for human intervention in routine integration tasks. The human supervising the agent may not even be aware that the agent has read an llms.txt file and installed a package from it. Even if the human is watching, the agent’s log may simply show that it installed a package from a vendor domain that the human trusts. The human has no way to distinguish a legitimate installation from a hijacked one without manually inspecting the exact domain registration status of every package the agent encounters.
The Supply-Chain Surface Expands as Agentic AI Deployments Grow
The researchers’ warning about the expanding supply-chain surface is grounded in concrete trends. Enterprise adoption of AI coding assistants and autonomous agents is accelerating rapidly across every industry sector. Cloud providers, cybersecurity platforms, and productivity tools are all embedding agentic capabilities that can autonomously execute multi-step workflows. Each new agent deployment adds another endpoint that could potentially be exploited through an llms.txt file with an unregistered reference. The agents do not even need to be explicitly programmed to read llms.txt files — many coding assistants automatically fetch and process these files as part of their normal operation when integrating with documented services.
The problem is compounded by the fact that llms.txt files on legitimate vendor sites can remain vulnerable for extended periods. A vendor may include a reference to a package that exists today but whose domain registration lapses next year. Or a vendor may include a package name that was never registered in the first place — a placeholder that the vendor intended to register but never got around to. Or a vendor may change its infrastructure, deprecating old package domains without updating the llms.txt file. Each of these scenarios creates a window of opportunity for attackers who monitor the web for vulnerable documentation files.
At Least One Misconfigured Site Is Directing Visitors to Live Malware
Beyond the researchers’ proof-of-concept demonstration, the broader scan also revealed an even more alarming finding: at least one misconfigured site among the 120 vulnerable domains is currently directing visitors — human or AI — to live malware. The researchers did not identify which site or what malware, likely to avoid tipping off attackers or causing panic, but the implication is clear. The theoretical attack vector that the researchers demonstrated with their benign beacon is already being exploited in the wild, at least on that one site. Whether the malware was placed there intentionally by an attacker who scanned for unregistered references, or accidentally by a vendor who uploaded compromised code to what they believed was their own domain, the result is the same: any AI agent that encounters that site and follows its llms.txt instructions will be infected with live malware.
The presence of at least one live malware distribution point among the vulnerable sites raises the urgency of the issue considerably. This is not a theoretical future risk or a proof-of-concept waiting to be weaponized. The weaponization has already begun, at least in one case, and the mechanisms by which attackers can discover unregistered references are the same mechanisms the researchers used. Automated scanning of llms.txt files across millions of domains is trivial to conduct, and registering unclaimed domain names costs only a few dollars each.
What Enterprises Can Do to Mitigate the Risk
The vulnerability described by the researchers is not primarily a problem with the llms.txt standard itself, nor is it a bug in Claude, Codex, or Hermes that can be patched with a software update. It is a problem with the trust model underlying how AI agents handle documentation-driven code execution. That means the mitigation burden falls not just on AI vendors but also on the enterprises deploying these agents and on the security industry that protects them.
Until AI vendors implement sandboxing, least-privilege execution, and domain verification for all code installed through llms.txt references, enterprises should take several practical steps. They can configure their AI agents to use a controlled package registry or a curated allowlist of domains from which code installations are permitted, blocking all installations from unregistered or unknown domains. They can deploy network monitoring that specifically tracks outbound connections triggered by AI agent processes, looking for connections to domains that were registered very recently or that match known patterns of expired domain squatting. They can enforce a policy that all code installations performed by AI agents must go through a human approval workflow, even if that reduces the autonomy that the agents are intended to provide. They can scan their own internal and third-party llms.txt files for references to unregistered domains and package names, treating those references as critical vulnerabilities that must be remediated immediately. And they can work with their AI vendors to demand transparency about what files their agents read, what code they install, and what verification checks are performed before execution.
Security teams should also consider the broader implications: if an attacker can cause a trusted AI agent to install unverified code by simply registering an expired domain referenced in a documentation file, then every domain registration lapse of a package referenced in an llms.txt file becomes a potential supply-chain attack. The half-life of domain registrations — typically one to three years before renewal is required — creates a recurring window of opportunity that attackers can systematically exploit by monitoring domain expiration dates for packages referenced in popular documentation files.
The Path Forward: Trust but Verify in the Age of Autonomous Agents
The discovery that Claude, Codex, and Hermes installed unowned code inside corporate networks should be a watershed moment for AI security — not because the vulnerability is uniquely severe, but because it is so representative of the challenges that lie ahead. The llms.txt attack vector is a perfect illustration of what happens when the AI industry prioritizes agent autonomy and seamless integration over security verification. The same quality that makes these agents powerful — their willingness to trust documentation and execute instructions without question — is the quality that makes them exploitable. The solution is not to abandon that autonomy, which is the entire value proposition of agentic AI, but to add verification and sandboxing layers that do not exist today. Vendors like Anthropic, OpenAI, and Nous Research must treat domain verification, package integrity checking, and least-privilege execution as core security requirements rather than optional features, and they must collaborate with the security community to ensure that their agents do not become the preferred vector for supply-chain attacks in the era of autonomous computing. The researchers who demonstrated this vulnerability have done the industry a significant service by revealing the broken trust model before widespread exploitation becomes inevitable — but the clock is ticking, and at least one site is already pointing to live malware.
