The largest AI companies over the last month have been impacted by Agents accessing environments, credentials, and servers that they weren’t supposed to. This led to various security implications that not only impacted the AI providers, but customers and organizations using said AI providers.
The question is: if this is happening to them, what access do your Agents have that they shouldn’t?
In this blog post, you’ll learn about what an Agent Sandbox is, what makes a sandbox, and how you can start implementing sandboxing within your environment today.
What is an agent sandbox?
An agent sandbox is an isolated runtime where an AI agent executes code, browses, and calls tools without inheriting the developer's or host's credentials, cloud access, or production environments. It limits the blast radius when an agent acts autonomously.
Hey Google, what's Agent Sandboxing?: “A secure, isolated runtime environment where AI agents execute code, search the web, or make tool calls”.
This is a pretty good, yet high level description, so let’s dive into a bit more. When you’re running an Agent in say, opencode, Claude Code, or Codex, that Agent has the same exact access that you do. What that means is any cloud environment, credential, GitHub repo, storage/database, or production env you have access to, so does the Agent. Because Agents run autonomously or without much human intervention (e.g - clicking `enter` to just yes the Agent until the task is complete), this yields a problem. To minimize this, what can you call “possible attack surface”, agentic sandboxing is coming into organizations to isolate the Agents from other production-level workloads.
Let’s see where sandboxing can go wrong:
As we saw in the OpenAI Black Hat Hugging Face Incident Talk, an Agent, along with its friends/sub-agents, were able to retrieve credentials that were available to them as the credentials were accidentally exposed in a public fashion across four accounts on four third-party services.
The Agent was in a sandbox and this was still able to happen, and because of that, a very important question is now open… what the heck is a sandbox? Or rather, what actually makes a successful sandbox? Apparently it’s not just “put an Agent in its own container and hope for the best”.
A proper sandbox requires true isolation.
What Is Sandbox Isolation
OpenAI, Anthropic, and Meta (the three big AI providers that had Agents escape sandboxes over the past month) had one very important thing in common - they all used software isolation (network proxy + sandbox) instead of true hardware isolation. To fully understand what this means, let’s break down what the key differences are.
Software isolation at the software/kernel level is a separate app that runs in user space and intercepts system calls. It’s using OS rules and logic to separate programs and data. The goal is to limit direct contact with the host's kernel.
Hardware isolation uses virtualization technologies like VT-x or AMD-V to create small, watered down Linux kernels where each agentic workload runs. This creates TRUE isolation at the hardware level vs just another process running in user space (although it’s isolated, it’s still in users namespace) as it uses chip features (e.g - CPU privilege levels) to ensure that access is blocked.
To give some examples of where you’ll see each, gVisor uses software isolation and Micro VM uses hardware isolation.
Software vs hardware isolation: gVisor vs microVM
The two isolation models trade security for overhead in different ways. Here is how they compare for agent workloads:
Software isolation (gVisor)Hardware isolation (microVM)Isolation boundaryA user-space kernel intercepts system calls; workloads still share the host kernel underneath.Each workload gets its own lightweight guest kernel, enforced by CPU virtualization (VT-x or AMD-V).OverheadLow startup time and memory footprint; some system-call-heavy workloads run slower.Slightly higher startup and memory cost per sandbox, though modern microVMs boot quickly.Escape riskHigher: a flaw in the interception layer or host kernel can expose the host.Lower: an agent must break out of the guest kernel and the hypervisor to reach the host.
For untrusted, autonomous agents that execute generated code, hardware isolation is the stronger default. Software isolation can be a reasonable fit for lower-risk, high-density workloads.
Where Do Sandboxed Agents Run?
Technically speaking, you can run Agents via sandboxes anywhere that allow for sandbox tools/software. For example, if you wanted to run MicroVM on your Macbook, you can run Lima and then sandbox isolated agentic workloads. In production, however, it seems that the industry is taking advantage of the world-renowned orchestration platform that has served engineering teams for over a decade to run stateful and stateless workloads across every and any industry - Kubernetes.
K8s opens the door to run Agents in containers, implement self-healing, scale up, scale down, and implement your own APIs in the form of CRDs (Custom Resource Definitions) to ensure that you can manage your Agents exactly how you’d like, and like any other Kubernetes workload. This helps teams adopt Agents in a streamlined fashion because they’re already used to Kubernetes. That means the underlying infrastructure, CICD pipelines, security software, and monitoring/observability platforms don’t change. The thing that changes is what’s running in the container.
The Production Pattern
As you learned about in the Where Do Sandboxed Agents Run? section, the underlying architecture/system/server is going to run Kubernetes. The question then becomes “what’s running on Kubernetes?”.
You need:
- Sandbox software/tooling/platform.
- A runtime/agent framework to interact with the sandbox platform.
And as you learned about in the What Is Sandbox Isolation section, not all sandboxing is the same. If someone says they sandboxed an Agent, when in reality, it’s just running in its own Pod, how is it sandboxed? Proper `SecurityContext`? Non-root access? What Network Policies are implemented to ensure proper ingress/egress? All of the things you should be thinking about when securing a Kubernetes environment still hold true for Agent Sandboxes.
That setup can be cumbersome and often overlooked due to its complexity, so having a platform that works with all of the proper sandboxing implementations out of the box so steps aren’t skipped is a clear differentiator when implementing proper isolation.
This is where Agent Substrate and kagent comes into play.
.gif)
Kagent is the runtime that you use to programmatically, declaratively, or via the UI interact with Agents that are deployed within your production environment. The Agents can do anything from help you troubleshoot engineering issues to tasks for HR, Finance, Marketing, and everyone in-between.
Agent Substrate is the innovative sandbox technology that runs on Kubernetes. It allows you to isolate Agents via gVisor if you want software-level isolation or MicroVM if you want hardware-level isolation. You can then route all requests from kagent to the Workers that host the Actors via the `atenet-router` using agentgateway. Underneath the hood, Agent Substrate has a concept called “Actors” that are your Agents and they run in Workers, which are Pods. It allows you to not only isolate Actors, but from a performance perspective, you can run far more Actors in Workers than a standard Agent in a Pod (e.g - 50 Actors in 5 Workers or 50 Agents in 50 Pods).
Hosted sandboxes vs. Agent Substrate
If you don't want to run sandboxes yourself, hosted options such as OpenShell, E2B, Daytona, and Modal give agents an isolated environment through an API. They are a fast way to start: you call a service, get a sandbox, and run code in it. The tradeoff is that the sandbox lives outside your cluster, so identity, network policy, observability, and data residency follow the provider's model rather than the Kubernetes controls your platform team already runs.
Agent Substrate takes the opposite approach. It runs on your own Kubernetes clusters, lets you choose gVisor or microVM isolation per workload (covered above), and packs many Actors into shared Workers for higher density. Traffic flows through agentgateway, so the same policy and audit controls apply to every agent call.
For a side-by-side look at isolation, high availability, and OpenShell vs. Agent Substrate, watch Agent Runtimes on Kubernetes: isolation, HA, and OpenShell vs. Agent Substrate.
Is a sandbox enough?
No. A sandbox limits what an agent can touch on the machine it runs on, but it does not decide which models, tools, or other agents that agent is allowed to call, with whose identity, or how much it can spend. As we cover in why sandboxing your agent is not enough, the incidents above involved agents that were sandboxed and still reached credentials and services they should not have.
Pair the sandboxed runtime with a gateway for agent traffic. agentgateway sits between agents and the LLMs, MCP tools, and other agents (A2A) they reach, and applies identity, fine-grained policy, rate limits, and observability to every call. Run agents with kagent on Kubernetes, isolate them with a sandbox, and govern their traffic with agentgateway. To try the pattern hands-on, follow the run sandboxed agents with kagent and Agent Substrate lab, or read how Google Agent Substrate works.
Combining kagent and Agent Substrate, you have an effective, isolated, agent sandbox runtime for all agentic isolation needs.
Interested in learning more? Join the Agent Substrate 101 webinar.
In 30 minutes, we’ll break down what a sandbox should actually give you, where different approaches trade off security, performance, and efficiency, and why isolation becomes an infrastructure decision once agents move into production.
Frequently asked questions about agent sandboxes
What is an agent sandbox?
An agent sandbox is an isolated runtime where an AI agent executes code, browses, and calls tools without inheriting the developer's or host's credentials, cloud access, or production environments. It limits the blast radius when an agent acts autonomously.
What is the difference between software and hardware sandbox isolation?
Software isolation (for example gVisor) runs in user space and intercepts system calls using OS rules. Hardware isolation (for example a microVM) uses CPU virtualization features such as VT-x or AMD-V to give each agent workload its own lightweight kernel, which is a stronger boundary.
Is a sandbox enough to secure an AI agent?
No. A sandbox isolates execution, but agents still need scoped identity, policy on the tools and models they reach, and observability. Pair sandboxed runtimes with a gateway such as agentgateway to govern agent traffic to LLMs, MCP tools, and other agents.
Where can sandboxed agents run?
Anywhere the sandbox tooling is supported: a laptop (for example a microVM via Lima), a Kubernetes cluster, or a managed agent platform. In production, teams typically run sandboxed agents on Kubernetes so isolation, scheduling, and policy are managed declaratively.
%20(1).png)
%20a%20Bad%20Idea.png)
