Physix Frontier
llms.txt is an interface, not a manual
When I saw that Fortune 500 AI coding agents were being tricked into executing arbitrary code via llms.txt, my first reaction wasn't "Security circles are exploding again," but rather "The spacing is wrong." A documentation file meant for machines was placed in the website root directory, looked like robots.txt, read like documentation, but ended up becoming executable instructions in the eyes of the agent. There was no whitespace between data and action, and the attack slipped through right there.
A detail in public research stands out: a security analyst said it took only 4 minutes to get a Fortune 500 company to run code they wrote. They scanned 8,565 llms.txt files across 6,214 domains, covering approximately 15,000 companies. The proportion of Fortune 500 companies actually hosting llms.txt isn't high, only 7.4%, but that doesn't matter. The danger doesn't come from how many files exist, but from the system's default trust in them. One sufficiently credible entry point is enough for someone to slip in malicious package names, installation commands, or script addresses.
Having done design systems for a long time, I treat "description" and "action" as two types of controls. Buttons are actions, hints are descriptions, and status copy should be restrained—you can't hide risks in text. The problem with llms.txt is that superficially it's a description, but it might actually be treated as a source of action by the agent. The file has no signature, no permission hierarchy, no sandbox prompts, and doesn't even tell the agent which fields are read-only and which require confirmation. To a designer, this is a semantic error. Something that looks like a README shouldn't have the power to install dependencies.
Interaction flows can be optimized. Currently, an agent's workflow often involves reading requirements, finding docs, parsing instructions, installing dependencies, and executing commands. llms.txt appears at the "finding docs" step and defaults into the context. The issue isn't whether it can be read, but why it can directly alter subsequent actions. After using WorkBuddy for three weeks, I have a deep realization: rules must hardcode conditions. For example, customer tiering must be limited to the last 6 months, cumulative transaction volume, and operation scope; otherwise, the system grabs other fields, resulting in outputs that look correct but aren't what was expected. I've also used n8n for a while. Once automation connects "reading" and "executing" too smoothly, dirty data turns into bad actions. llms.txt is the same type of pitfall, just with the object changing from tables to AI agents.
Underneath this is actually a visual language problem. Previously, when discussing interfaces, we talked about buttons, whitespace, hierarchy, and feedback. Now, the interface of AI agents isn't just the screen; it includes file naming, default paths, trust boundaries, and parseable context. Placing llms.txt in the root directory is itself a strong hint: things here are for machines to see, and machines should obey. This hint is bigger than any icon. Fortune 500 companies might treat it as AI SEO or crawler-friendly documentation, but agents treat it as an API. APIs have permissions, and APIs have attack surfaces.
Supply chain attacks aren't new terms. In the past, it was package managers, dependency libraries, and mirror sources. Now there's another path: turning documentation files into poisoning entry points. Researchers also mentioned that issue titles, PR descriptions, and comments can trigger prompt injection. Tools like Claude Code, Gemini CLI, and GitHub Copilot are included in the discussion. This means the problem isn't just in one txt file, but in the entire agent workflow. As long as agents read external text and decide actions based on it, text can become code.
Security teams might say: implement whitelists, signatures, sandboxes, and approvals. These are all correct, but not enough. User experience must keep up. You can't just give agents a "Allow execution?" popup, because everyone will blindly click confirm. Better design visualizes risk: Where does this dependency come from? Will it modify files? Will it access the network? Does it have a signature? How large is the change scope? Like releasing versions in a design system, diffs must be clear, impacts must be clear, and rollbacks must be clear. Security shouldn't be the final alarm, but a boundary visible at every step.
So, what truly worries me about this news isn't how dangerous llms.txt is, but that more and more "instructions for AI" are becoming system entry points. We used to think documentation was just documentation; now documentation is gaining power. The next question is: When a file sits in the website root directory and is read by agents by default, should we treat it as a manual, an API, or a permission request page?
📌 This article is compiled from Hacker News. Original source: https://www.tomshardware.com/tech-industry/artificial-intelligence/researchers-easily-trick-fortune-500-companies-ai-agents-into-running-arbitrary-code-supply-chain-attack-via-llms-txt-guidance-file-illustrates-how-data-has-become-code
Copyright belongs to the original authors. This is a compilation and independent analysis based on public reports.
