Vulnerabilities targeting tools that give models access to files, software packages, or code execution were published this week. The recommendation accompanying these publications is simple and rarely followed: inventory all services that give this type of access to a model, apply the patches, and seriously isolate your agent experiments.
We have been documenting attacks targeting agents for months. They are changing target, and the shift is instructive.
The shift in target
Until now, the attacks we have covered targeted the model or its context: invisible text in an email, an injection via persistent memory, reusable encrypted reasoning blocks.
These new vulnerabilities target something else: the tools surrounding the model. The server that gives it access to your files, the package manager it uses, the environment in which it executes code.
This is a logical shift. These layers are often installed quickly, in an experimentation context, with generous permissions because restricting takes work. They are the weak link.
Why this is more serious than it looks
An injection into the model's context produces a wrong answer. A vulnerability in the execution tool produces code execution on your machine.
The difference is one of kind. In the first case, the attacker manipulates what the model says. In the second, they use the agent as an entry point into your infrastructure.
And these environments are often connected to sensitive things: your code repositories, your access credentials, your databases. That is what makes them useful, and it is exactly what makes them interesting to an attacker.
Here is the pattern that repeats across all organisations. Someone installs a tool to test an idea, with broad permissions because it is just a trial. The trial works, it gets used a bit more, and people forget it is running. Six months later, an experimental component with full access runs permanently without being monitored. This is not an AI problem; it is a classic of computer security. AI makes it worse because these tools install in minutes.
What to do
Four measures, in order of effectiveness.
Inventory. List all services that give a model access to files, packages, or execution. Most organisations discover things they had forgotten in the process.
Apply the patches. The advice sounds trivial and remains the most effective. We documented with a campaign targeting 460 systems that attacks massively exploit already-patched flaws.
Isolate for real. An execution environment must be genuinely separate: no unnecessary network access, no credentials from the main system, minimal permissions. We showed in our article on security testing that software isolation is never perfect. All the more reason to stack it.
Monitor network egress. A compromised agent has to send what it has stolen somewhere. That is often the easiest signal to spot.
What to take away
This series of incidents confirms what we have been writing since the start of the summer: every capability that makes an agent useful widens its attack surface, and there is no powerful version without a surface.
What changes with these vulnerabilities is that the target is no longer the system's intelligence but the plumbing around it. That is rather good news on one point: we know how to secure plumbing. The techniques of isolation, least privilege, and monitoring have existed for decades.
What is missing is therefore not know-how, but treating these installations as production rather than as trials. And that requires knowing what is running, which is precisely the starting point.