At this point, most people have realized that AI agents come with a variety of risks. From attackers tricking your agent into exfiltrating data, to your agent just deciding to delete your production database for fun, there are problems that need to be solved. That’s where sandboxing comes in. The pitch, in short, is that you can take a very dangerous AI agent, put it in a sandbox, and now your problems are solved.
Unfortunately, AI agent security isn’t that simple. While properly isolating your AI agents from resources they don’t need is absolutely necessary, there are some problems with relying too heavily on sandboxing to solve your problems. This blog post discusses some of those problems, pulling on work I’ve done in this domain over the last few months.
What Is a Sandbox?
For the purposes of this blog post, a sandbox is a controlled execution environment that limits the resources that an agent can access. That can be done through containers, virtual machines, or any other technique really; the important part is that the sandbox is enforcing restrictions on the agent’s capabilities.
Importantly, sandboxes must also be deterministic. A solution that attempts to classify the danger levels of a given action and decide whether to block or allow isn’t really a sandbox. That doesn’t mean it is a bad idea (although often it is), but it doesn’t count because it doesn’t guarantee anything. Sandboxes are about guarantees.
So with that out of the way, we can discuss some of the problems.
Sandboxes That Don’t Work
The first problem that arises with sandboxes occurs when they just don’t work. They’re supposed to contain your agents to a specific set of resources, but they fail to properly accomplish that goal.
This is far more common than you might think. Sandboxes aren’t new, but very rarely in the past did we have an intelligent and motivated entity we were trying to trap inside. Even the name, “sandboxing”, is a poor fit in this context. We should instead think of sandboxes as maximum security prisons. They’re meant to lock the agent in.
Some “sandboxes” are easy to break. For example, there is a project, HermitClaw, that promised to be a sandboxed OpenClaw. It even had a little crab that walked around in a sandbox on screen. Unfortunately, the sandbox used a Python file to limit what commands were allowed, which meant the agent simply had to find a way of writing a command that wasn’t blocked. Given there are a nearly unlimited number of ways of expressing any given logical action, the agent quickly found a way to get past the blocks and access files outside the sandbox.
In other cases the sandbox escape is slightly more difficult. For example, another “safe OpenClaw” project, NanoClaw, used Docker containers to isolate the agent. However, NanoClaw also mounted the agent’s code in the container itself, including the parts of the code that enforce security restrictions. The agent therefore could modify that code to remove those restrictions, effectively freeing itself.
Some sandbox flaws are less escapes, more critical flaws that you would have hoped sandboxing would prevent. This is most clear with NVIDIA’s NemoClaw, which was advertised as bringing enterprise-grade security to OpenClaw. While there was no clear escape, it was possible for NemoClaw to open itself up from the inside, allowing any random website you visit to connect and communicate with your agent directly. Even after the NVIDIA team attempted to fix this, the same flaw persisted via a different mechanism. If NVIDIA struggles to get sandboxing right, you can imagine that a lot of sandboxes have these flaws.
Sandboxes That Are Too Big
But even if the sandbox is properly built, sandboxing still isn’t a full solution to AI agent security. The reality is that you want your agents to be able to do a lot of different things. You want them to be powerful, otherwise the utility goes away and they’re no longer worth the eye-watering amounts you’re paying for them. As a result, you often need to put far too many resources into the sandbox to make the agent effective.
For developers, this might mean a sandbox that has access to every single code repo in the organization, as well as internet access and maybe even the ability to connect to third party services such as GitHub or NPM. That is a lot. It is more or less everything an attacker could possibly want or need. Getting inside that sandbox would be the same as getting into the machine itself, because in many ways the sandbox became the full machine.
The reality is that a sandbox is only as good as it is inconvenient (from the inside), because making a sandbox inconvenient for yourself means making it inconvenient for attackers. If your agent has access to everything from inside the sandbox, you aren’t protecting anything.
Sandboxes Don’t Last Forever
The most overlooked problem with sandboxing is simply that to be useful, one day the resources your agent produces will need to leave the sandbox. For example, if your agent is writing code, that code will later need to run in production or at least on your machine. That creates an opportunity for attackers.
For example, a compromised agent might find that it lacks the access needed to steal sensitive credentials. However, it might realize it is writing code that will later run in an environment with more access, and add code that exfiltrates the credentials later. This is in some ways similar to a blind XSS attack, but for AI agents.
It doesn’t even have to be a compromised agent doing this. In some cases, an agent is simply trying to solve a problem and might find it lacks the given resources, and could tell the user to run some script or even just restart the agent for changes outside of the sandbox to take effect.
You Should Still Sandbox Your Agents
With all of that said, it’s important to understand that this isn’t a blog post about why you shouldn’t use AI agent sandboxes. You absolutely should. This is a blog post about why you need to be realistic about what your sandbox can achieve and the threats you’re still exposed to.
I also think there is room for sandbox solutions to improve some of this. Of course, better sandboxes avoid the first problem discussed entirely, but there is likely useful innovation to be had in the second and third category of problems too. That won’t ever make sandboxing into a one-stop-shop of AI agent security, but it will help contribute to making things better.