Anthropic Google Security Gap: AI Agents Followed Trusted Docs Into Unowned Code

Anthropic and Google now sit inside a security dispute after researchers reported that coding agents executed packages referenced by trusted corporate documentation. One test package reportedly ran inside a Fortune 500 environment within four minutes. Claude, OpenAI Codex, and Nous Research’s Hermes appeared in later process records, according to the researchers.

The finding does not show that Anthropic, Google, or OpenAI deliberately distributed malware. Most packages registered for the experiment contained harmless beacons, which only reported when they ran. The more serious discovery was an unrelated, reportedly malicious npm package connected to instructions once published on authentication provider Clerk’s website.

This distinction matters because the initial coverage can sound like three AI vendors breached corporate networks. The evidence instead points to a software supply chain failure. Agents trusted official-looking instructions, reached public package registries, and executed names that nobody had secured.

Google enters this Anthropic Google security story through its support for checking llms.txt files in Lighthouse, its website auditing software. Claude and Codex enter through the agents that reportedly followed installation instructions. The common problem is not one model or one company. It is the collapsing boundary between documentation and executable action.

That boundary used to feel clear. A developer could read a setup guide, verify a package, and decide whether to install it. An autonomous coding agent can compress those steps into one operation, often using the developer’s existing permissions.

The result is a new security question for every organization deploying coding agents: when software reads a document, who verifies that the document still points to something trustworthy?

Corporate AI agents executed names that nobody owned

Researchers turned stale documentation into executable proof that trusted text can become an entry point.

Security researcher Alon Hertz and colleagues examined machine-readable documentation across 6,214 live domains. Their sample included defense contractors, major technology companies, and Fortune 500 organizations.

The researchers reported finding 8,265 llms.txt and llms-full.txt files. An llms.txt file is an emerging convention that organizes a website’s content for language models and AI agents. Its larger companion can provide more extensive documentation in a single machine-readable file.

Among the collected files, 120 websites reportedly referenced at least one unregistered package or unclaimed domain. The team counted 227 commands involving nonexistent packages or destinations.

These were not necessarily hostile instructions. Some appeared to be ordinary installation commands pointing to package names that had never been registered. Others referenced domains that had expired or services that were no longer claimed.

A line such as pip install package-name becomes dangerous when the package name is available on PyPI. The same principle applies to npm, RubyGems, NuGet, crates.io, Packagist, or an abandoned hosting subdomain.

The researchers registered a small selection of these available names. They then published packages containing code designed to contact their server when executed. Hertz’s research account says the first callback arrived from a Fortune 500 environment within four minutes.

Two more systems reportedly executed the code within the first hour. Over time, the team received several dozen callbacks from startups and large enterprises.

The callback recorded the parent process chain, which identifies the programs involved in starting a process. According to the researchers, those records connected some installations to Claude, OpenAI Codex, and Nous Research’s Hermes.

The experiment did not require compromising those models. It also did not rely on a newly discovered software vulnerability, phishing message, or stolen employee password. The agents reportedly found instructions published on legitimate websites and followed them with the access available in their environments.

That is the central reversal. Corporate documentation normally strengthens security by showing developers the approved way to configure software. Here, abandoned references inside that documentation created an opportunity for someone else to define what the approved command would execute.

The finding also requires careful language. The researchers have not publicly identified the affected enterprises, released every package name, or provided enough telemetry for outsiders to reproduce each corporate attribution. Anthropic, OpenAI, and Nous Research did not comment before the original report was published.

Even with those limits, the experiment demonstrates a credible mechanism. A public package registry assigns meaning to whoever controls a name. Official documentation can preserve that name long after its intended meaning has disappeared.

Why the Anthropic Google trust chain failed

The agents did not ignore the trust model. They followed a trust model that no longer matched how autonomous software operates.

Traditional documentation assumes a human reader sits between instructions and execution. That reader can notice a strange package name, inspect its publisher, or ask why a setup command has no supporting repository.

An agent can perform the same checks, but only when its instructions and environment require them. Otherwise, it optimizes for completing the requested task. Finding official documentation and running its installation command can look like the shortest valid path.

The Anthropic Google connection highlights how several independently reasonable decisions can combine into one risky chain. Websites publish machine-readable guidance. Google’s Lighthouse tooling encourages developers to make that guidance discoverable. Coding agents search for authoritative context. Package managers make dependencies easy to retrieve and execute.

None of those components needs to be malicious. The danger appears when the agent treats the complete chain as authenticated.

Google’s Lighthouse guidance describes an audit for llms.txt availability and formatting. Lighthouse does not certify every command or dependency named inside a file. Passing a formatting audit therefore says nothing about package ownership, publisher identity, or code safety.

Similarly, HTTPS proves that a file came from the domain shown in the browser connection. It does not prove that every referenced package still belongs to that domain’s operator.

A public registry can also serve a correctly spelled package from an attacker-controlled account. This differs from classic typosquatting, where attackers register a misspelling resembling a popular package. The names in this experiment were reportedly copied directly from official documentation.

That makes the instructions more persuasive to both agents and humans. A developer reviewing a terminal transcript might see an official domain, a familiar package manager, and a plausible dependency name. Every visible signal can appear routine.

The agent’s search behavior compounds the problem. A user may mention only a vendor while requesting an integration. The agent can locate the vendor’s documentation, discover llms.txt, select an installation command, and invoke the package manager without receiving a suspicious link from the user.

This is why the incident is broader than prompt injection. Prompt injection usually involves hostile content attempting to redirect an agent. Here, the instruction itself can be benign and historically legitimate. The security failure occurs later, after ownership of the referenced destination changes or never existed.

The emerging llms.txt convention is also not equivalent to a formal web standard with an established security architecture. Its usefulness comes from giving models concise, structured context. That same convenience can concentrate operational instructions in a location agents are encouraged to trust.

The Anthropic Google security gap is therefore a provenance problem. Provenance means evidence showing where an artifact came from and who controls it. The agent verified the document’s location but apparently did not establish provenance for the executable dependency behind the command.

The real opponent is autonomy without provenance

The defining conflict is not Claude versus Codex. It is autonomous execution versus verified software ownership.

Claude, Codex, and Hermes use different models, interfaces, and permission systems. Treating this event as a simple comparison between those tools would miss the shared operating condition behind the reported installations.

Each coding agent can read project context, consult documentation, edit files, and invoke development tools. Those abilities make agents useful because they remove manual transitions between research and execution.

They also move a security decision into the agent’s workflow. Someone must decide whether a dependency is authentic, whether its version is acceptable, and whether its installation scripts should run.

Package managers routinely execute code during installation. An npm package can define lifecycle scripts, while a Python package can execute installation-related behavior through its build process. The exact behavior varies, but installation is not equivalent to downloading inert text.

The Clerk example shows why this matters. Researchers found that an instruction file on Clerk’s legitimate website referenced npx clerk-next-fix-auth-protection. The npx utility can download a package and execute its exposed command without adding it permanently to a project manifest.

According to the security investigation, someone had claimed that package name and used it to distribute live malware. Clerk later corrected the documentation.

It remains unclear whether that package caused infections through an AI agent. The reporting also notes that an existing binary from Clerk’s legitimate ESLint plugin was safe. A machine missing that legitimate binary could instead retrieve the attacker-controlled package.

The difference is subtle enough to escape a hurried reviewer. Both paths begin with a command published by the real vendor. Both use npm infrastructure. The dangerous path depends on whether the expected binary already exists locally.

This is the practical tradeoff facing enterprises. Agents deliver more value when they can resolve dependencies, run tests, and fix failures without waiting for approval after every command. Those same permissions let a mistaken trust decision turn into code execution.

The model provider can reduce that risk through sandboxing and approvals. The enterprise must still configure those controls, maintain network policies, and decide which package sources an agent can reach.

The software vendor owns another part of the problem. Its documentation has become an operational asset rather than static marketing content. Package references, sample domains, copied commands, and archived setup pages now require the same lifecycle management as executable code.

Registry operators also influence the outcome. Namespace reservation, publisher verification, suspicious-package scanning, and ownership history can help. However, registries cannot always know that an unclaimed name appears in a third party’s documentation.

This division of responsibility makes simple blame unhelpful. The Anthropic Google narrative is important because it crosses product boundaries. A search or documentation tool can make instructions easier to find, an AI agent can interpret them, and a registry can supply the named artifact.

Security fails when every participant assumes another participant verified ownership.

Existing agent safeguards do not erase the risk

Claude and Codex already provide meaningful controls, but those controls only work when organizations preserve their restrictive boundaries.

Anthropic’s Claude security guidance describes prompt injection as hostile text that attempts to manipulate an assistant’s instructions. It also documents permission controls and restrictions for commands that retrieve arbitrary web content.

Claude Code can use sandboxing to limit filesystem and network access. Child processes inherit those operating-system restrictions, which helps prevent an allowed command from quietly escaping into a less restricted process.

OpenAI describes a similar layered approach. Its Codex safety model combines sandbox boundaries, approval policies, managed network access, rules, and agent-aware telemetry.

OpenAI says its managed deployments do not give Codex unrestricted outbound access. Expected destinations can be allowed, unfamiliar domains can require approval, and security teams can export logs covering prompts, tool calls, approvals, and network decisions.

Those safeguards matter, but they do not automatically invalidate the researchers’ findings. Organizations can configure agents with broader access. Developers can approve commands. Local installations may inherit permissions and network connectivity from the user running them.

A package registry is also an expected destination in many development environments. Blocking all access to npm or PyPI would disrupt ordinary builds, dependency updates, and test setup. Allowing those domains removes one obvious network signal that could distinguish a malicious installation.

Endpoint detection and response software faces a similar challenge. A coding agent starts a standard package manager, which contacts a well-known registry over an encrypted connection. The process may resemble normal developer activity until the downloaded package performs something clearly hostile.

The research beacon was intentionally minimal. It reportedly contacted a server and recorded execution context. A real attacker could attempt credential theft, environment discovery, persistence, or modification of source code.

However, the public evidence does not show that the experimental packages performed those actions. It also does not establish that dozens of companies suffered production compromise. They executed proof-of-concept code, which is serious but narrower than a confirmed breach.

This skeptical distinction should shape enterprise response. Teams should not assume every use of Claude, Codex, or Hermes creates an infection. They should identify the conditions required for this path to work.

The agent needs access to the relevant documentation. It needs authority to invoke a package manager. The environment must allow retrieval from the registry. The package must execute meaningful code, and existing controls must fail to contain its behavior.

Removing any one of those conditions can interrupt the chain. Restricting network access is one option. Requiring human approval for dependency installation is another. Running agents in disposable containers can limit the consequences when a package does execute.

Organizations can also enforce an internal dependency proxy. The proxy can permit approved packages and versions while rejecting unknown namespaces. This approach moves the trust decision away from an agent reading public documentation.

Approval prompts alone are less reliable when they present only a familiar command. A reviewer needs context about package ownership, age, publisher identity, download history, and whether the dependency appears in an approved software bill of materials.

The lesson is not that safeguards are useless. It is that controls designed around obviously malicious commands can miss legitimate commands resolving to untrusted ownership.

Documentation now belongs in the software supply chain

Enterprises must treat every executable reference in documentation as a dependency that can expire, drift, or change owners.

The immediate response begins with inventory. Organizations should search llms.txt, llms-full.txt, developer portals, archived guides, code examples, support articles, and generated API references for installation commands.

Each referenced package, domain, repository, container image, and hosted subdomain needs an owner. A name that nobody recognizes should not remain public while an investigation proceeds.

Teams should verify that public package names match the organization’s real registry accounts. They should also inspect whether scoped packages are available where a global, unscoped name appears in older documentation.

Documentation pipelines need automated tests. A build can verify that every package exists, belongs to an approved publisher, resolves to an expected repository, and has not changed ownership.

Link checking alone is insufficient. A malicious package or reclaimed domain can return a successful response. The pipeline must validate identity rather than availability.

Companies should reserve names before publishing documentation. This is similar to registering defensive domains around an important product, but package namespaces require ongoing maintenance.

The same principle applies when a project is retired. Removing a package without removing its installation instructions creates an ownership gap. Abandoning a hosting subdomain while leaving links to it can let another party inherit a trusted path.

AI-generated documentation deserves additional scrutiny, but human-written pages are not exempt. The researchers found evidence that some questionable references predated the current agent era. Copying those pages into llms-full.txt made old mistakes easier for autonomous software to consume.

Enterprises deploying agents need a complementary control plane. Agent sessions should run under dedicated identities instead of a developer’s unrestricted account. Credentials should be scoped to the current repository and task.

Package installation should occur inside an isolated environment with limited access to secrets. If a dependency needs network access during installation, that access should be explicit and logged.

Teams should preserve the agent’s reasoning context alongside operating-system telemetry. A process log can show that npm started, while agent-native records can show which document supplied the package name.

That context matters during incident response. Investigators need to distinguish an approved project dependency from a package selected after an agent browsed external instructions.

Dependency allowlists can reduce risk, but they require an exception path for new packages. That exception should collect provenance evidence and require a named human owner.

Organizations should also maintain a searchable record of the sources agents consult. This can include documentation snapshots, package metadata, approval decisions, and generated code changes. A controlled technical knowledge base can help reviewers reconstruct why an agent selected a dependency.

The broader lesson extends beyond llms.txt. Coding agents consume issue descriptions, repository files, search results, package documentation, Model Context Protocol responses, and generated internal guides.

Any of those sources can contain an instruction. If the agent has tools, the instruction can become an action.

That makes documentation integrity part of software supply chain security. The enterprise cannot protect only source repositories and build servers while leaving machine-readable instructions outside its control.

Three signals will show whether the industry learned

The next phase depends on whether documentation, agent permissions, and registry identity improve together.

The first signal is disclosure and remediation across the 120 affected websites. Hertz’s team says it contacted affected organizations and relevant security teams, but the public record does not identify most domains.

Watch for companies auditing llms.txt files, reserving package names, and publishing incident notices. A coordinated cleanup would strengthen the argument that the industry recognizes machine-readable documentation as security-sensitive infrastructure.

Silence would not prove that no fixes occurred. Many organizations repair exposed references without public disclosure, especially when researchers used harmless code and found no confirmed data theft.

The second signal is a product-level provenance check from agent vendors. Claude, Codex, and Hermes can already ask for approval before commands, but approval becomes more useful when the interface explains the dependency behind the command.

A meaningful change would warn that a package is new, unverified, unrelated to the vendor’s known publisher account, or absent from the project’s existing dependency graph. A stronger system could require explicit approval whenever public documentation points to an unrecognized package.

Such a feature would strengthen the Anthropic Google security response because it would address the decision point before execution. Another generic warning about shell commands would offer less protection.

The third signal is registry and enterprise-policy integration. Package managers and internal proxies can expose publisher history, namespace age, signing status, and ownership changes. Agent platforms can use that metadata before selecting or installing a dependency.

An enterprise policy might allow established packages automatically while isolating unfamiliar packages for review. It might also reject a package whose name appears in official documentation but lacks a verifiable connection to the publisher.

This signal would weaken the researchers’ broader warning if dependable provenance checks stop the attack path across multiple agents. It would strengthen their warning if agents continue installing newly claimed names despite available identity data.

The current evidence supports a measured conclusion. Researchers reportedly demonstrated code execution in real corporate environments, and they connected some activity to prominent coding agents. They did not demonstrate that the model vendors intentionally installed malware or that every reported callback represented a serious compromise.

The more important finding is structural. Trusted documentation, autonomous execution, and public registries now form a supply chain that many security programs do not inventory.

Developers and enterprise buyers should ask direct questions before expanding agent permissions. Can the agent access public package registries? Does it verify publisher identity? Are installation commands isolated? Can security teams reconstruct which document caused an action?

The Anthropic Google security gap will not close through better model behavior alone. Documentation owners, registries, agent vendors, and enterprise administrators each control a different link.

Before giving a coding agent broader autonomy, test that complete chain with an unrecognized dependency. If the agent installs it without presenting provenance, the environment is treating documentation as authority instead of evidence.