AI agents are introducing a significant shift in software supply chain security: documentation is no longer necessarily passive information. Research into thousands of llms.txt files found references to packages and domains that no longer had an owner. After registering some of them, the researchers found that agents tied to Claude, OpenAI Codex, and Hermes ended up installing their test packages inside corporate environments, including Fortune 500 companies.
The orphaned-code risk for AI agents in 30 seconds
- The analysis covered 6,214 domains belonging to Fortune 500 companies, major tech firms, and defense contractors.
- 120 sites contained references to one or more packages or domains that were available to register.
- The researchers claimed some of the names and published test code designed only to confirm it had run.
- Signals came back from several companies, and some installs could be traced to Claude, Codex, and Hermes.
- The problem widens the scope of supply chain security: an agent can turn outdated documentation into a real action.
There was no need to compromise a company’s website, send phishing emails, or exploit a zero-day vulnerability. No code was inserted into a legitimate repository, either.
The researchers relied on something much simpler: old references that were still treated as valid after the original resource had disappeared.
The case is especially relevant now that coding agents are starting to get permission to use terminals, install dependencies, modify repositories, run tests, and operate development tools.
A broken link doesn’t always end in a 404 error anymore.
In certain automated workflows, it can become an opportunity to introduce code.
From llms.txt to the terminal: where the security model changes
llms.txt is an emerging convention meant to give language models a simple, structured representation of a website’s content.
The usual comparison is robots.txt, although technically the two serve different purposes. While robots.txt gives instructions to crawlers, llms.txt is meant to help models and agents find and understand relevant documentation.
The format by itself doesn’t install anything.
The risk appears when the information it contains or references ends up being used by an agent that does have the tools to act.
Technical documentation might say, for example, that using a certain library requires installing a package. The agent reads the instructions, determines it needs that dependency, and runs the corresponding package manager.
That workflow works fine as long as every component in the chain stays under legitimate control.
But the internet has been piling up years of technical debris: discontinued projects, deleted repositories, retired packages, expired domains, and documentation nobody has updated since.
The researchers analyzed 6,214 active domains belonging to large organizations. According to the published data, they found 8,265 llms.txt and llms-full.txt files and identified 120 sites pointing to one or more unclaimed resources.
The situation echoes well-known supply chain problems, but it introduces an important difference.
Before, there was usually a person standing between the documentation and its execution.
Now there can be an agent instead.
A package disappears, but its trust sticks around
To test the consequences, the researchers registered some of the names that had become available.
They didn’t publish malware meant to compromise the companies. They used test packages built to send a signal to their infrastructure whenever they ran.
Then they waited.
The mechanism is especially interesting from a security standpoint because the researchers didn’t have to actively hunt for vulnerable systems. The references were already published by the organizations themselves, or in documentation considered legitimate.
Once agents processed that information and ran the installs, the signals started coming in.
Analysis of the process chains made it possible to link some of the executions to coding agents, including Claude, OpenAI Codex, and Hermes from Nous Research.
That needs an important caveat.
The experiment doesn’t prove that these agents always and autonomously install any package mentioned in llms.txt. Whether they run depends on how each agent is configured, the instructions it received, the tools available to it, and the permissions granted by the user or the organization.
That’s exactly where the security question lies.
The more autonomy an agent has, the more it matters to verify where every instruction it turns into an action actually came from.
The old problem of expired domains reaches AI agents
David Carrero Fernández-Baillo, co-founder of Stackscale (Grupo Aire), sees an interesting parallel with a phenomenon that’s been known on the internet for years: the residual trust of expired domains.
Carrero explains that he has registered expired domains on occasion for legitimate SEO-related projects. A domain with years of history can keep links from other pages and part of the authority it built up under its previous owner.
The new owner inherits, to some extent, a reputation they didn’t build themselves.
The research into agents shows a considerably more delicate version of the same principle.
If a company recommended a domain, package, or repository for years and that resource later disappears, the reference can keep the previous owner’s trust even after control has changed hands.
With a traditional website, the consequences might be limited to sending visitors to a domain that now belongs to someone else.
With technical documentation processed by agents, the new owner could inherit something different: a position inside a chain that eventually ends in software execution.
As Carrero points out, the conceptual leap is considerable: it goes from inheriting the SEO authority of links to potentially inheriting a door that the documentation left open.
This isn’t a vulnerability in llms.txt
Framing the whole discussion around llms.txt could lead to the wrong conclusion.
Removing those files wouldn’t solve the problem.
An agent can pick up instructions from a README, official documentation, a repository, a support page, a tutorial, or any other source it considers sufficiently trustworthy.
The problem lies in confusing documentary authority with the authority to execute.
Security teams have spent years protecting code repositories and continuous integration/continuous deployment (CI/CD) pipelines. They scan dependencies, container images, credentials, and build artifacts.
Documentation has normally been treated differently, because historically its ability to change systems was indirect.
Agents are changing that separation.
If a document can cause an agent to run a command, install a dependency, or change a configuration, that document becomes part of the attack surface.
That also forces a rethink of the security of content published by companies themselves.
A company should be able to answer questions that until recently seemed secondary: do all the packages recommended in its documentation still exist? Do the linked domains still belong to the same owner? Are the mentioned repositories still legitimate? What happens to the documentation for discontinued products?
Maintaining documentation is starting to take on characteristics of dependency management.
The supply chain needs a layer specifically for agents
The technical response shouldn’t simply be another warning bolted onto the model, either.
Organizations that let agents execute code need controls outside the model itself.
The simplest principle is never letting a documentary source alone be enough to establish trust in a dependency.
A package’s provenance should be verified independently. Depending on the environment, that can mean checking the registry, owner, version, age, signature, hash, source repository, and other available data.
Agents also shouldn’t automatically get the same privileges as a developer.
An isolated or disposable environment lets an agent try out a dependency without immediately pulling the code into systems that have access to corporate information.
That separation matters especially when the agent holds credentials for cloud services, private repositories, secrets managers, CI/CD pipelines, or production infrastructure.
Human approval still makes sense for certain operations.
But it shouldn’t be used as the only line of defense, either.
Someone who gets dozens of confirmation requests will end up approving them mechanically, especially if the interface only ever asks something like “allow installation?”
The control should provide context: what package will be installed, who maintains it, where the recommendation came from, and why the agent thinks it’s needed.
The cultural problem behind the technical flaw
Carrero also points to a less visible aspect of the research: 120 of the 6,214 sites analyzed still carried references to resources that were no longer properly under control.
That isn’t the result of some sophisticated vulnerability.
It’s the outcome of practices that have been known for decades: documentation that goes stale, abandoned projects, domains nobody renews, and references copied for years without anyone checking their status.
Copy-paste has always been part of the risks of software development.
The difference is scale.
A developer might copy a command, run it, hit an error, and stop. An agent can check dozens of pages, resolve dependencies, and execute instructions in seconds.
Automating a task also automates its bad habits.
That’s why the problem has a cultural dimension as well as a technical one.
The arrival of agents means abandoning a deeply held assumption: that anything published under a vendor’s domain can automatically be treated as true and current.
Documentation is a source of information.
It shouldn’t work like a digital signature.
From broken links to a new attack surface
The research also hints at how offensive security might evolve.
The internet holds millions of abandoned references. Many belong to projects of no consequence, but others sit inside corporate documentation, old scripts, repositories, tutorials, and configuration files.
Until now, finding one of these resources was usually worth very little.
Agents can change that equation.
An attacker could systematically hunt for references to abandoned packages, domains, or repositories that show up in documentation used by automated tools.
The goal would no longer be convincing a person to install something.
It would be finding an abandoned chain of trust that machines are still consuming.
The llms.txt experiment shows that possibility no longer belongs purely to the theoretical realm.
Companies are rolling out agents capable of writing code, using terminals, and managing services at considerable speed. They now need to make sure the trust those systems place in the internet doesn’t advance at the same pace, unchecked.
Because orphaned code has been around for years.
What’s changed is that there are now agents willing to find it, interpret it, and, under the right conditions, run it.
Frequently Asked Questions
Is llms.txt a security vulnerability?
Not by itself. llms.txt is a convention for giving models and agents information. The risk appears when an agent turns the instructions it finds into actions without independently verifying the resources involved.
What is an orphaned package?
In this context, it’s a package name, domain, or other resource mentioned in existing documentation that is no longer controlled by its original owner. If someone else can claim it, old references can end up pointing to the new owner.
Did Claude, Codex, and Hermes run the researchers’ code?
The researchers linked certain installs to process chains associated with Claude, OpenAI Codex, and Hermes. The experiment doesn’t imply that these agents always behave this way: it depends on their configuration, permissions, and environment.
How should a company using AI agents protect itself?
It should apply least privilege, isolate executions, verify dependencies through independent mechanisms, and periodically review the packages, domains, and repositories recommended by its documentation. Sensitive actions shouldn’t depend solely on an agent deciding a webpage is trustworthy.
Source: Open Security
