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.
Defining An Agent Sandboxing
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 it’s 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 it’s 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 ios blocked.
To give some examples of where you’ll see each, gVisor uses software isolation and Micro VM uses hardware isolation.
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 Define 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 hard-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).
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.
%20(1).png)
%20a%20Bad%20Idea.png)
