What Comes After Containers: Building the Compute Substrate for the AI Era

Trail of Bits gave an AI agent twelve hours against a virtual machine and told it to get out. It escaped three separate times, the last one through a chain of bugs nobody had reported yet. Another research team largely from the UK AI Security Institute found that many frontier models are able to reliably escape from standard containers. 

Everyone already agrees that containment matters. That's not what gets us out of bed at Edera. The interesting part is that the engineering which fixes containment and the engineering which makes AI infrastructure fast are the same engineering – and almost nobody shipping software today has noticed.

What a Real Isolation Boundary Buys You: Fork, Snapshot, Restore

Picture an agent mid-task: a repo cloned, dependencies installed, a model warm in memory, a few hundred megabytes of state that took ninety seconds to assemble. The obviously correct thing for the machine to do is fork that state four ways in milliseconds, let each branch try something different, keep the one that works, and throw the rest away for almost nothing. When it goes idle, it should snapshot to disk instead of burning memory overnight, then come back warm instead of rebuilding itself from scratch.

None of that is exotic — it's roughly what people have wanted since fork(). It's hard because a process isn't self-contained; it's a bundle of handles reaching into a shared global state, which is why you can't copy it faithfully or write it to disk and get it back. Containers made this worse, not better — same shared state, nicer packaging.

Isolation is what makes forking, snapshotting, and restore sound operations rather than dangerous ones. A unit of execution with a genuinely crisp boundary is one you can copy exactly, freeze, move, and hand a device to without handing over the rest of the box. Security and capability aren't two things we trade against each other here — they're one property, viewed from two angles.

Which is why we've been aggressive about one specific thing: isolation has to be the cheapest primitive in the system, not merely an adequate one. Expensive boundaries get rationed — people batch untrusted work together, reuse them across tenants, and the whole model quietly becomes decoration. Cheap boundaries invert that. You start using one per action, per rollout, per request, and the architectural workarounds people built to avoid paying for isolation stop being necessary at all.

One Compute Substrate, Two Buyers: AI Safety and RL Throughput

One kind of buyer worries about safety — an agent writing and running its own code, and a need to know what happens when it does something nobody predicted. Another worries about throughput and cost — RL or eval harnesses at scale, needing thousands of divergent branches off expensive warm state, spun up and discarded continuously, without rebuilding the same setup a hundred times over.

Most companies here have ended up picking one of those buyers. We haven't had to, because the same crisp boundary that contains a hostile agent is exactly what makes a fork exact and a snapshot complete. It's the actual shape of the problem, not a coincidence we're exploiting — and it means the engineering compounds in both directions at once: every hour spent making a boundary cheaper is a performance win and a security win in the same commit.

Introducing Project Lunchbox: A Kubernetes-Native Agent Runtime

This is where the strategy stops being an argument and becomes a runtime. In our next release, we are cutting Edera's agent and reinforcement-learning execution substrate – a Kubernetes-native runtime for agent and Reinforcement Learning (RL) infrastructure on clusters you own, not a sandbox cloud you rent. Internally, it’s referred to as Project Lunchbox.  

Lunchbox exposes the three primitives this post is built on — hardware isolation, snapshotting, and copy-on-write forking — as first-class Kubernetes objects. The objects Sandbox, Snapshot, Fork, and Capability are all backed by a developer-friendly Python SDK. The coding agent gets a boundary a prompt injection physically cannot widen, because egress is mediated below the guest. An RL job gets a live, warm environment forked in milliseconds, sharing memory copy-on-write, so branching a rollout costs almost nothing and every branch starts bit-identical and contamination-free. Both arrive through a RuntimeClass, not a re-platforming project – the same primitive that contains a hostile agent is what makes a rollout cheap to fork, and now you can install it on your own cluster.

Where AI Agent Infrastructure Has to Live: On Clusters You Own

None of this matters if reaching it means rewriting an application. Kubernetes stays the interface – pod specs, images, and pipelines keep working, and the deeper machinery shows up as resources a platform team adopts on an ordinary Tuesday rather than a migration project. It also has to run wherever the workload does: your own hardware, your own cluster, your own attestation chain, not just a capability you rent by the second.

To learn more about Project Lunchbox, read on, or reach out to us directly.

FAQ

What is Project Lunchbox?

Project Lunchbox is Edera's Kubernetes-native runtime for AI agent and reinforcement-learning workloads on clusters you own. It exposes hardware isolation, snapshotting, and copy-on-write forking as first-class Kubernetes objects (Sandbox, Snapshot, Fork, Capability), backed by a Python SDK and delivered through a RuntimeClass.

Why does isolation make forking and snapshotting cheaper?

A unit of execution with a crisp boundary can be copied exactly, frozen, and restored, because it is not reaching into the shared global state. The same boundary that contains a hostile agent is what lets you fork a warm state in milliseconds and snapshot it to disk faithfully, so security and performance improve in the same commit.

How does Lunchbox protect a coding agent from prompt injection?

A sandbox gives the agent a boundary that a prompt injection physically cannot widen, because egress is mediated below the guest rather than inside it. The isolation is hardware-enforced, so a compromised agent cannot reach the rest of the host to expand its access.

Can Edera run AI agent workloads on my own cluster?

Yes. Lunchbox is a Kubernetes-native runtime you install on clusters you own, not a sandbox cloud you rent. Pod specs, images, and pipelines keep working, and the runtime arrives through a RuntimeClass so it runs on your own hardware and attestation chain.