Ahead of August’s Last Call webinar, I made a bespoke addition to my wardrobe: a shiny, slightly crumpled tinfoil hat. And while I’ve never felt the need to don one before, this summer has marked a radical shift in the cybersecurity landscape, putting everyone from SOC analysts to frontier AI scientists—and even Bill Gates—a little more on edge about the state of the threat landscape. Instead of tracing the actions of human threat actors, we suddenly find ourselves trying (and often failing) to keep tabs on the machines themselves. It’s enough to make anyone want to add another defensive layer. You can’t be too careful these days.
Three incidents this summer brought that shift into focus. They involved different AI labs, different technologies, and very different paths to compromise, but they all exposed the same underlying problem: the more autonomy we give an agent, the more opportunity we create for that autonomy to be abused.
What makes these cases especially interesting to me is what wasn’t required. There was no phishing email, no employee clicking the wrong link, and in some cases no human attacker actively directing the activity at all. Instead, agents followed instructions, exercised the access they had been given, and kept moving, sometimes well beyond the boundaries anyone expected them to respect.
For MSPs and CISOs, the risk calculation is changing day to day. These aren’t hypothetical scenarios about what autonomous AI might someday be capable of. They’re examples of what can happen when agents already operating inside real environments are given access, trust, and the ability to act.
Let’s start with the most dramatic example: an AI agent that effectively breached its own environment.
The agent that breached itself
In July, Hugging Face disclosed a breach of its production infrastructure. The first post-mortem described an “autonomous agent framework” that executed thousands of actions across a swarm of short-lived sandboxes over a single weekend. At first, nobody knew whose model it was.
Days later, OpenAI said it was theirs. During an internal red-team evaluation called ExploitGym, a model identified as GPT-5.6 Sol, alongside a more capable pre-release model, was given deliberately reduced safeguards and told to find exploits. It did exactly that. The model found a vulnerability in a piece of third-party software, used it to escape its sandbox, escalated privileges, harvested credentials, and moved laterally through Hugging Face’s infrastructure for four days.
The part that sticks with me is that the agent was not “turning malicious” in some science-fiction sense. It was trying to be helpful. It pulled down a malicious dataset and kept working through the task it had been given, ultimately running more than 17,000 autonomous actions in a single weekend. That is an extraordinary amount of activity for any defender to keep up with, and it illustrates why I think focusing only on whether an AI model is behaving “safely” misses part of the problem.
From a defender’s perspective, the relevant fact pattern is much simpler: an agent with elevated permissions, internet access, code execution, and enough autonomy found a real vulnerability and operated inside a production environment long enough to resemble a persistent threat actor. At that point, whether we call it an attacker, an autonomous agent, or a red-team experiment is almost beside the point. The attack path exists either way.
Vendor documentation is now part of your attack surface
The second incident is quieter, but I would argue it is even more relevant to day-to-day MSP work because it exposes a trust problem that is going to become increasingly common as organizations race to make their environments “AI friendly.”
A security research group scanned more than 6,200 live domains belonging to defense contractors, Fortune 500 companies, and major technology vendors, looking specifically at llms.txt and llms-full.txt files. These are plain-text instruction files companies publish to help AI agents understand and navigate their sites. Across roughly 8,265 files, researchers found 120 references to code packages or domains that had never actually been registered by the vendor.
The researchers claimed the unregistered names, hosted test packages, and watched what happened. Within an hour, a Fortune 500 company’s coding agent had installed one. Over the following weeks, dozens more installs followed across Claude, OpenAI Codex, and Nous Research Hermes.
Some of those companies should know better, but that is also why the finding matters. This is not simply a case of an unsophisticated organization making an obvious mistake. The underlying trust model is broken. Agents tend to treat vendor documentation as ground truth, and frankly humans often do too. An agent reading a documentation page does not reliably distinguish between “this is information about the product” and “this is an instruction I should execute.” If its job is to complete a task, it will keep trying to complete that task.
That means documentation itself can become part of the software supply chain. A package name buried in an llms.txt file might look harmless to a human reviewer, but to an automated coding agent it can become an installation instruction. Nobody planned for a documentation page to become an install script, yet here we are.
This is the part that concerns me more than the individual incident. I have been saying some version of this on almost every AI call I have done this year: how many MSPs and organizations are already building agents across multiple models, plugging in additional LLMs, connecting SaaS platforms, and automating workflows without any central governance program in place? We are adopting the technology faster than we are defining what it should be allowed to trust.
An unregistered package sitting in a vendor’s documentation is exactly the kind of gap that ungoverned agent sprawl walks straight into. The package itself is the vulnerability. The bigger security problem is that the agent had enough trust and autonomy to act on it.
Your Claude session is a credential now
The third incident is probably the most familiar to defenders because the attack technique itself is not new at all. Anthropic warned Claude users that infostealer malware,including families such as Vidar, LummaC2, StealC, RedLine, Acreed, and Atomic Stealer on macOS, was harvesting active browser sessions and using them to log into Claude accounts.
There is no password required and no MFA prompt to defeat. The malware simply lifts the session cookie from an infected endpoint and hands the attacker a live, authenticated session.
This is the same commodity infostealer ecosystem that has been draining browser credentials, banking sessions, and SaaS logins for years. Now AI sessions have been added to the list of things worth stealing. Anthropic correctly noted that this has nothing to do with a flaw in Claude itself, but from a defender’s perspective that distinction only goes so far. Your control can be working exactly as designed and the attacker can still get what they need.
If a Claude session provides access to APIs, connected tools, proprietary data, code environments, or an active agent workflow, then that session has value well beyond a browser cookie. Whoever controls it may inherit the access behind it. We need to stop mentally categorizing AI session tokens as a minor browser artifact and start treating them the same way we treat other credentials.
What this means for MSPs and CISOs
Put the three incidents together and a broader pattern starts to emerge. Agents are becoming privileged users. Vendor content is becoming an unvetted part of the supply chain. Session tokens are behaving like credentials even though many organizations do not manage them that way. The common thread is trust.
My CyOps team called this out in our 1H 2026 ECHO Report as one of the defining patterns of the first half of the year: trusted tools becoming weapons. We saw identity infrastructure, remote-access software, legitimate IT utilities, and other sanctioned technologies abused precisely because defenders already trusted them. Attackers increasingly do not have to break through a control if they can find a way to make that control, tool, or workflow work on their behalf.
AI agents are the newest version of that problem, and potentially the fastest-moving one. An agent does not need to be socially engineered in the same way a person does. It needs an instruction it cannot distinguish from a legitimate one, access it should not necessarily have, or a session that somebody else can steal. Once those conditions exist, automation does the rest.
That is why I do not think the answer is to treat AI as some entirely new category of security problem. Most of the underlying risks are painfully familiar: excessive privilege, credential theft, supply-chain trust, weak inventory, and insufficient monitoring. AI simply changes the speed and scale at which those weaknesses can be exploited.
The practical starting point is knowing where your agents are, what identities they operate under, what they can access, and what they can actually do inside your systems. Can they install software? Execute code? Create accounts? Invoke APIs? Modify cloud infrastructure? Containing access starts with knowing what you have, and right now many organizations simply do not.
My advice for defenders
1. Treat AI session tokens like credentials. Enforce EDR on any endpoint with an active Claude, ChatGPT, Gemini, or other privileged AI browser session, and revoke those sessions the moment malware is detected on the endpoint. Do not assume a password reset is enough if the attacker already has an authenticated token.
2. Audit your own llms.txt and llms-full.txt exposure. Check whether public-facing documentation references unregistered packages or domains that an agent could “helpfully” install, and add those files to your external attack-surface scope. Apparently documentation files are part of attack-surface management now too. Welcome to 2026.
3. Require human review before agents execute installs from vendor documentation. Coding agents should not automatically trust dependencies discovered in scraped documentation. Reserve that trust for pinned, reviewed dependency manifests and approved repositories. This is standard software supply-chain hygiene, except now the thing reading the documentation is capable of acting on it immediately.
4. Verify that guardrails inspect decoded content, not just surface text. If any part of the AI stack decrypts, decodes, renders, or otherwise transforms content, confirm that the safety layer runs after that step as well. Otherwise you may be inspecting the wrapper while implicitly trusting whatever appears once the agent opens it.
5. Put a real kill switch on autonomous agent testing. Sandbox teardown should not be something the agent itself can recover from or work around. If you are testing systems capable of code execution or autonomous exploitation, design containment around the assumption that something may eventually attempt persistence. Seventeen thousand autonomous actions is a lot of opportunities for one of them to surprise you.
None of these incidents required us to invent some entirely new attack path. We already understand credential theft, software supply-chain attacks, excessive privilege, and the danger of implicitly trusting legitimate tools. AI agents do not replace those problems, they just accelerate them.
Defenders should focus on what the agent is trusted to do, what happens if that trust is abused, how quickly you would see it, and whether you can revoke its access before an efficient piece of automation becomes an equally efficient incident.
I’m not saying we’re in full HAL 9000 territory … yet. But keep the tinfoil hat close anyway.