Data became code. And Fortune 500 companies ran it.
On August 27, 2026, security researchers published findings that should make every defense autonomy platform and aerospace OEM CISO sit up: AI agents — including Claude, OpenAI's Codex, and Nous Research's Hermes — auto-installed unclaimed packages from llms.txt files across more than 100 corporate websites. Within 4 minutes, the first Fortune 500 company called home. Within an hour, a few dozen more.
No CVE exploit. No phishing. No perimeter touch. The agents read official HTTPS-served vendor documentation, saw pip install company-sdk, and ran it. The package came from PyPI — exactly as the file said. But it was the researchers' package, not the vendor's. The vendor had never claimed that namespace.
The llms.txt Trust Model
llms.txt and llms-full.txt are an emerging convention — the AI equivalent of robots.txt — that websites publish to provide machine-readable summaries of their content for AI agents. Google Lighthouse recommends them. Vendors publish installation commands, SDK references, and quickstart sequences so agents can act on their documentation autonomously.
The problem: agents treat these files as ground truth and don't question them. Neither do the humans supervising them.
Alon Hertz, one of the researchers, described the core weakness bluntly: "The trust model is broken. An agent doesn't distinguish between a page and a command. Everything it reads is input, and every input is a potential instruction."
The Attack Surface
The researchers analyzed 8,565 llms.txt files across 6,214 active domains, including Fortune 500 companies, major technology firms, fintech providers, and defense contractors.
They registered unclaimed package names that appeared in these files and hosted proof-of-concept packages that phoned home when installed. The beacon recorded the chain of parent processes that spawned each install — revealing that coding agents, including Claude, OpenAI's Codex, and Nous Research's Hermes, were autonomously executing the commands.
Within an hour of publishing, they received callbacks from Fortune 500 companies. Over time, a few dozen more — some from Fortune 500s, others from startups with security teams larger than the researchers' entire professional network.
Live Malware in the Wild
The researchers also found at least one active attack already exploiting this vector. A misconfigured site — clerk.com — contained the text:
npx clerk-next-fix-auth-protection
The command appeared inside the site's agent-oriented guidance. Clerk had not published a standalone package under that name, leaving it available for third-party registration. A malicious package using that name was registered and is now tracked as MAL-2026-11069. According to the researchers, this package executed install hooks that transmitted the installer's username, hostname, working directory, and timestamp to an external server.
That's not a proof-of-concept. That's live malware on a vendor's official documentation, waiting for agents to read it and act.
Why This Matters for Defense and Critical Infrastructure
For defense autonomy platforms, aerospace OEMs, and classified-intel mission owners deploying AI agents at scale, this is the agent-data-boundary problem in its rawest form.
An agent that reads vendor docs to configure itself, install dependencies, or execute quickstart sequences cannot distinguish between legitimate vendor guidance and adversary-injected instructions. The agent sees a page that says pip install X. It installs X. If X is unclaimed, whoever registers it first controls what runs inside your network.
Monitoring tools see the breach after the package runs. They can trace it, log it, alert on it — but they cannot prevent the blind read. By the time the monitoring tool flags it, the code has already executed. In a defense or OT environment, that's not acceptable. You don't get to audit your way out of a supply-chain compromise after the fact.
Edge Enforcement vs. Post-Hoc Monitoring
This is the difference between monitoring and enforcement:
- Monitoring observes what an agent did and flags anomalies. It's a detection layer. It produces an audit trail. It tells you what happened.
- Enforcement prevents the agent from acting in the first place unless the action passes a deterministic policy check. It's an authorization boundary. It tells you what's allowed.
For the llms.txt attack, monitoring would detect the unclaimed package install after it runs. Enforcement would block the agent from reading untrusted package-installation commands in the first place — or require cryptographic proof of package provenance before allowing the install.
The Mission Authorization Gateway is built for the latter. Every agent action crosses a deterministic policy boundary before execution. The gateway evaluates the request — data source, data class, destination, context — and returns a cryptographically signed receipt: PERMIT, DENY, or CLAMP (permit with redaction). The agent cannot act without the receipt. If the policy forbids reading unclaimed package sources, the agent never sees the install command.
At the edge. Before the read. Every time.
The Supply-Chain Lesson
The researchers' work is a reminder that AI agents inherit every supply-chain risk we've spent the last decade trying to lock down — and introduce new ones we haven't.
Software supply-chain attacks (SolarWinds, Codecov, event-stream npm) exploited trust relationships in dependency trees. The llms.txt vector does the same thing, but the attack surface is every public-facing vendor documentation page an agent might read. The adversary doesn't compromise a package repository. They register unclaimed package names that official vendor docs already reference and wait for agents to follow the instructions.
Defense contractors, aerospace OEMs, and classified-intel programs cannot tolerate "we'll flag it after the code runs." The authorization boundary has to exist before the agent reads untrusted input. Deterministic. Cryptographically signed. Non-bypassable.
What This Means Now
If your organization is deploying AI agents with access to public vendor documentation:
- Audit what your agents can read. Enumerate every documentation source, SDK repository, and public API reference your agents are configured to consume.
- Enforce package-source allowlists. Do not allow agents to install arbitrary packages from public registries (PyPI, npm, Maven Central) without cryptographic signature verification or explicit allowlist approval.
- Require deterministic enforcement at the boundary. A monitoring tool that flags the install after it runs is not enough. The policy check must happen before the agent acts.
- Treat vendor docs as untrusted input. An agent cannot distinguish between a legitimate quickstart command and an adversary-injected one. Every external data source is adversarial until proven otherwise.
The researchers who disclosed this didn't defeat security controls. They abused the chain of trust. The agents did what they were built to do: read official vendor documentation and act on it autonomously.
The trust model is broken. Edge enforcement fixes it. Monitoring after the fact does not.
Learn more: Mission Authorization Gateway
Researchers' findings: GBHackers coverage (August 28, 2026); Slashdot thread (August 27, 2026); Artiverse analysis (August 28, 2026)