A security investigation has linked Claude, OpenAI Codex, and Nous Research’s Hermes coding agents to the installation of unclaimed software packages inside corporate environments. The activity emerged when researchers tested documentation files that directed agents toward packages and domains no organization currently owned.

The findings matter because the commands looked like ordinary developer setup instructions and, in several cases, came from legitimate corporate websites. Researchers said they received a callback from a Fortune 500 company within an hour of registering some abandoned package and domain names for a proof-of-concept test. The evidence does not establish widespread compromise, but it shows how AI agents with shell access can turn stale documentation into a software supply-chain entry point.

What the researchers found

According to Ars Technica AI, a stealth security startup in Israel scanned 6,214 live domains associated with defense contractors, Fortune 500 companies, and major technology firms. The team identified 8,265 files using the emerging llms.txt and llms-full.txt conventions, which websites use to provide machine-readable descriptions and navigation for AI systems.

Among those files, 120 hosted on separate sites referenced one or more unregistered package names or unclaimed domains. Across the files, the researchers counted 227 commands to install packages or access domains that were not owned at the time of the scan. Many references involved common package ecosystems, including PyPI and npm.

To test the risk, the researchers registered several of the abandoned names and hosted packages designed to contact their server when executed. The resulting beacon identified parent processes associated with Claude, Codex, and Hermes. The researchers also received callbacks from a few dozen organizations, including some Fortune 500 companies and startups, after the test packages were processed.

The investigation did not show that these companies were infected with malware. It showed that their environments executed proof-of-concept code or otherwise reached the researchers’ infrastructure. Anthropic, OpenAI, and Nous Research had not responded to requests for comment by the time of publication, according to Ars Technica AI.

A documentation problem becomes an execution risk

The exposure comes from the way AI coding agents combine browsing, retrieval, and command execution. An agent may read a vendor’s documentation, treat its contents as authoritative, and then run the setup command in a local or corporate environment. If the referenced package has never been registered, an attacker can claim the name later and publish malicious code under it.

One documented pattern used pip install or npm install instructions for packages that did not exist. Another referenced a non-existent testing framework domain. The security issue is therefore not limited to a malicious website or deliberately poisoned prompt. A documentation author may have entered an incorrect, obsolete, or hallucinated dependency years earlier, leaving the reference available for someone else to claim.

The researchers also described a case involving Clerk’s website. An llms.txt file included an npx command associated with a package name that had later been claimed and used to distribute live malware. Because npx can fetch and execute a package binary without adding it to a project’s dependency manifest, the command created a particularly direct path to execution.

Clerk subsequently fixed the documentation issue. The company said that users who had already installed a related package, @clerk/eslint-plugin, were not exposed to the malicious package under the circumstances it described. It remains unclear whether the Clerk confusion caused real infections.

Why conventional defenses may miss the signal

The investigation highlights a gap between the point where an unsafe decision is made and the point where corporate security tools typically look for abuse. A coding agent running pip or npm against a well-known package registry can resemble normal developer activity. Endpoint detection and response tools may see an approved AI assistant launching a familiar package manager over an allowed network connection.

The problem is the unverified relationship between the documentation and the dependency. An agent may confirm that the file came from an official HTTPS domain and that the command uses a standard registry, while failing to verify package ownership, publisher identity, provenance, or whether the dependency is expected in the project. Those checks are not necessarily part of the agent’s default workflow.

This is related to prompt injection but is broader in one important respect. Prompt injection generally involves deliberately planted instructions intended to manipulate a model. In the scenario described by the researchers, the original instruction can be genuine and benign. The danger appears later, when an abandoned package or domain becomes available to an attacker.

What it means for AI builders and enterprise teams

For developers of AI agents, the findings strengthen the case for treating retrieved documentation as untrusted input rather than as an extension of the user’s command. Agents that can run shell commands should separate reading instructions from authorizing execution, require confirmation for new dependencies, and check package ownership and provenance before installation. Sandboxing and restricted network access can reduce the consequences when those checks fail.

Product teams deploying coding agents inside companies face a more immediate governance question: whether an assistant should have unrestricted access to internal repositories, package registries, credentials, and production-adjacent systems at the same time. A useful deployment policy may allow code generation and testing in an isolated environment while blocking arbitrary package installation or requiring an approved dependency list.

Security teams should audit llms.txt and llms-full.txt files on their own domains, but the risk is not confined to those formats. Agents also consume README files, vendor SDK guides, issue threads, examples, and third-party documentation. Organizations will need dependency verification and provenance controls across the full retrieval path, including trusted partners and community projects.

The market implication is practical rather than speculative. AI coding assistants are being given more authority to act, while software supply-chain defenses are still largely designed around human developers and conventional build systems. The more often agents install tools automatically, the more important it becomes to record why a dependency was selected and which source authorized it.

What to watch next

The first signal will be whether Anthropic, OpenAI, or Nous Research disclose changes to their agents’ handling of installation commands, unregistered packages, and retrieved instructions. Security researchers and enterprise users should also watch for package-registry controls that flag abandoned-name reuse and for agent platforms that add provenance checks before execution.

A second signal is whether companies audit and correct their machine-readable documentation. The researchers’ scan found that some faulty entries predated the AI era, suggesting that cleanup alone may not solve the problem. Teams will need to monitor package ownership over time, not merely validate a dependency when documentation is first published.

Finally, incident responders may look for evidence that similar callbacks or package claims have occurred outside controlled tests. The current reporting demonstrates exposure and at least one live malware case involving a documentation reference, but it does not quantify confirmed infections across the affected organizations.

Creati.ai perspective

This incident is a warning about authority, not just model accuracy. An AI agent can make a technically correct request to a package registry and still be acting on an unsafe instruction. That distinction is easy to miss when the command originated on an official vendor domain.

For enterprises, the sensible response is not to abandon coding assistants, but to narrow what they can execute and require verifiable dependency provenance. Until agents can reliably distinguish reference material from authorization, every automated install should be treated as a security-sensitive action.