How To Use Self-Hosted AI Agent Sandboxes on Kubernetes with Edera

AI agents are quickly outgrowing the execution environments we originally designed for them. As highlighted in Manveer Chawla’s Substack post, the major cloud providers (AWS, Azure, and GCP) have “all quietly migrated their control planes away from runc toward hardware-enforced isolation”. The agent that simply runs a generated Python snippet has very different requirements from one that installs arbitrary dependencies, compiles software, browses the internet, inspects source code, runs fuzzers, launches services, and continues working autonomously for hours. The industry has responded with a new class of infrastructure - various sandboxes purpose-built for agents. E2B, Blaxel, and the Kubernetes SIGs agent-sandbox project are all great expressions of the same idea that you should give an agent somewhere isolated and stateful to work, while making that environment disposable enough that we can safely let the agent do things we would never allow on a normal application server. Kubernetes itself is increasingly becoming part of this story. The Kubernetes SIGs project describes its Sandbox resource as a stateful, singleton, pod-backed workload intended specifically for AI agent runtimes and similar workloads.

Where Edera Fits: The Sandbox as Stateful Computation

One particularly interesting open-source project that stands-out in this space that makes the problem concrete is Agent-Sandbox. It takes the Kubernetes foundation and puts a product-oriented interface in front of it. Instead of asking your app developer (or agent) to understand CRDs, pods, namespaces and controllers, Agent-Sandbox exposes a REST API and MCP server for creating, using and deleting sandboxes. It is explicitly designed as an open-source, self-hosted alternative to managed sandbox platforms. That distinction matters. Kubernetes is an excellent substrate for running workloads, but it is not necessarily the interface we want to expose to an AI workload. The application wants to say “give me an isolated environment, let me execute this command, preserve the state, and bring it back later.” It does not want to construct some complex Kubernetes object graph to express that intent. Agent-Sandbox is an attempt to bridge precisely this chasm.

That gap is also where Edera becomes interesting. Edera is not another agent framework and it is not trying to replace Kubernetes as the orchestration layer. Instead, it provides a runtime with capabilities that become increasingly valuable once an agent's execution environment is treated as a first-class, stateful object. Snapshotting, restoring, forking, object capabilities and workload identity give us primitives that are difficult to express cleanly through the standard Kubernetes abstraction. The important shift is that a sandbox no longer has to mean starting a fresh container. A sandbox can just as easily become a piece of live computational state. It’s something you could pause, resume, snapshot, clone into multiple trajectories, give narrowly scoped capabilities to, and eventually discard. Kubernetes gives us a powerful way to schedule and operate that workload, whereas Edera gives users a richer execution model underneath it.

Why Putting the Agent in a VM No Longer Settles Isolation

This is especially relevant because the traditional answer to agent isolation (“go put that agent into a VM”) is coming under serious pressure. A recent Trail of Bits experiment gave GPT-5.6-Cyber the task of escaping a QEMU/KVM VM. The agent escaped 3 times, using a combination of known CVEs, bugs that had not yet reached the distribution's packages, and ultimately previously unknown vulnerabilities. The agent worked autonomously for roughly 12 hours, researching, even writing PoC code, backtracking from failed approaches before chaining different vulnerabilities together. 

That result should not be read as VMs are no longer useful or as though every VM provides the same security boundary. A VM is not a security property by itself, but rather the security properties depend on the entire virtualization stack and its implementation. The Trail of Bits experiment targeted a particular QEMU/KVM configuration, while Edera uses a different virtualization stack based on Xen (as well as the option for KVM with no QEMU). That means the relevant attack surface and failure modes are different, but it does not make Xen immune to the underlying problem where a sufficiently capable agent can investigate and attack vulnerabilities in whatever software sits between itself and the host. Trail of Bits also found Firecracker to be a substantially harder target, but even there the experiment caused host kernel crashes.

The broader lesson is therefore not that one virtualization technology is deemed safe and another is unsafe. It is that isolation has to be evaluated as a property of the complete design, including the hypervisor, guest kernel, device emulation, networking stack, host kernel, available credentials, other exposed services, and the strength of the boundary relative to what the agent is actually permitted to access. An autonomous agent can literally spend hours investigating that surface in a way that a human developer simply could never dream of. That makes the ability to preserve and manipulate execution state increasingly valuable as snapshotting gives us a reproducible point in time, while forking lets us turn that state into multiple independent execution paths. These are primarily operational and efficiency primitives, but they also give us useful tools for investigating, containing and recovering from unpredictable agent behaviour.

Kubernetes Wasn't Built to Branch Running State

There is another problem hiding underneath all of this. Kubernetes was not originally designed around the idea that application developers would manipulate process state. Kubernetes is exceptionally good at declaring what should be running. It is much less opinionated about preserving the exact execution state of something that is already running and then turning that state into multiple independent continuations. The CRI does now expose checkpoint and restore-related RPCs, but these are runtime-facing interfaces rather than a general-purpose application abstraction. Kubernetes' own CRI documentation explicitly describes CRI as an interface for kubelet-to-runtime interaction and node-level troubleshooting, rather than a general-purpose container runtime API. The checkpointing functionality was introduced as minimal checkpointing support, and the Kubernetes enhancement that introduced it was explicitly framed around forensic container checkpointing.

That last point is really important for our AI workloads. The thing we want to checkpoint is not necessarily a container for forensic analysis. We want to checkpoint a useful piece of computation because we intend to resume it, duplicate it, branch it, evaluate the branches, and potentially merge the results into an agent workflow. Consider an agent that has spent 20 minutes installing dependencies, downloading a repository, building the project and understanding its architecture. Starting 10 new containers and repeating that work is wasteful. Starting from a snapshot of the already-initialised environment and exploring 10 divergent trajectories is a fundamentally different computational model. The same applies to agent evaluations, reinforcement learning rollouts, debugging, long-running coding tasks and workflows where an agent reaches a decision point and needs to explore several possible futures. We explore this further in our Project Lunchbox announcement.

The Real Question Is Where the Execution Boundary Lives

This is one reason technologies such as gVisor have attracted so much interest in AI infrastructure. The value is not only that they provide a stronger than a standard container boundary, but they also manage to successfully create opportunities around workload isolation and state management. The industry has increasingly demonstrated that checkpoint and restoration capabilities can be made into a managed platform capability. What remains surprisingly awkward is taking these capabilities and composing them yourself on Kubernetes, on infrastructure that you actually control. 

There is a useful distinction here between managed Kubernetes and a self-hosted execution plane. A managed Kubernetes offering, such as the model Snowflake is pursuing, can remove a significant amount of operational burden while still giving customers a Kubernetes-based environment. This type of offering is rightfully compelling for many teams. But there are workloads where the important requirement is not simply “give me Kubernetes”. Instead, many orgs will ask to keep the computation, the data, its credentials, and the network connectivity with the infrastructure and trust boundaries we control. For those workloads, moving the app onto a managed Kubernetes service may still introduce constraints around data locality, network access, compliance, tenancy and possibly failed internal security policies.

This is precisely where a self-hosted sandbox runtime becomes interesting. Rather than sending sensitive source code, customer data or agent execution to an external sandbox provider, or moving the entire workload onto infrastructure managed by someone else entirely, you can bring the sandbox abstractions to the infrastructure where the data already lives. The point is not that self-hosted is necessarily always better than having managed infrastructure, we instead need to be conscious that many enterprises need to be able to choose where the execution boundary lives without giving up the DevEx of a managed sandbox/ Edera provides the runtime primitives that make all this possible. Your org can still retain control of the underlying infrastructure while exposing a simple, sandbox-oriented interface to the application.

This matters because managed sandbox platforms solve a very real problem, and they are increasingly becoming a capability offered directly by the major cloud providers. While E2B and Daytona are also popular options, many teams end up choosing sandboxing capabilities that are already integrated into their existing cloud provider platforms, such as GKE Sandbox or AWS AgentCore. For those teams, this could well be the right answer. The cloud provider manages the infrastructure and security boundary, so devs enjoy a relatively simple interface for running untrusted agent workloads. 

But there is an important trade-off. The closer the sandbox is to the app and its data, the more useful it can be, and the more expensive it becomes to control where that sandbox actually runs. Platform teams may need agents to access proprietary source code, internal services, customer data or regulated information without moving that workload into a separate managed environment or outside an existing network and security boundary. Data residency, privacy, regulatory compliance requirements, internal security policy and network architecture can all make “just use the cloud provider’s sandbox” statement less straightforward than it first sounded.

Building the Agent-Sandbox Layer on Edera

That is the fundamental objective of building an Agent-Sandbox layer on top of the existing Edera offering. The goal was never to make developers learn Edera internals. It is to make Edera's capabilities available through the abstraction developers already understand. Someone building an AI application should be able to create a sandbox, execute commands, suspend it, resume it later, take a snapshot, or branch it without knowing which runtime is underneath. Kubernetes remains the control plane for deploying and operating the system. Edera becomes the runtime layer that gives those sandboxes richer semantics. The SDK becomes the final layer that turns those primitives into something an agent developer can actually use.

What the API Looks Like: Create, Suspend, Snapshot, Fork

At the simplest level, the interface can look remarkably similar to the APIs people already use for agent sandboxes. For example:

from edera_runtime import Sandbox

sandbox = Sandbox.create()
sandbox.commands.run("pip install -r requirements.txt && python main.py &")

sandbox.suspend()
sid = sandbox.sandbox_id

# Later
resumed = Sandbox.resume(sid)
resumed.commands.run("cat /home/sandbox/output.txt")

The important part of this API is not actually the syntax but rather the model behind that syntax. The Sandbox.create() function gives the user an isolated execution environment, the commands operate against that environment, and suspension preserves useful state. The resume() function turns that state back into an active computation. The app at no point needs to know whether the underlying implementation is a Kubernetes Pod, a microVM, a CRI runtime or something else. It gets a stable abstraction around a unit of computation.

Once snapshots and forking are available, however, the abstraction becomes considerably more powerful:

from edera_runtime import Sandbox, Capability

sandbox = Sandbox.create()
sandbox.commands.run("pip install -r requirements.txt && python main.py &")

snapshot = sandbox.snapshot(name="agent-minimal")

instance = snapshot.start()
instance.exec(command="agent.py --until-decision-point")

# Fork the live state into 10 divergent trajectories
snapshot, forks = instance.fork(count=10)
for fork in forks:
    cap = Capability("talk-to-github")
    fork.exec(command="agent.py --explore-branch", capability=cap)

Here, the sandbox is no longer just a secure shell. It becomes a branching execution environment. An agent can perform an expensive initialisation once, snapshot the results, and then create many trajectories from that common state. Each trajectory can receive different capabilities. One branch might be allowed to communicate with GitHub; another might have access to a database; another might have no network access at all. The sandbox's identity and permissions become part of the computational model rather than a collection of Kubernetes configuration details.

This is where object capabilities become particularly interesting. A common pattern in agent security is to give an agent broad access to a runtime and then try to constrain what it can do through increasingly elaborate policy. A capability-oriented approach starts from the opposite direction where the agent has no authority until a specific capability is handed to it. That makes it possible to express something closer to: 

“This particular branch may talk to this particular service for this particular purpose” 

rather than: 

“This Pod has network access”

Here, the sandbox is no longer just a secure shell. It becomes a branching execution environment. An agent can perform an expensive initialisation once, snapshot the results, and then create many trajectories from that common state. Each trajectory can receive different capabilities. One branch might be allowed to communicate with GitHub; another might have access to a database; another might have no network access at all. The sandbox's identity and permissions become part of the computational model rather than a collection of Kubernetes configuration details.

This is where object capabilities become particularly interesting. A common pattern in agent security is to give an agent broad access to a runtime and then try to constrain what it can do through increasingly elaborate policy. A capability-oriented approach starts from the opposite direction where the agent has no authority until a specific capability is handed to it. That makes it possible to express something closer to: 

“This particular branch may talk to this particular service for this particular purpose” 

rather than: 

“This Pod has network access”

Combined with SPIFFE/SPIRE identity, Edera can establish an identity layer beneath the agent abstraction, while the sandbox API exposes a much simpler interface to the application. There is a useful architectural precedent for this separation in the broader agent-security ecosystem. The Nono approach, for example, positions policy controls above the underlying secure runtime rather than making policy inseparable from a particular sandbox implementation. The underlying runtime can be Kata, Firecracker or runC, while the policy layer controls what the agent is permitted to do. That is a compelling design principle because it separates what the workload is allowed to do from how is this workload actually isolated? Edera fits naturally into the latter category while also providing primitives such as identity, capabilities, snapshotting and forking that, when combined, make the policy layer substantially more expressive.

A Thin Kubernetes Layer and a Python SDK

The Kubernetes layer is therefore deliberately thin. At the runtime layer, Edera implements the hard primitives of snapshotting, restoring, forking, object capabilities and workload identity. A CRI integration or shim can easily react to annotations on Kubernetes Pods and connect those workloads to the Edera runtime. Above that, Kubernetes resources are able to express the concepts that matter to users like Sandbox resources, a SandboxTemplate, or a job-like resource that could simply ask for a particular runtime and capability configuration. The controller translates those resources into the appropriate Pods and annotations, while another lightweight component exposes RPCs for operations that do not fit naturally into the existing CRI lifecycle.

The final layer was always going to be the SDK. This is where we meet the developer where they already are. Kubernetes is the infrastructure layer, but Python is where many AI applications are actually being built. Devs should not have to learn Kubernetes controllers simply to create an isolated execution environment. The SDK in turn exposes Sandbox.create(), snapshot(), resume() and fork() while handling the Kubernetes machinery underneath. It can also provide compatibility with existing sandbox-oriented application patterns, making it possible for teams already building against E2B-style interfaces to move the execution plane onto infrastructure they control.

Kubernetes Describes the Sandbox; Edera Runs It Anywhere

That is also why the additional distinction between Kubernetes SIGs-backed Agent-Sandbox and the Edera-backed Agent-Sandbox really matters here. The SIGs project is an important Kubernetes-native building block that provides a Sandbox CRD and a controller-oriented abstraction for stateful, singleton workloads, with a Python SDK available for programmatic interaction. The Edera-backed approach is complementary rather than competitive at that level. The Kubernetes API describes the sandbox, but Edera provides the execution semantics underneath it. 

In other words, Kubernetes answers the question: 

“Where and under what desired configuration should this sandbox exist?” 

While Edera answers the follow-up concern: 

“What can we do with the state of this running sandbox?”

There is also a practical reason to keep these layers separate, and that’s portability. Some existing approaches to snapshot and restore depend heavily on particular cloud environments or virtualization stacks. That can make a feature look portable at the API layer while quietly coupling the implementation to a specific provider. Edera's goal is simply to make the underlying primitives available across standard Kubernetes infrastructure. The sandbox API should therefore be able to remain stable even as the runtime underneath it evolves. If a customer runs Kubernetes on their own hardware, in a private cloud or in a public cloud, the application should not need to change merely because the infrastructure changed.

What Self-Hosting Actually Unlocks

The self-hosted aspect is a lot more than a deployment preference. It changes what kinds of AI applications become possible. Imagine an enterprise agent that needs to process confidential source code, customer documents or internal datasets. The agent needs the freedom to install packages, execute arbitrary code and explore a problem, but the company cannot allow that data to leave its environment. A managed sandbox API can provide excellent isolation, but it cannot remove the data-residency requirement. A Kubernetes-native sandbox backed by Edera lets the organisation keep the entire execution path inside infrastructure it already controls, while still giving developers a high-level experience that looks much closer to a managed service.

This is already a real operational pattern rather than a purely theoretical one. Agent-Sandbox was created in response to internal AI teams needing isolated environments for data processing and AI workloads, initially using managed sandbox infrastructure and then running into network, security and compliance constraints around sending data outside of your org. The resulting open-source project is designed around the same basic operational requirements for string per-agent or per-user isolation, state persistence, multi-tenancy as well as a simple lifecycle API. Its published architecture explicitly puts the API/MCP layer above Kubernetes and the individual sandbox environments beneath it.

The interesting opportunity is to make the underlying runtime substantially more capable without forcing those app development teams to understand the complexity. The agent developer does not necessarily care that the runtime supports Copy-On-Write (COW) forking. They care that they can create 10 sessions from the same state without paying 10 times for initialisation. They don’t necessarily even care about SPIFFE. They should instead care that each sandbox has a strong identity that can be used to authorise access. Again, they shouldn’t really care about any of the checkpoint/restore internals. They absolutely should care that an agent can sleep for 6 hours and wake up exactly where it left off. The job of this layer is to turn powerful infrastructure primitives into rather straightforward, simple abstractions.

Security Is a Byproduct, Not the Whole Pitch

That leads to a different way of thinking about the security story. Security is obviously fundamental, particularly given what we are learning about capable agents, but it does not have to be the entire product pitch. Snapshotting is useful because it makes security investigations easier, but it is also useful because it makes agents faster. Forking is useful because it limits the blast radius of an agent experiment, but it is also useful because it enables parallel exploration. Identity is useful because it controls access, but it is also useful because it lets distributed agent workflows reliably identify their workloads. Least privilege is useful because agents can be dangerous, but it is also useful because it gives developers a precise model for what each branch of an agent workflow is allowed to access.

That combination is the real value of Edera in an agent-sandbox architecture. We do not have to choose between a better user experience and stronger isolation. The same runtime primitives can provide both. Kubernetes provides the ecosystem, scheduling and operational model that enterprises already understand. The sandbox API provides the developer experience that AI applications actually need. And Edera supplies the execution semantics that neither layer naturally provides on its own.

Three Layers, Three Responsibilities

The end result is a stack with three distinct responsibilities. 

1. At the bottom is the Edera runtime, providing isolation, snapshotting, restoring, COW forking, capabilities and identity. 
2. In the middle is Kubernetes, providing the resource model, scheduling, tenancy and operational integration required to run the system on infrastructure the customer controls. 
3. At the top is the Agent-Sandbox API and SDK, providing a simple interface for humans and AI agents to create, manipulate and destroy execution environments without touching kubectl. 

This combined architecture means we can add richer control-plane functionality over time, such as dynamic templates, resource reservations, agent lifecycle management and event broadcasting, without having to reinvent the execution layer underneath.

For AI infrastructure, this is an increasingly important boundary. The industry has spent years making containers easy to schedule and years more making managed sandboxes easy to consume. The next step is making stateful, branchable and capability-aware execution environments easy to build on infrastructure that enterprises already own. As agents become more autonomous, the ability to start a clean environment is only the beginning. We need to be able to preserve state, reproduce it, branch it, constrain it, identify it and destroy it, all without making every AI dev team an overnight expert in Kubernetes and virtualization.

Edera gives us the primitives to do that. Agent-Sandbox gives us the interface. Kubernetes gives us the infrastructure. Put those three layers together, and a sandbox stops being just a place where an agent runs code. It becomes a programmable unit of computation: isolated enough to trust, stateful enough to be useful, portable enough to run on your own infrastructure, and simple enough that an AI developer can create one with a few lines of Python.

If you’d like to learn more about sandboxing AI agents with Agent Sandbox and Edera, check out our official, up-to-date documentation: https://docs.edera.dev/guides/deployment/agent-sandbox/