The file that tells AI agents what to install usually lives outside your change management. A research team just showed what that costs, and your security team can't fix it on its own.
When I was designing the APIs for Vetifly, I bought a separate .co domain and put every API on it. The reasoning was boring. If the .com went down for a bad deployment, a DDoS, an expired certificate or a CMS plugin doing something creative, the apps and our internal Ops portal would keep running. Different domain equals different failure domain.
I've been thinking about that decision a lot this month, because of a text file.
Researchers at Pandex scanned the llms.txt and llms-full.txt files that companies publish for AI agents. Some of those files pointed at packages and domains nobody owned anymore. Some had been renamed. Others were never registered at all. So the researchers registered a handful of the free names, put beacon code inside, and waited.
Four minutes to the first callback. Within the hour, one came from inside a Fortune 500 company.
There was no prompt injection and no social engineering. The trigger was an ordinary developer request: "Using all of [VENDOR]'s docs, build and run a node.js project with [VENDOR]'s SDK." The agent read the vendor's own documentation, found the reference, installed it and ran it. The team also found one case where someone had already done this with real malware.
"The trust model is broken," said Alon Hertz, one of the researchers. His point was that agents take vendor docs as ground truth, and so do the humans supervising them.
Your API documentation sits in a repo. Changes go through a pull request, someone reviews and merges them, and there's a deprecation policy when an SDK goes away. Every change has a name on it.
llms.txt carries the same instructions, reformatted for machines. In the enterprise setups I've seen this year, that file ships with the website. And marketing owns the website. So 'install this package' gets a review when a human will read it, and a content calendar slot when a machine will run it.
From what I've seen, and from conversations with friends in marketing, that website content is increasingly run through AI-led CMS tools. So a system with no visibility of the actual integration instructions has edit access to the file that publishes them. Google has already had a version of this. llms.txt files showed up across several of its developer properties, apparently pushed by an internal CMS update, and the one on Search Central got pulled within hours. By the look of it, nobody decided to publish them.
The llms.txt proposal was published by Jeremy Howard in September 2024 and reached v2 on 10 August 2026. It isn't a standard. It's an open proposal in a GitHub repo that changed six weeks ago. The spec lets you publish a file at the root or at any subpath, and tells agents to use the most specific one.
So the question isn't whether your organisation publishes an llms.txt. It's how many you publish, on which domains and paths, and who approved each one. Jeane Sumner talks about this at length. Shopify's old shopify.dev/llms.txt now returns a 404 with no redirect, and the file lives at shopify.com/llms.txt instead. Anthropic moved its docs too, but redirected the old path. Same kind of migration. One kept every old link working, the other didn't.
Which brings me back to the .co domain. Lighthouse looks for llms.txt at the root of your main domain, and its docs tell you to put it there. So the file describing your machine-facing contract gets pulled onto the marketing domain. Wrong failure domain, weakest change control.
You could put it on your API domain. The spec allows it. But very little will find it, because nothing tells an agent to look there. Discoverable and loosely governed, or well governed and hard to find. I haven't yet seen an organisation that has formally made that call.
There's a reason llms.txt ended up with marketing. It looks like robots.txt, and robots.txt has always been an SEO file. SEO sits in marketing. The tooling agrees: Yoast SEO and AIOSEO, both WordPress SEO plugins, now generate llms.txt for you. So the new file got handed to the team that owned the old one.
But the two files fail differently. Get robots.txt wrong and you lose rankings. Get llms.txt wrong and someone else's code runs on your customer's machine. robots.txt tells an agent where not to go. llms.txt tells an agent what to run. One is a marketing file. The other is an installation guide that happens to sit in the same folder.
So marketing owns the file, and engineering owns what it tells machines to do. Marketing has no way of knowing whether a package name is still registered. Engineering knows the file exists, but not who can edit it, and changes never come to them for review, not even after they've gone live. Each side assumes the other has it covered, and the file sits in the gap. It will never land on a risk register because it doesn't look like anything.
A gap between two teams gets fixed from above or not at all. Your CFO doesn't need to learn a file format. What leadership does need to own is narrower: deciding which artifacts are now in scope for change control, now that agents act on material only people used to read. That's an organisational design decision. It can't sit in the security backlog to be prioritized next quarter.
And the research only showed neglect. Stale references nobody claimed. I suspect the deliberate case is easier. One person with edit access to a marketing CMS can change that file, and there's no review gate like the one a code repo would have. From my experience, getting a marketing intern's credentials is a far easier task for a malicious actor.
Which team in your organisation can currently publish instructions your customers' machines will execute?
#AIGovernance #AIGRC #SupplyChainSecurity
Sources:
- Tom's Hardware: 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
- Schneier on Security: https://www.schneier.com/blog/archives/2026/09/ai-coding-agents-are-installing-unknown-untrusted-code-on-corporate-networks.html
- The llms.txt domain dilemma, Jeane Sumner, Website HQ: https://websitehq.com/the-llms-txt-domain-dilemma-where-should-you-actually-put-your-file/
- Google's llms.txt guidance depends on which product you ask, Search Engine Journal: https://www.searchenginejournal.com/googles-llms-txt-guidance-depends-on-which-product-you-ask/575431/