Hey {{first name | there}},

If you clicked on this, you’re likely as curious as I am, or you feel I am about to sell you something; only the first part is true. 

If you have been around (Twitter, Reddit… the internet at large), you might have heard about sandboxes. At first glance, my reaction was, “Great, another thing in the advent of AI.” However, I have had some time to think about it.

In this issue, I’d like to talk about what they are and why I think it might be worth a shot to know and possibly use it. 

Sandboxes have emerged as AI agents started gaining more access to system resources and tools. If you are like me, then when you use something like Claude code, you simply approve each command after another until completion. 

This I find to be a good middle ground, as I do not want an agent screwing things up or creating new code paths I can not account for,  however not everyone leverages agents this way. What if you could give agents access to an isolated environment but still let them run freely within it? That is essentially what a sandbox is — a controlled execution environment where an agent can operate without the ability to affect anything outside of its boundary. Think of it like a walled garden: the agent gets to do its thing, write files, run commands, explore the codebase, but if it makes a mistake, it cannot escape into your real system and do damage that matters.

This is also where the cloud native world comes in. The Kubernetes SIG Apps community has stood up a dedicated project, Agent Sandbox, to address exactly this problem at scale. Agent Sandbox provides a secure, isolated execution layer to safely deploy autonomous AI agents on Kubernetes that generate and run untrusted code at scale. k8s What makes it interesting from an architecture standpoint is the interoperability angle:

At EverythingDevOps, we are huge advocates for the cloud-native community, so a SIG being formed to tackle this problem on K8s is a sign of bigger things to come.

Another interesting piece I found while researching for this issue is the Cursor team's write-up on agent sandboxing. They do a good job of going over the basics and some specifics for macOS — worth a read if you want to get into the weeds on how this plays out at the OS level.

Feels like I heard about sandboxes only yesterday, and folks are already looking to stretch beyond sandboxes and give agents full computers.

Computers for agents is interesting; it seeks to provide agents with full access to an operating system with the premise being that the boundary between "task" and "environment" should not exist for an agent — it should have a persistent workspace, the way a human developer has a laptop they come back to. The machine remembers state, retains context, and agents should always be running or at least ready to run.

This started to click when I saw OpenComputer from the folks at Digger. The idea is persistent VMs that hibernate when idle and wake in seconds. Where a sandbox constrains what an agent can touch, computers for agents says give the agent a full machine that is its own, let it persist state between runs, and design the infrastructure around that assumption rather than around restriction.  

“Isn’t this just a VM?” I hear you whisper. Well, honestly, you’re not wrong. It is still early days, and I am still in the early stages of forming a full opinion, so if you have one, feel free to send me an email, and we can chat.