The Four Sandbox Markets: A 2x2 Hypothesis

TL;DR

There are a lot of sandboxes these days. I was starting to lose my sanity. I therefore devised a 2x2 framework that categorizes sandboxes based on two dimensions, resulting in four distinct sandboxing markets. One key dimension is whether the sandbox is intended for software development or for running software in production. Another key dimension is whether the software can be self-hosted or whether the sandbox is “managed.” I think I’ve regained my sanity, but perhaps you disagree. Let me know!

OMG. Why Are There Suddenly So Many Sandboxes?

When I started at Edera earlier this year, I’d mostly heard the term “sandbox” in reference to malware sandboxes. In that case, a researcher places a known malicious piece of software in a controlled environment and prods it to see what it does. For instance, if you’re investigating Stuxnet–the malware used to sabotage Iranian centrifuges–and you don’t want to infect your own machine, you reach for a sandbox.

So I was surprised when Edera’s internal slack, my LinkedIn feed, software industry “manifestos” (marketing departments and Karl Mark both love manifestos), and even front-pager newspaper articles were focused on sandboxes, and not of the malware research variety.

The first thing I noticed is the stupendous variety of things that are called sandboxes, environments designed to constrain software. I started collecting a list of sandboxes (and I cribbed from existing lists of sandboxes). These sandboxes had names like “yolo-cage” and “IronCurtain.” Some used microVMs. Some didn’t. Some were vibecoded in the wake of OpenClaw and associated incidents, which didn’t inspire much confidence. Some were open source projects. Some were commercial products. Some have dozens of features; some, very few.

And I wanted to categorize these sandboxes, from the user’s perspective, into distinct markets. Something like: “When I face situation X, I reach for sandbox type Y.” And so I did that. And it took me a while. And it’s probably terribly wrongheaded. But I wanted to disseminate this so other people could tell me how I’m wrong. So here I go.

Two Dimensions for Every Sandbox

One key dimension is whether the sandbox is intended for software development or for running software in production. I admit it’s possible for a sandbox to be used in both cases, but my own investigation suggests this is currently the exception rather than the norm. 

Another key dimension is whether the software can be self-hosted or whether the sandbox is “managed.” Self-hosted software can be run on your own laptop or, for instance, a kubernetes cluster you manage. A “managed” sandbox generally requires shipping a workload, often a container, to some other company’s cloud.

These two dimensions then interact to create a 2x2 grid of four markets. See graphic #1 below. The next section explains the four markets.

The Four Sandbox Markets Explained

I’ll sketch the characteristics of all four markets, mentioning examples of open source projects or commercial products in each category.

Market #1: Local Machine Sandboxes for AI Agents

This category is for software engineers that run agents locally and want to sandbox that agent, limiting the blast radius of a rogue or malicious agent. After Summer Yue, director of alignment at Meta Superintelligence Labs, tweeted about a rogue OpenClaw agent that deleted portions of her email inbox despite her emphatic “STOP OPENCLAW” prompting, there has been a veritable explosion of sandboxes aimed at agents on local machines. There’s ai-jail, agentsh, clampdown, Docker Sandboxes, fence, nono, OpenShell, shuru and the list goes on. These local sandboxes allow a user, at least theoretically, to run agents in “YOLO mode” on your local machine. My anecdotal poking suggests that these sandboxes, universally open source, are mostly vibecoded, which, depending on one’s persuasion, could be good or bad or neutral.

Market #2: Remote Developer Environment Sandboxes

Sometimes engineers want to run agents doing software development tasks in a remote environment, again limiting the blast radius of an agent by separating it from the engineer’s local machine. Examples include AWS WorkSpaces, Google Cloud Workstations, or GitHub Copilot cloud sandboxes. In my crude mental model, it’s SSH’ing into a remote VM but with better ergonomics and designed for developer productivity. I expect more and more entrants to this category.

Market #3: Self-Hosted Production Sandboxes on Kubernetes

Engineers sometimes, however, want to run a sandbox in production on their own, well, production infrastructure, often Kubernetes. Historically engineering teams have turned to open source projects such as gVisor, Firecracker, Kata Containers. Edera is now also an alternative for similarly-minded engineering teams. For AI agents in particular, engineers have begun using the nascent Kubernetes “agent-sandbox” project, which can integrate with gVisor, Kata, or Edera. The benefit of deploying sandboxes on your own infrastructure is the control and autonomy one retains compared to using “managed” sandboxes, which I’ll mention next.

Market #4: Managed Sandboxes for Production

Some engineering teams want to offload sandboxing a production workload to someone else and, in that case, they have managed sandboxes to choose from. This is a bustling market! There are startups like Daytona, E2B, Isorun, and Modal; there are sandbox product offerings from established companies like Vercel Sandbox and Cloudflare Sandboxes; and there are offerings from the major cloud companies like GKE Sandbox and AWS Lambda MicroVMs.

But [INSERT SANDBOX] Doesn’t Fit Into the Above Framework

This simplistic framework doesn’t represent reality. It’s like a map. A map doesn’t indicate where potholes are. If you’re driving with a map, you’ll still need your eyes. Same with this framework. You’ll still need your brain.

There is some blurriness to the above categories because of “bring your own infrastructure” approaches that straddle “self-hosted” and “managed.” I can already see the HackerNews thread making this point. Additionally, the term “sandbox” is relatively elastic above–I offered the barebones definition of “environments designed to constrain software”--and this will beg many questions about what is and is not a sandbox. Also, some of these “sandboxes” above are more like a component of a sandbox while others are full-featured.

Sanity Despite The Profusion of Sandboxes

I offer this framework above with Cunningham’s Law in mind:

> the best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer

(See xkcd #386 for a delightful riff on the above.)

I have found the above framework helpful in conceptually organizing “sandboxes” into distinct markets. Maybe you will too. Or perhaps you won’t.

And if you’re interested in learning more about how Edera fits into this whole sandboxing thing, check out EderaON at on.edera.dev, an easy way to get hands-on with Edera quickly.

FAQ

What is the difference between a self-hosted and a managed sandbox?

A self-hosted sandbox runs on infrastructure you control, such as your laptop or your own Kubernetes cluster. A managed sandbox requires shipping your workload, often a container, to another company's cloud—trading control and autonomy for lower operational burden.

What is a sandbox for AI agents?

Here, a sandbox is simply an environment designed to constrain software and limit the blast radius of a rogue or malicious agent. For local agents, these sandboxes let you run agents in "YOLO mode" while isolating them from the rest of your machine.

Which sandboxes run AI agents in production on your own infrastructure?

For self-hosted production isolation, engineering teams have historically used open source projects like gVisor, Firecracker, and Kata Containers. Edera is now also an alternative, and the Kubernetes "agent-sandbox" project can integrate with gVisor, Kata, or Edera.

Why are there suddenly so many AI agent sandboxes?

After public incidents involving rogue autonomous agents—including an OpenClaw agent that deleted inbox contents despite emphatic stop prompts—interest in constraining agents exploded, producing a wave of mostly open source, often vibecoded sandboxes aimed at limiting an agent's blast radius.