At BSides Greenville last weekend, I had a great conversation with a colleague about the difficulty of detecting new skills, plugins, and context being deployed by non-privileged users in our clients’ environments. Traditional web-filtering or cloud-security tools can identify connections to services such as GitHub Copilot, but recognizing an approved service does not reveal everything the service has been instructed to do by text files. The problem gets even harder when automated AI agents leverage these text artifacts to carry out downstream actions without a human-in-the-loop to review the action for potential consequences. It was only two days into this week that I came across an article in Ars Technica describing a demonstrated attack path that takes advantage of this type of chain of events (https://arstechnica.com/security/2026/08/claude-codex-and-hermes-installed-unowned-code-inside-corporate-networks/)

The described attack is a little convoluted at first reading. The first interesting thing to understand about the article is the growing role of llms.txt files. You can read more about them here (https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt). These are markdown files typically published in a website’s root directory or within a path. These Markdown files provide AI agents with a concise guide to a website and links to relevant documentation. The chain of trust can break when that material contains an installation command naming a package that has never been registered, or a link to an expired, misspelled, or otherwise unclaimed domain. Researchers demonstrated that they could claim some of these names and observe corporate AI agents reaching their test infrastructure. The danger was not a conventional website redirection, but an authorized agent treating documentation from a trusted source as instructions, following the reference, and, in some cases, executing the associated installation command.

This brings me back to my conversation last weekend at BSides: what’s new for us as policy-governed innovators and what’s just a new context for previously established controls? Where supported, installation policies should require a verifiable record of origin tied to a previously approved publisher, source repository, and build workflow. Security teams must establish clear governance boundaries for what an agent can do, including requirements for permission to access sensitive files, credentials, and infrastructure, as well as to install new packages.

For detection, security teams should 1) inventory and monitor the user-, project-, and application-level locations where agents obtain skills, plugins, and configuration instructions; 2) examine newly introduced instructional content for package-installation commands, credential access, or changes to agent permissions; and 3) correlate those changes with subsequent agent-launched processes and network connections. Agent-specific activity logs can also reveal the originating instruction and approval history, which is a context that ordinary endpoint monitoring may miss. The technology is new, but the response is familiar: understand the trust boundary, limit authority, verify sources, and preserve enough evidence to determine what happened.