Sandboxes Aren't Optional: 4 Ways to Isolate Coding Agents — Robert Brennan, OpenHands

Uh, my name is Robert Brennan. Uh, I'm the CEO at OpenHands, uh, and I wanna talk to you a little bit about-- today about, uh, sandboxing coding agents, uh, why this is a really important pattern and, uh, different ways to actually get this done. Uh, a little bit about me. Um, like I said, I'm the, I'm the CEO of OpenHands. Uh, co-founded it, uh, a little over two years ago, really with the vision of bringing, uh, coding agents to the community, right? Uh, really giving software developers a say in the gigantic change that's happening to our

jobs. Uh, and we started OpenHands as an MIT licensed coding agent, uh, and I would say now we've, we've evolved really to a, a platform for running coding agents. Everything from the harness to the infrastructure to the control plane to actually, like, monitor these agents at scale.

Uh, a little bit about the history of AI-driven development and how we got to where we are today and, you know, where I think things are going in the future. Uh, we really started with, like, uh, code snippets being generated by a chatbot, right? I remember the first time I typed into ChatGPT, like, "Write a SQL query that does X," and it just, like, one-shotted it, and I was blown away. Uh, that feels very, um, uh, antiquated today. Um, but, uh, you know, my, my original workflow was a lot of, like, type into ChatGPT, paste something into my IDE, hit Enter, paste an

error message back into ChatGPT, and it's pretty quick that I realized, like, "Hey, this is kinda dumb. I can just, like, wire some APIs together." Uh, and very quickly we got, uh, these AI-powered IDEs. Stuff like Cursor and GitHub Copilot doing things like autocomplete, right? Where now you have the context of the code base. You're not just generating code snippets inside of a chat window, you're actually modifying the code itself. You can see the variable names that are available there. So the AI gets a little bit smarter, a little bit more context-aware. And then the big leap in, like, the beginning of twenty-twenty-four, uh, was this leap

to agents. So, uh, AI that wasn't just writing code, but was actually running the code that it wrote, right? Um, actually, like, looking at the error messages, googling them, really doing that entire loop of development on top of the LLM. Um, and that's kind of where we're at today. I would say most developers today are still-- They're running something like Claude Code or OpenHands, uh, or Codex on their laptop, um, uh, as, like, kind of a pair programmer model, right? They're manually prompting this thing. The leap that we're seeing organizations make over the course of

twenty-twenty-six is really to agents that run in the cloud, and this is really where sandboxing comes into play. Uh, one, because, you know, it needs a place to work in the cloud, right? You need to give this agent a terminal, a file system, et cetera. Um, but two, because, um, you're really, uh, you're able to do a lot more once you've got these agents in the cloud, right? Um, and you need to make sure that they have access only to the things that they're, they're allowed to access, um, 'cause there's not necessarily going to be a human there to babysit them, right? Um, going forward from there, I think the more we get

agents running in the cloud, running autonomously, running, uh, you know, in response to events coming out of systems like GitHub and Datadog and Slack, rather than being manually prompted, you're gonna get these interactions between agents where, like, one agent opens a PR, another's doing code review, and they're going back and forth, and we see these multi-agent teams emerging. Uh, and then I think the end game is really this full SDLC automation where, you know, humans aren't even looking at the source code anymore. Uh, but the really-- thing I really wanna talk today about is how do we make this leap from, from number three, where we're running agents on our machine, to number

four, where we've got agents running in the cloud?

Uh, so let's talk a little bit about, uh, running locally. Uh, who here runs Claude Code on their laptop or Codex or OpenHands? Something, some local agent. All right. Fewer than I would expect. Uh, keep your hand raised if you use Dangerously skip permissions. Yeah, okay. Somehow more hands than before. Um, so the, the-- this is the big trade-off when running agents locally, right? Is you can either sit there and hit, like, yes, yes, yes, you're allowed to do that, over and over again and babysit the agent while it works, or you can go into dangerly-- dangerously skip

permissions mode and just, like, trust that the agent isn't going to delete a file you really care about or access your production database or anything like that, right? Um, so running locally, you, you are kind of limited by those, those two options. Uh, and if you do run locally and you run with Dangerously skip permissions, uh, the agent does have access to a lot of things, right? It has access to your whole local file system, uh, it has acc-access to any secrets that are in your environment variables, uh, it has access to any secrets that are in, like, in your, in your home

directory. Uh, if you're connected to, like, a production database or a production Kubernetes cluster, the agent can get in there. It has access basically to everything that you have access to, right? Um, so super important that you, uh, either sit there and babysit it and watch what it's doing, or you find a way to cut off its access and really only give it access to the things that it needs. And this is a, this is a paradigm that we actually know well from, you know, pre-agent security days. It's the principle of least privilege, right? The idea is that both

agents and humans should only have access to the things that they need in order to do their job, right? So the agent shouldn't have access to every secret on your system. It shouldn't have access to every file on your system. It should only have access to the GitHub repo that it's editing and maybe a couple secrets that it needs to access a local database, something like that. Um, so it's important when we start to sandbox these agents that we're looking at what exactly does this agent need in order to do its job, and then we can create a sandbox that has just exactly those things. And then we know that the, the blast radius of a prompt injection attack,

uh, or the agent getting confused, anything that could go wrong, like, we, we limit the blast radius by limiting how much the agent has access to.

So the first strategy that folks tend to experiment with is running inside of Docker containers on their laptop. This is actually the, uh, way we originally launched OpenHands was as an interface where every time you started a new conversation with the agent, we'd spin up a brand-new Docker container, the agent would get its own, its own container, and this, this works really nicely for several things, right? Uh, one, it's ephemeral, so the agent can do kinda whatever it wants. If it runs rm -rf / and deletes everything, uh, you just kill the container and start again, right? It's, it's a very nice, uh-- the agent

can, can just kinda run wild. You don't have to worry too much about what it's gonna do. Um, and because it's running locally on your laptop, you can also mount in things selectively from your local file system, uh, you know, like a, a Git repo. Uh, you can mount ports so that the agent can run out an application, and you can view it in your browser. You can mount specific secrets and environment variables for the agent. Um, you can have MCP servers either running locally on your laptop or inside the Docker container. Uh, and it's nice because the agent is still working with, like, your local copy of the code, right? It's similar to how you're used to working where

you've got, like, a, a copy of the code on your workstation, and instead of you editing it, the agent's editing it now, and you're deciding when to Git Push and all that. Uh, but this doesn't really scale very well. Uh, there's only so many Docker containers you can get running on a laptop. Uh, your laptop can't, like, listen for events coming out of, like, Slack and Datadog, et cetera. Um, so this, this is pretty limited in terms of what you can do here.

The next strategy we see folks taking is starting to, like, glue together Claude Code and GitHub Actions. Um, uh, this is definitely different from, like, running Docker containers on your computer. Uh, now you're no longer working with your local copy of the code base. You're now, uh, you know, having, uh, this, this agent inside of a, like, an ephemeral environment, somewhere inside of GitHub Actions, cloning the repo, doing stuff, you know, uh, and then, like, shipping it off, and then everything, everything goes away once that action spins down.

But what's nice is that, you know, you can run as many GitHub Actions as you're willing to pay for, right? It has built-in support for things like a secrets registry. Um, so you get these nice, these nice isolated environments, and what's really cool is now you can run them on a schedule, right? You can just have a GitHub Action that spins up an agent, you know, every Monday morning at nine AM and updates your dependencies, right? You can have a GitHub Action that anytime a PR gets opened, is gonna use an agent to do code review. So you can start to get some automation in place now that the agents are, are off your laptop and in the cloud. Uh, but you're locked into GitHub

Actions, right? This is a proprietary standard. Uh, you're not gonna be able to really port this. Um, it's only able to respond to events coming out of GitHub, right? You can't respond to, like, a Slack webhook or a Datadog webhook. Um, so you're, you're kind of limited in terms of what you can do by just, like, gluing things together with GitHub Actions.

The next strategy we saw folks take was kind of in the OpenClaw craze where you actually get a separate computer, you know, a virtual machine in the cloud or maybe a Mac Mini, uh, and just put all your agents on that, right? Um, this is different from GitHub Actions in that now you've got a, a long-lived environment. You've got persistence, right? Which is good and bad, right? You, you-- your agents can modify the system and know it's gonna be that way again when they run, you know, two days from now. Um, but your machine could get into a bad state as well, and you might have to go and debug and figure out what's going on. Um, you can, again, you

can, uh, just like in GitHub Actions, you can run agents on a schedule. Uh, now since-- if you're on a-- running on a VM, you can actually listen for webhooks coming in from, uh, you know, Twilio, if you wanna listen for text messages, from Slack. Uh, you can listen for incidents coming out of Datadog, events coming out of GitHub. So you get agents running automatically now, uh, but you still have this principle-of-least-privilege problem, right, where all of your agents are now, like, co-located in this virtual machine, and they all have access to the same stuff. So you might have, like, a, a code review agent in there, uh,

alongside of, uh, you know, a Datadog triage, like, incident triage bot. And the code review agent now for some reason has access to Datadog, and there's just a lot more possibility for things to go wrong, right? The code review bot can even, like, uh, you know, edit the, the memory for the Datadog bot. Uh, so, like, there's this co-locating problem, uh, quickly runs into issues where agents have access to way more than they necessarily need in order to do their job. So way more opportunities for things to go wrong when all these agents are bumping into each other.

The fourth and, and really, like, the most robust strategy here, I would say, is to use Kubernetes, uh, or some other, like, you know, highly scalable environment, uh, that's ephemeral, right? Um, and now you're getting, you know, with Kubernetes, say, uh, you get a pod for every agent session you wanna run. Uh, it spins up, the agent runs, does its work, you know, maybe working on a local copy of the, of the repo. Then it spins down, and all that environment goes away. You know, the agent has opened up a pull request or something like that, right? Um, this is really nice because, uh, you don't have to worry about, like, the long-term

state of this thing the way you do with a VM. You don't have to worry about it getting into a bad state because every time an agent runs, you're, you're basically killing the environment and starting fresh. Um, and you get, like, an infinite amount of scale, right? You're-- You have cloud scale at this point. Um, you can run as many agents as you want as long as you're, again, willing to pay for the memory and CPU, uh, to run them.

And again, because it's, it's Kubernetes, it's running in the cloud, uh, you can respond to, uh, you can run things on a schedule using, uh, cron jobs. You can, uh, run things in response to HTTP events coming out of, you know, Slack and GitHub and Jira. Um, you can basically run agents fully automatically. Um,

a little, uh, kind of like quick comparison here. I'll just go down the, the, the things that I look at when I'm comparing these different strategies. Um, one is, is it local, or is it remote, right? Is it on your, on your laptop working with your copy of the code base, or is it running somewhere else that has to, like, clone in the code itself or with its own copy? Those are two very different ways of working. Um, what kind of scale can you get out of this thing, right? If you're, if you're running locally on your laptop, you can maybe run ones of agents before things start getting uncomfortable. If you're in Kubernetes, you can run thousands. Um, level of

isolation, right? Uh, if you're not running-- if you're running, like, dangerously-skip permissions on your laptop, you've got nothing. Uh, if you've got all your agents, like, co-located in a VM, they're separated from your environment, but they can still step on each other's toes. But something like Kubernetes, uh, every agent has its own workspace. You know, it's, it's doing its own thing. Uh, level of persistence. Um, you know, you can, you can always get some persistence by saving files out or, like, writing to external systems. Uh, but when you're working on your laptop or you're working in a VM, you do get just, like, persistence by default, right? That system is long-lived.

Um, and then what kinds of triggers can actually cause these agents to run, right? If you're running locally on your laptop, it's typically just gonna be a manual. You're typing in a prompt. Uh, once you get into the cloud, you can start to run things on a schedule or run things in response to events. Uh, if you've ever, like, uh, been, like, biking home with your laptop open 'cause you didn't want Claude Code to shut down, this is a great reason to start moving your agents to the cloud.

Uh, I did want to, uh, touch on the fact that sandboxing is not a panacea. Um, there is, uh, evidence of agents escaping their sandboxes. Um, you know, here we, we saw during, uh, one, when Anthropic was te- testing Mythos, uh, one of the Mythos instances actually managed to break out of its sandbox, gain internet access, start doing other things. There are container escape attacks out there. Um, some of them are known if you're running an old version of Docker, say. Um, so it's not, it's not

perfect. You still have to be a little bit careful. Um, but it is, it is at least a, uh, a good first pass at keeping agents limited to, uh, what they're-- what they should be doing.

Um, last, I'll give a quick plug for OpenHands Agent Canvas. Um, this is a way, you know, really to run, uh, with any type of sandbox. You can run it with Claude Code or Codex or the OpenHands harness. Uh, but we've designed it really to, you know, by default, if you saw it on your laptop, it's like running Claude Code with dangerously skip permissions. But with one quick toggle, you can start running things in Docker containers. Another toggle, you can start running it in a remote VM. Another toggle, you can run it inside of Kubernetes. Um, so it's a really great way to, like, pick the right environment for the job, right? Sometimes

you really do wanna be working with your local copy of the code base. You wanna be doing that quick iterative development back and forth with an agent where you're looking at the code locally. Sometimes you really just wanna fire off events that, you know, let agents run autonomously in the background for a few hours. Um, you really want it running inside of Kubernetes or inside of a VM. Um, so this is a, a great way to kinda move between these different types of environments. Uh, that's all I've got, but I'm happy to, to take questions from the audience.