Sandboxes Aren't Optional: 4 Ways to Isolate Coding Agents — Robert Brennan, OpenHands Transcript, AI Summary & Key Points

00:01 [music] >> Uh my name is Robert Brennan. Uh I'm the CEO at Open Hands. Uh and I want to 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 Open Hands, uh co-founded it a little over 2 years ago, really with the vision of bringing uh coding agents to the community, right?

00:37 Uh really giving software developers a say in the gigantic change that's happening to our jobs. >> [snorts] >> Uh and we started Open Hands 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.

01:00 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 in a ChatGPT like, "Write a SQL query that does X." and it just like one-shotted it and I was blown away.

01:16 Uh that feels very um antiquated today. Um but uh you know, my my original workflow was a lot of like type in a ChatGPT, paste something into my IDE, hit enter, paste an error message back in a ChatGPT. And it's pretty quick that I realized like, "Hey, this is kind of 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?

01:42 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 beginning of 2024 uh was this leap to agents.

01:59 So AI that wasn't just writing code, but was actually running the code that it wrote, right? Actually like looking at the error messages, Googling them, really doing that entire loop of development on top of the LLM. 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 open hands or code acts on their laptop.

02:23 As a 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 2026 is really to agents that run in the cloud. And this is really where sandboxing comes into play. 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, etc.

02:42 But two because you're really you're able to do a lot more once you've got these agents in the cloud, right? And you need to make sure that they have access only to the things that they're they're allowed to access cuz there's not necessarily going to be a human there to babysit them, right? Going forward from there, I think the more we get agents running in the cloud, running autonomously, running you know, in response to events coming out of systems like GitHub and DataDog and Slack rather than being manually

03:07 prompted, you're going to get these interactions between agents where like one agent opens a PR, another's doing code review and they're going back and forth. We see these multi-agent teams emerging. 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. But the really thing I really want to 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

03:29 running in the cloud? Let's talk a little bit about running locally. Who here runs Claude code on their laptop or code acts or open hands, something some local agent? All right. Fewer than I would expect. Keep your hand raised if you use dangerously skip permissions. Yeah, okay. Somehow more hands than before. So that the is the big trade-off when running agents locally, right?

03:53 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 dangerously dangerous to 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?

04:11 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 access 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

04:37 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 is the principle of least privilege, right?

05:00 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, 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.

05:17 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.

05:43 So the first strategy that folks tend to experiment with is running inside of Docker containers on their laptop. This is actually the way we originally launched Open Hands 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?

06:01 One, it's ephemeral. So, the agent can do kind of whatever it wants. If it runs rm -rf and deletes everything, you just kill the container and start again, right? It's It's a very nice The agent can can just kind of run wild. You don't have to worry too much about what it's going to do. And because it's running locally on your laptop, you can also mount in things selectively from your local file system, you know, like a Git repo.

06:23 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. You can have MCP servers either running locally on your laptop or inside the Docker container. And it's nice because the agent is still working with like your local copy of the code, right?

06:40 It's similar to how you're used to working where you've got like 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 get pushed and all that. But this doesn't really scale very well. There's only so many Docker containers you can get running on a laptop. Your laptop can't like listen for events coming out of like Slack and DataDog, etc.

07:00 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 Cloud Code and GitHub Actions. This is definitely different from like running Docker containers on your computer. Now you're no longer working with your local copy of the code base. You're now, you know, having this this agent inside of a like an ephemeral environment somewhere inside of GitHub Actions, cloning the repo, doing stuff, you know, and then like shipping it off and then

07:30 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 in for things like a secrets registry. 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 9:00 a.m.

07:51 and updates your dependencies, right? You can have a GitHub action that anytime a PR gets opened is going to 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. But you're locked in to GitHub actions, right? This is a proprietary standard. You're not going to be able to really port this.

08:09 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. So, you're you're kind of limited in terms of what you can do by just like gluing things together with GitHub actions. >> [snorts] >> The next strategy we saw folks take was kind of in the open claw craze where you actually get a separate computer, you know, a virtual machine in the cloud or maybe a Mac mini and just put all your agents on that, right?

08:32 This is different from GitHub actions in that now you've got 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 going to be that way again when they run, you know, 2 days from now. 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.

08:50 You can again you can just like in GitHub actions you can run agents on a schedule. Now since if you're on a running on a VM you can actually listen for webhooks coming in from you know, Twilio if you want to listen for text messages from Slack. You can listen for incidents coming out of DataDog, events coming out of GitHub. So, you get agents running automatically now.

09:11 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 alongside of 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?

09:30 The code review bot can even like you know, edit the the memory for the DataDog bot. So, like there's this co-locating problem 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. >> [snorts] >> The fourth and and really like the most robust strategy here, I would say is to use Kubernetes or some other like, you know, highly scalable environment that's

09:59 ephemeral, right? And now you're getting, you know, with Kubernetes say you get a pod for every agent session you want to run. 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?

10:17 This is really nice because 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. And you get like an infinite amount of scale, right? You're you have cloud scale at this point.

10:33 You can run as many agents as you want as long as you're again willing to pay for the memory and CPU to run them. And again, because it's it's Kubernetes, it's running in the cloud. You can respond to You can run things on a schedule using cron jobs. You can run things in response to HTTP events coming out of, you know, Slack and GitHub and Jira. You can basically run agents fully automatically.

11:02 A little 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. 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.

11:18 Those are two very different ways of working. 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. Level of isolation, right? If you're not running if you're running like dangerously skip permissions on your laptop, you've got nothing.

11:35 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.

11:53 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 going to 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.

12:13 Uh, if you've ever like, uh, been like biking home with your laptop open cuz 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 or doing other

12:45 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 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 Open Hands Agent Canvas.

13:09 Um, this is a way, you know, really to run, uh, with any type of sandbox. You can run it with Claude code or Code X or the Open Hands harness. Um, 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.

13:27 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 want to be working with your local copy of the code base. You want to be doing that quick iterative development back and forth with an agent where you're looking at the code locally.

13:43 Sometimes you really just want to 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 kind of 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. >> [applause] [music]