Sandboxes Are Becoming the New Security Perimeter for AI Agents

For a long time, a sandbox was where you ran something you didn’t trust. Isolate it, restrict its access, and delete it all when you’re done. AI agents are making that simple concept considerably more important.

An agent can run code, read and write files, browse the web, call APIs, and talk to production systems. With credentials and the necessary tools, an agent can perform operations that previously would have required a human sitting in front of a computer. The problem, however, is that an agent doesn’t have to be malicious to pose a risk. A prompt injection, a compromised repo, or even a poisoned file can cause an agent to do something unexpected. This makes runtime isolation even more critical, because as opposed to always assuming an agent will make the right decision, the infrastructure must assume that now and then, it won’t.

The sandbox is not a cage anymore

While traditional application security has focused on blocking unauthorized access, with AI agents that’s only half the story. An agent can have legitimate access to the filesystem, command line, or API and still use those resources in an unexpected way. That’s because agents don’t necessarily know which instructions or data they can trust. A repository might contain a malicious instruction, a webpage might try to manipulate the agent through prompt injection, or a tool might return code that the agent then executes.

Recent findings from researchers demonstrate why this distinction matters. Security researchers discovered that AI coding agents could cross security boundaries without technically escaping their sandbox. While the agent itself was contained, it created files and configurations that trusted software located outside the sandbox later executed. This redefines what a sandbox escape looks like.

The question isn’t just whether an agent can break out of the process-level isolation. We also have to consider how things outside the process-level isolation behave when they interact with or trust data generated by an agent. In other words, the perimeter has to move with the workload.

The runtime becomes the security boundary 

This is driving a push for stronger runtime isolation in agent environments. A typical container provides some level of isolation, but it still uses the host’s kernel. For workloads that run arbitrary or untrusted code, additional layers of isolation can be added by security teams.

gVisor is one solution that places an application-level kernel between the workload and the host. As opposed to letting the app inside the container interact directly with the host’s Linux kernel, gVisor intercepts system calls and implements a separate kernel API. It integrates with Docker and Kubernetes via a runsc OCI runtime.

Kata Containers uses a different approach by adding an extra layer of virtualization. Kubernetes’ Agent Sandbox project now lists gVisor and Kata Containers as methods to increase security in sandboxed workloads.

That doesn’t mean every AI agent needs to run in a VM. It does mean, however, that execution environments are becoming an integral part of security architecture. That matters especially for agents because their workloads aren’t static and can be unpredictable. While standard applications run code written by humans, agents can dynamically create code, determine which tools to use, process outside data, and choose which actions to take. 

The sandbox has to keep up

The catch is that stronger isolation can come at a cost in performance and workload density. If each agent is given its own dedicated virtual machine, running thousands or millions of transient tasks will quickly become a costly affair. Hence the interest in lighter-weight forms of isolation. Perplexity, for example, uses its new sandbox-based SPACE platform for its Computer agent, giving each task a dedicated Firecracker microVM and passing credentials into the sandbox from outside only if required. It can then destroy the sandbox once the task is complete. The company says it’s already handled millions of sandbox creations and tens of millions of reconnections with SPACE.

Tencent offers further evidence of where this is going. Tencent says it now runs millions of gVisor sandboxes per day for agentic reinforcement learning, after conducting more than 74,000 side-by-side comparisons of gVisor’s runsc runtime against conventional runc execution. This is a significant development because it shows that sandboxing doesn’t have to be a heavyweight, slow, post-hoc security feature added on top of an AI system. It can become part of the standard runtime environment.

Isolation ends where the network begins 

But what about agents that need network access? An agent with no access isn’t very useful, while an agent with full access presents obvious risks. Increasingly, this means that you can’t rely on the agent itself to secure its own network connections. Perplexity’s SPACE architecture relies on node-level network controls and keeps secrets outside the sandbox. The sandboxed agent can execute its authorised tasks without automatically being able to access every secret or network resource available in the wider infrastructure.

This is where technologies like seccomp, namespaces, and eBPF-based network monitoring and policy enforcement become relevant. Instead of a single giant security wall, runtime security allows us to track and restrict what a workload does at the OS and network levels. The agent might be allowed to run a command like curl, but the security policy can dictate which endpoints that command can reach. 

Containment is only half the battle

Agent Sandbox brings Kubernetes-style workload isolation to AI agents and other long-running workloads that execute untrusted code. Just as Kubernetes gives cloud-native teams a consistent model for deploying, scheduling, and governing workloads in isolated contexts, Agent Sandbox offers a consistent model for safely and efficiently running AI agents on Kubernetes.

The security model is clear. The model decides. The agent orchestrates. The sandbox controls what’s allowed to happen. More secure runtimes offer additional levels of isolation.

In this model, the blast radius of an agent’s poor behavior is a question not of intent but of implementation. That may make the sandbox the new perimeter for securing agents. Sandboxes can’t keep agents from behaving badly, but they can put a stop to bad behavior. For many enterprises, that’s enough. The days of simple chatbots operating behind APIs are giving way to new AI-centric architectures built on swarms of ephemeral sandboxes.