Security in corporate environments just got a troubling new chapter — and it has everything to do with AI agents you probably already use at work. The news broke after a detailed investigation and shows how something seemingly harmless can become a silent entry point inside the networks of major companies.
Researchers from an Israeli startup operating in stealth mode discovered that agents like Claude, Codex (from OpenAI), and Hermes (from Nous Research) installed ownerless code inside the networks of large enterprises, including some on the Fortune 500 list. And the most impressive part: several of these companies actually executed proof-of-concept code created specifically to demonstrate the risk.
The most surprising thing wasn’t what these agents did — it was where the trigger came from.
The vulnerability wasn’t hiding in some obscure system or exotic infrastructure flaw. It was tucked away in documentation files that almost nobody monitors closely: llms.txt and llms-full.txt files, an emerging standard that websites use to communicate with AI agents — kind of like the well-known robots.txt, but designed for intelligent machines. When these files pointed to packages or domains with no registered owner, the agents simply followed the instructions. No questions asked. No alerts raised. And that’s exactly what opened the door. 🚨
What are llms.txt files and why they matter so much
If you’ve ever worked with SEO or web development, you’re familiar with robots.txt — that simple file that tells search engines what they can and can’t index. llms.txt follows a similar logic, but with a different and much more recent purpose: it serves as a structured, machine-readable guide so AI agents can understand a site’s content and its high-level structure more efficiently. The idea is solid, functional, and makes sense within the modern AI ecosystem — but like any new standard, it still carries weaknesses that need to be taken seriously before it becomes the norm across every environment.
It’s worth noting that there are examples of proper configuration for these files out there. Cloudflare, for instance, maintains well-structured llms.txt and llms-full.txt files as a reference. Tools like Google Lighthouse, built to help web developers, have also incorporated specific audits for this type of file, which shows just how much traction the standard is gaining. Many sites even host both versions simultaneously, offering a short summary alongside a full version of their documentation.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
The problem identified by the Israeli researchers is that these files can contain references to external packages, repositories, and domains that, at some point, stopped having an active owner. When an AI agent like Claude, Codex, or Hermes reads these instructions and decides to follow them — which is exactly the behavior they were trained for — it can end up fetching resources that were registered by bad actors. And that’s when the whole picture changes. The agent wasn’t hacked. It just did what it was programmed to do, following instructions that looked legitimate.
This type of attack has a name in the security world: dependency poisoning, or dependency confusion. It’s not a new concept for anyone working in software security, but what’s new here is that it was adapted to exploit the automatic trust that AI agents place in instruction sources — and that changes the scale of the problem significantly. Before, a human developer could, in theory, spot something off before installing a suspicious package. An AI agent, on the other hand, operates with far greater speed and volume, without the same intuition or skepticism a human would have when something seems out of place.
How the researchers found the problem
The methodology used in the investigation is as interesting as the results. The researchers scanned 6,214 active domains belonging to defense contractors, Fortune 500 companies, and tech giants. Within that universe, they found 8,265 llms.txt and llms-full.txt files — a number larger than the site count, precisely because many hosted both versions.
Out of those thousands of files, 120 of them, each on a different site, pointed to one or more code packages or domain names that weren’t registered. To test what happens when an AI agent processes these files, the researchers registered some of those abandoned names and hosted packages that made any machine executing them phone home to their server.
The results came fast. In less than an hour, the researchers received the first callback from a Fortune 500 company. Over time, a few dozen more responses rolled in — some from other Fortune 500 companies and others from startups. The signal sent by these packages also logged the process chain that triggered each installation, clearly revealing that coding agents like Claude, Codex, and Hermes were involved. As of the original report’s publication, Anthropic, OpenAI, and Nous Research had not responded to requests for comment.
How ownerless code got inside corporate networks
The sophistication of this attack lies precisely in how simple the vector is. Nobody had to break into a server, exploit a zero-day flaw, or engineer an elaborate phishing attack. All it took was registering domains and packages that were referenced in llms.txt files on legitimate websites — resources that, at some point, had been active and were later abandoned. With those assets under their control, the researchers simply waited for a well-intentioned AI agent, running routine tasks inside a corporate network, to do the rest of the work.
Inside the affected companies — some with billion-dollar revenues and global footprints — these AI agents were being used exactly as the tools promise: to automate tasks, consult documentation, generate code, and integrate systems. Codex, for example, is widely used by development teams to speed up code writing. Claude has been adopted in workflows ranging from document analysis to internal support. Hermes, in turn, shows up in more technical natural language processing pipelines. All of them, within the context of this investigation, were involuntary vectors for behavior that no security team was monitoring — because nobody knew they needed to monitor it in the first place.
It’s worth highlighting that in the case tested by the researchers, the packages only sent a signal back to prove the concept. But nothing would have stopped a real attacker from swapping that harmless behavior for malicious code capable of executing arbitrary commands, collecting environment data, or escalating privileges within the network. The researchers even flagged that at least one misconfigured site was directing visitors — human or AI — to active malware. The level of damage in a real-world scenario would vary depending on the permissions each agent had at the time of execution.
And this is a critical point that many IT teams still haven’t built into their security policies: AI agents need to be treated as entities with permissions, just like any human user or automated system. Giving an agent unrestricted network access because it was brought in to be helpful is the same conceptual mistake as handing an intern the root password on day one.
The trust model is broken
One of the researchers behind the discovery, Alon Hertz, put the problem bluntly in an interview. According to him, the trust model is broken. Agents treat vendor documentation as absolute truth and don’t question it — and the humans overseeing them don’t either. He points out that the use of agentic AI is exploding and that these agents are spreading across every layer: SaaS, cloud, endpoint.
That statement captures the heart of the issue. As agents multiply, so does the supply chain surface area that can be exploited — and, as Hertz himself pointed out, today’s protections simply don’t cover this new territory. We’re talking about a problem that isn’t just technical in origin but also cultural and organizational.
What companies need to review right now
This discovery triggered an alert that goes well beyond this specific attack. It reveals a structural gap in how companies are integrating AI agents into their work environments. Most corporate security policies were still written with humans and traditional systems in mind — firewalls, antivirus, identity-based access control. Autonomous AI agents are a different category altogether, and the rules for dealing with them are still being written in real time, even as companies already run them in production.
From a practical standpoint, some reviews are urgent. First, any llms.txt file present in corporate repositories or websites needs to be audited. References to external packages, third-party domains, and resources outside the company’s perimeter should be verified for active ownership and source reliability. Second, AI agent permissions need to be reviewed with the same rigor applied to human users — principle of least privilege, activity logs, alerts for out-of-pattern behavior. Third, security teams need to start monitoring what agents are fetching and installing, not just what humans do.
On top of that, development and security teams should start treating instruction files for AI agents with the same care they give to critical configuration files. A poorly managed llms.txt can be just as dangerous as an exposed config.yml or an unprotected .env file. Security culture needs to evolve to include these new digital artifacts — and the sooner that happens, the smaller the exposure window for attacks that, like this one, exploit exactly the collective lack of attention to something new. 🔐
The good news is that the Israeli startup behind the discovery reported its findings responsibly, and the demonstration served to expose a real risk before it was exploited maliciously at scale. But the episode serves as a powerful reminder: the speed at which AI is being adopted in corporate environments still doesn’t have an equivalent in the speed at which security practices are adapting to it. And that gap is, by itself, a massive vulnerability that deserves extra attention from everyone working in tech today.
