Home Cyber Security News AI Agent Instruction Files Let Attackers Execute Code Inside Fortune 500 Networks

AI Agent Instruction Files Let Attackers Execute Code Inside Fortune 500 Networks

0

A newly disclosed novel supply chain attack vector built entirely from publicly available, legitimate infrastructure: LLM.txt files.

In a controlled experiment, Alon Hertz registered the names of unclaimed packages referenced in official corporate instruction files and had code execute within a Fortune 500 network within four minutes.

llms.txt (and llms-full.txt) are emerging root-level files, similar to robots.txt, that companies publish to guide AI agents toward documentation, APIs, and installation commands.

AI Agent Instruction Files

Google has institutionalized the format through a Lighthouse “Agentic browsing audits” category in Chrome DevTools, accelerating adoption across the web.

The research team resolved 8,565 llms.txt files across 6,214 live domains, representing roughly 15,000 companies surveyed, spanning tech giants, fintechs, and defense contractors. The critical flaw isn’t misconfiguration or typosquatting; it’s abandonment.

Google’s own tooling (Source: Alon Hertz)

Alon Hertz found 237+ instances in which official files instructed agents to install exact-match package names or to visit domains that were never actually registered by the vendor.

Names were “printed in black and white” but simply unclaimed on PyPI, npm, RubyGems, NuGet, crates.io, and Packagist, or as expired subdomains on Render, Vercel, Fly, and Netlify.

Alon Hertz claimed these package names and embedded a benign phone-home beacon. The first callback from inside a Fortune 500 environment arrived in under four minutes; a second came within the hour.

Testing showed that a single prompt naming only a vendor, with no URL or mention of llms.txt, was sufficient across five frontier model configurations and two agentic CLIs to enable agents to autonomously discover the file and install the unclaimed package.

While analyzing the corpus, Alon Hertz found an active exploitation case involving Clerk, the authentication vendor. Clerk’s agent-facing documentation referenced running npx clerk-next-fix-auth-protection, a binary meant to ship inside the scoped package @clerk/eslint-plugin.

Registered acme-client  (Source: Alon Hertz)

When run before local installation, npx resolves to the public registry, where Clerk has never published a standalone package under that name. A third party had registered it and planted code that exfiltrates the installer’s username, machine name, and timestamp on every install.

The package is now tracked as MAL-2026-11069, classified under CWE-506 (embedded malicious code), and flagged by both OSV.dev and Amazon Inspector. Clerk was notified and remediated the issue.

The technique evades endpoint detection because every observable signal appears legitimate: HTTPS delivery from a trusted vendor domain, standard package manager traffic to allowlisted registries like pypi.org, and execution via an agent the organization intentionally installed.

No CVE, phishing, or perimeter breach is involved; the trust chain itself is the vulnerability, and it extends transitively through any third-party docs an agent is configured to consult.

Researchers frame this as a broader shift: agent-consumed content GitHub repos, tickets, forums, documentation has become an untreated execution surface, with no findings yet disclosed publicly beyond the Clerk case.

Give your security team the visibility and context to investigate suspicious activity faster and contain threats before business impact grows. Strengthen Your Investigations with ANY.RUN

NO COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Exit mobile version