Two Years Building “The Sandbox” Everyone Suddenly Needs For AI

A Journey Through Time at Edera

The OpenClaw and Moltbot incidents made it clear: autonomous code execution without strong sandbox isolation isn't a theoretical risk. It's an active one.

Open your feed now and you'll find a new sandbox announcement every few hours – another AI agent isolation project, another weekend prototype. The conversation has shifted almost overnight from "do we need isolation?" to "how do we get it yesterday?"

Suddenly, everyone needs what we've been building. (...and that feels good; it feels like validation.)

We’ve been deep in this problem for two years. Not because we saw this week coming, but because the problem of untrusted code on shared compute has always demanded a better answer than what containers provide. Here’s what that looks like when you actually do the hard work.

Why We Bet on Container Sandbox Isolation Before AI Agents

The AI agent explosion is new. The fundamental problem isn't. Before anyone was talking about isolating Claude Code, our CTO Alex Zenla was solving this for IoT infrastructure – heating systems, building controllers, the kind of equipment where a security failure puts human health at risk. These systems ran on containers, and the security story was, to put it charitably, terrible. Alex needed production-grade isolation: not detection, not dashboards, but actual architectural separation of workloads.

Here's what you need to understand about building a production-grade container sandbox in 2023: the industry had accepted that containers were "good enough" for everything except the most paranoid workloads. If you wanted stronger isolation, the answer was supposed to be Kata Containers – an open source project that wraps pods in lightweight VMs.

The problems show up when you try to operate it across a real fleet. In practice, teams run into three systemic issues:

• Operational visibility breaks down: Kubernetes thinks a pod is healthy while the workload inside the VM is struggling. CPU and memory pressure are obscured behind abstraction layers, and alerts fire too late — or not at all.
• Debugging becomes archaeology: Logs and signals are scattered across runtimes, guests, and hosts. A single failure can originate in multiple places, and identifying the root cause requires deep, non-obvious expertise in Kata’s internals.
  
• Kubernetes health signals no longer match reality: Nodes require special configuration, and routine updates that work fine for standard pods can break isolated workloads in unpredictable ways. Teams end up blaming “cloud noise” because the real failure mode is invisible.
  

The deeper issue is that Kata tries to make a VM look like just another container, but it’s only one piece of the puzzle. That disguise creates complexity: special runtime layers, fragmented visibility, and mixed behavior on the same node. Kubernetes wasn't designed for this, and it shows.

A New Approach to Production-Grade Container Isolation

Edera takes a different approach. Instead of disguising VMs as containers, we're explicit about the boundary. 

Each workload runs in what we call a zone – its own isolated environment with its own kernel. Your monitoring tools see exactly what's happening inside your zone, not a blurred average across the whole node. When something goes wrong, the failure is contained and the cause is visible.

Deploying Edera is boring on purpose. Change your AMI, add a few lines of YAML, and your existing workflows keep working. Your OCI images run unmodified. We built for operators who need to run this across an entire fleet, not just demo it on a single node.

Most of our founding team came from Chainguard, where we'd worked on the container image supply chain security problem. We founded Edera because we knew the next unsolved problem – runtime isolation – was deeper in the stack, harder, and completely unaddressed at production scale. We've spent two years and thousands of engineering hours making isolation actually work: easy to deploy, easy to observe, and fast enough that you won't notice the difference. CPU runs 0.9% slower than bare Docker. Memory and syscall performance are actually slightly faster in our benchmarks.

What Two Years of Engineering Real Sandbox Isolation Looks Like

So why did it take two years? Because making isolation actually work in production isn't a weekend project.

The thing about contrarian technical bets is that the universe pushes back on you for making them. Every integration point becomes a flaming chainsaw to juggle. Every assumption the cloud native ecosystem makes about your architecture is wrong. And you have to fix all of it yourself.

Here’s a taste. Getting Edera running on AWS EKS required us to identify a regression in an upstream Linux kernel commit that had broken ENA support in a way that was invisible to everyone running standard containers but catastrophic for our architecture. We fixed it at the kernel level. That’s one example. There are hundreds.

So what does the end user experience look like after thousands of hours of that work?

One line of Kubernetes YAML. Your OCI images run unmodified. Your existing workflows don’t change. You just get actual isolation. CPU performance is within 1% of bare metal. Memory operations run at native speeds. Syscall throughput averages 3% faster due to the paravirtualized architecture.

That simplicity on the surface is the product of thousands of hours of the hardest systems engineering our team has ever done.

What Strong Sandbox Isolation Unlocks for AI and Kubernetes

Here's something that might surprise you: security isn't our end goal. It's the foundation that makes everything else possible.

Most security operates reactively: dashboards that show you problems, policy engines that block known-bad patterns, incident response when things go wrong. Edera operates proactively: workloads are isolated by default, and breaches are contained by design.

When isolation is a property of the infrastructure rather than a layer bolted on top, something shifts. Developers deploy whatever they want – new models, experimental agents, third-party tools – and it's automatically sandboxed. You test faster, prototype anything, experiment with untrusted code without security review cycles. Security teams stop seeing Kubernetes as the weakest link. They start saying yes.

The question isn’t whether you’ll be breached. It’s whether that breach matters. When each pod runs in its own production-grade sandbox (i.e. Edera Zone) with its own kernel, a kernel CVE compromises one workload, not the node. Your rogue AI agent can’t reach your Personally Identifiable Information (PII). Your popped pod can’t exfiltrate model weights.

This isn’t a policy that can be misconfigured or an agent that can be evaded. It’s the geometry of the system.

Come Talk to Us

The market is finally arriving at the question we started with: can you make isolation technology performant, compatible, and secure? If you're wrestling with how to isolate AI agent workloads, running untrusted code in production, or building secure multi-tenant platforms – come talk to us. We've probably already hit the wall you're about to hit. More importantly, we can show you what's on the other side.

FAQ

Why aren’t containers enough to safely run AI agents?

Containers share a kernel, which means a single exploit or kernel vulnerability can compromise every workload on a node, including AI agents executing untrusted code.

What makes a sandbox “production-grade”?

A production-grade sandbox provides true kernel isolation, full observability, predictable performance, and operational simplicity at fleet scale—not just demo-level containment.

How is Edera different from Kata Containers?

Instead of disguising VMs as containers, Edera makes isolation explicit, giving each workload its own kernel while preserving Kubernetes visibility and operator workflows.

‍