Docker Sandboxes - Building Safe Agents

summarized

TLDR

Docker Sandboxes offer a practical solution for running AI agents safely by launching them inside microVMs with hardware-enforced isolation, not just containers. The key innovation is that you can define granular policies for network access, file system read/write permissions, and credential handling through a proxy, all while booting in seconds and tearing down cleanly. This makes it straightforward to let agents run autonomously — even with local models via LM Studio — without worrying about system damage or secret exfiltration.

Key points

  • Docker Sandboxes are based on microVMs, not standard Docker containers, providing hypervisor-level isolation with fast boot and teardown.
  • Sandboxes allow granular control: you can limit which folders an agent can read/write, which network endpoints it can reach, and which credentials (e.g., API keys) it can use.
  • Credentials are handled via a proxy so that the raw key never appears inside the sandbox; only a 'proxy managed' placeholder is visible to the agent.
  • Pre-built sandbox templates exist for popular coding agents like Codex and Claude Code, and the video demonstrates running Codex in a sandbox where writes outside the designated folder are silently blocked.
  • Custom sandbox templates called 'kits' can be created to install dependencies, set environment variables, and run a startup script — demonstrated with a Deep Agents (LangChain) kit configured to only allow network access to OpenRouter and LM Studio.
  • The video shows the custom Deep Agents sandbox cannot search Google or access the host file system, confirming the isolation works as intended.
  • Docker Sandboxes are free for individual use; the sbx login links to a Docker account, presumably for enterprise tracking.
  • The sandbox can use local models via LM Studio (localhost:1234), enabling fully offline, secure agent testing without external API costs.

Tools mentioned

Techniques

  • microVM-based sandboxing for agent isolation
  • credential proxying to avoid exposing raw API keys inside the sandbox
  • network policy definition with allow/deny rules per sandbox
  • filesystem permission policies (read-only vs. read-write folders)
  • custom sandbox kits for automated environment setup and application launch
Transcript (captions)

0:00 Okay, so one of the biggest pain points at the moment if you're running any kind of agent is the whole safety factor. Now this can be if you're running coding agents, things like clawed code, codecs,

0:12 etc. where you just don't want to have to sit there babysitting doing yes, allow, yes, allowed, no, don't touch that for the next sort of 3 hours. Now, of course, you've got the option of

0:22 dangerously skip permissions, but then you've got to worry about what it's actually going to do to your system. Is it going to wipe your drive? etc. And all of this is compounded if you're

0:32 using agents like Hermes or Open Claw or even creating your own custom agents. So, while we want our agents to basically have autonomy and to be able to do different things, we also want to

0:46 have them locked down so that they're safe and they're not going to wipe your hard drive, etc. This is where Docker has been working on a really good solution for this and they've agreed to

0:55 sponsor this video so I can tell you all about it. So what I'm talking about is Docker sandboxes. So the idea here is that you can use these for coding agents. You can use these for sort of

1:07 local personal agents. You can even use it for your own custom agents. But what it is doing is allowing you to create a sandbox where you determine things like what network access the agent can have,

1:20 where you determine what models it can use, where you determine things like what storage folders it's allowed to read from, and also what folders it's allowed to actually write to, etc. And

1:31 then probably one of the biggest ones is you want to basically have a way to lock down your credentials so that the agent itself can't just start going out and giving your credentials to other people

1:43 if someone tries to prompt injected etc. So Docker sandboxes allows you to basically lock all of these things down and define simple policies that give you the control that you want for each of

1:55 the things that you want your agent to be able to do. So, in this video, I'm going to look at how to basically set this up. We'll look at creating sandboxes. We'll look at how do you give

2:04 different sandboxes different permissions, etc. How do you allow it to have access to the credentials? How do you set up a proxy for credentials? And for me, one of the biggest things here

2:15 is just how quickly you can basically try out new agents that are out there, set them up and connect them to perhaps a local model on LM Studio or something, run them for a few hours to see how they

2:29 actually go and not have to worry is this thing going to be making changes to my computer or messing up my file system, etc. All right, so let's start off with what actually this is. This is

2:39 not normal Docker containers. So, Docker is a fantastic tool. I think most people in development have used it for a long time. It's certainly the way to be able to set up environments that you can then

2:51 use both locally and put into production, etc. But generally, Docker kind of containers are great for packaging up an app. They're not necessarily ideal though for agents.

3:03 What Docker sandbox is is actually sandboxes that we're going to be making is a microVM. So this is a small fast VM with its own Linux kernel that's separate from yours. And one of the key

3:17 things here is that this is all about the hypervisor. So the hypervisor is basically a layer that creates and runs VMs. It sits between your hardware and the virtual machine and it can hand off

3:30 sort of like a slice of your CPU, your memory, etc. to the actual VM. And the key thing here is that this is hardware enforced. It's not just software etc. And so this idea of a microVM is a fully

3:44 contained solution that actually has more isolation to it than normal sort of containers. So full VMs they isolate things fine but they can often be quite chunky slow takes time to spin them up

3:57 takes time to spin them down. The microVM sits in the middle and gives you sort of real virtual machine level isolation, but boots really fast and can tears down really fast. And this is

4:09 exactly what you want for agents. Now, inside each of those VMs, you've got a sort of Docker engine in there. You can install packages, you can run things, you can make a mess, and when you're

4:21 done, you can just throw the whole thing away, and it won't have affected anything on your machine here. So let's jump in and look at how we can actually create these and then how we can

4:30 actually set this up with something like a local agent on a machine and let it run wild and see what we can actually do where we're not having to pay for external tokens. We're not having to

4:40 worry about stuff. We can just let the agent run and then evaluate that at the end. Okay, so the first thing you want to do is actually set this up. So to do that once you've got it installed and

4:51 the instructions are pretty easy to get it installed on the different platforms. You want to come in here and just do SBX login. What that will basically get you is that will link this to a Docker

5:03 account. And once you basically authenticate your account there, it will then authorize your system. Now, it's totally free. It's not going to cost you anything to do this. My guess is this is

5:14 just Docker's way of enforcing enterprises to use paid accounts, etc. Now once we've logged in, the simplest use of this is just to use it for coding agents. So for example, one of the big

5:27 issues you're going to have with various coding agents is that you don't want them going crazy and messing up your file system. So you can see here if I come in and I do spx run codeex, it's

5:41 going to start up codeex. But this codeex is actually now running in the docker sandbox here in this folder that I've called codeex test. Now if we come out and actually look at here what is

5:55 running, you can see I can just do sbxls and you'll see that sure enough I've got a number of different sandboxes here. The one that's running at the moment is this codeex test with the agent codeex

6:08 in there. So you can see that it's basically got access to everything in here. If I ask it to write me a read me with today's time, but in the folder one up from this, you'll see that okay, it's

6:23 able to go off and look like it's running the various sort of commands as it goes through this. But you're going to see that it's actually sandboxed. So it won't be able to write to this

6:34 particular directory. In fact, I can't write to anything on the actual machine there except this folder that we're in. So, you can see if I go out and I actually go up to that directory, there

6:46 is no read me in there. Yet, it thinks that it's actually done it, but it's actually been blocked when it was actually trying to do a read me there. But if I want to write something in this

6:56 folder, like I want to actually do code and stuff in this folder, that will have no problems, right? It will go off. It will check what's in this folder, but then it can write an HTML file. It could

7:07 write a set of Nex.js files, etc. No problem in here. Okay. So, you'll see that if we come out and we go to that folder, we can see that our index html file has nicely been written there. And

7:20 sure enough, if we look at it, we can see that it's exactly what Codeex wrote in there. So this is the basic sort of security that the sandbox gives you is it stops agents or anything that you've

7:32 got running in there being able to access other folders or erase things on your disc etc. And if I come out of the sandbox and I can actually go in there and see okay what network connections

7:44 was it connecting to in here. Now the first time you set it up you will actually get to be able to choose whether you want your sandboxes to be open, fully closed or balanced. Now at

7:55 any point you can also reset that. So if I come back to SBX policy and I select reset in here, it will first make sure that it's closed down all the different sandboxes that I had running. But you'll

8:08 see then I've got the option to basically select open so I don't block any network traffic. There's no restrictions or anything. I can have it fully locked down where all network

8:19 traffic gets blocked. But probably most of the time you're going to want to do this balanced. All right. So, let's make a completely new sandbox here. So, I'm going to do SBX run. I can do create,

8:29 but if I'm going to do run, it's just going to create it and run it. I'm going to go for claude this time. And I'm going to give it a name of testing CC. So, you'll see that it has already

8:41 downloaded the different sandbox files here. So, it was able to basically just get those going because I've used this before. It's already downloaded them. If you don't have them there, it would go

8:53 through this. Now, first off, I'm going to need to do my standard sort of login. In this case, I'm just going to log in with my account. All right. So, I've gone through. I've done my login with

9:03 the web, etc. And you can see it's basically got the bypass permissions on. So, it's running in dangerous sort of mode in here. What I'm going to do, though, is actually just exit out of

9:12 this so that we can look a little bit about the network rules that were actually in there. So to do this, we do sbx ls just to see what sandboxes we had there. We've already stopped this one.

9:23 So we're doing this testing CC. So spbx policy ls testing CC. Then I can tell it that I want to see all the different network settings for this. And you see there's 192 hosts basically in there. If

9:38 I wanted to actually see them all, I can actually go through and see what's in here and what's approved and stuff like that. So this is on the balance settings. So it's set up for a generic

9:48 use case across everything from chatgpt cursor openai anthropic. You'll have AWS in there. You'll probably have some Google APIs in there. Gemini.g Google. You've got a variety of these things in

10:02 there. Now if you wanted to, you can actually come in and make your own network policy from scratch. So you can lock it down. The next thing I wanted to show you though is probably the bit that

10:12 I think is more interesting than just the coding agents. The coding agents is really sort of rock solid for you to be able to do your day-to-day coding. But if you're building agents, whether

10:23 that's with something like deep agents or any of the agent frameworks that you want to work on yourself, you're often going to want to have your own sandbox for the agent. And in that sandbox, you

10:37 can install packages. You can install anything that you need to in there, but you want to basically limit where it can write and what it can write to that. It's just going to write to that local

10:50 directory. So the way we do this is we basically do run, but rather than put in clawed code or codeex or open code or something like that, we basically just tell it that we want to do a shell. And

11:05 this is going to give us a sandbox that is purely for a shell. And then also I can use a directory which is a sibling directory to this which is shell test. So that should now create the new

11:18 sandbox. Set it up and you can see now we are in shell test. Right. So, I've got a whole new sandbox for this with an agent that I can install. And I could then install all my scripts in here. And

11:32 then I can limit not only what it can read and write here, but also what it can access over the network. So, you'll see that if I just run a curl command here, I'm going to get told that this

11:42 was actually forbidden in here. And you'll see if I come out of this sandbox, I can also test this. And we can see that okay, this example.com is denied there. it's not allowed for that

11:55 sandbox. So, I've got that locked down in there. Now, if I want to allow it, I can just change the policy to allow the network on this sandbox to allow this URL on that particular port. And you can

12:08 see that now the rule has been added to the policy. And if I check this again now and run it, you can see sure enough now it's allowed. So, the cool thing there is you're able to lock down and

12:18 limit everything about what your sandbox can read and write. We could also set it up so that certain folders just have read access only and then other folders have write access. So that allows us to

12:31 basically then set a bunch of documents in there that we want to be immutable that the agent can access perhaps some things like that but then they can't be overwritten. While we may have like a

12:44 folder which is like a scratch pad folder where it can write memories to it can write use it as a full file system for writing notes to itself. The next thing we want to be able to do is look

12:55 at how we would support keys. So anytime I'm testing out a particular agent that's from GitHub or a new coding agent or something like that, I don't want to run it blindly on my machine. I want to

13:09 be able to control what it can actually read and write to and what it can actually look at on the web. All right. So, if you want to set something like a secret in here. So, let's say we wanted

13:20 to put in a secret for the open router API key, right? And I don't really trust my agent too much whether it's going to try and excfiltrate that out or it's going to do something with it. I can

13:34 come in here and set the secret. So, in this case, I'm just going to put Sam's open router secret in there. And it's basically been set in there. You'll see though if I come back in here and

13:49 actually look at the key in here, all I get out is that it's proxy managed. Meaning that inside the actual sandbox, you can't see the raw key. you just see a placeholder which gets passed out and

14:06 then as it goes out of the sandbox it gets converted into the real key to be sent to open router. So using open router would be fine but I don't need to worry that okay the sandbox is going to

14:19 be getting my keys and then sending them somewhere else. Now of course I could also block all other network access out apart from open router if I wanted to. There are a lot of different ways you

14:30 can kind of lock this down, but just knowing by default that you're able to basically do this SBX secret and set it and you could also set it as a global key if you're going to be using it quite

14:42 often for multiple sandboxes, etc. Okay, so there are a bunch of sort of pre-made templates that you can use to make sandboxes. So, for example, I showed you the codeex one, I showed you the claude

14:55 code one. There are also things like open code and a number of different things. But if you want to make your own sort of templates, Docker has actually created a system to do that and that's

15:05 called kits. So I'm not sure if this is in its fully worked out final version. You can see they've listed this as still early access but anyone can access this. And what this basically does is it

15:17 allows you to set up tools to install the environment variables, credentials, network rules, all these kinds of things to be able to make a kit. Now, kits can do a whole bunch of different things.

15:32 They can install things and create the environment for you. They can also basically set up an app and run the app for you. Now, here is an example of a kit that I made for a deep agents agent.

15:45 So, if you know deep agents from Langchain, it's basically a framework that allows you to build agents that both have access to file systems, have access to tools, all those kinds of

15:56 things. Now, if you look in here, this is going to basically inherit from a shell. So, it's going to basically just be a shell kind of sandbox, but it's going to have a bunch of properties that

16:08 I am setting in here. So, I only want this to be able to contact open router and LM Studio. So, you can see that it's basically set up for the network to just allow open router and open router on 443

16:24 and local host on 1234, which is the LM Studio. Now, it's also got some other things in there to be able to allow Linux updates, to be able to install Pi packages, etc. But you can see that it's

16:37 denying OpenAI, Chat GPT, all the typical sort of things that we have before. We can also set up that it's going to need some credentials which are going to be open router and that I'm

16:48 going to set globally. So, that's going to be injected in via the proxy, right? So, I don't need to set any of that in here. If I wanted to, I could actually put my key in there, but would kind of

16:59 defeat the purpose, right? And then you can see once this gets created, it's going to install Python. It's also going to set up a virtual environment in there. And it's then going to pip

17:09 install a bunch of packages like Deep Agents, Langchain, Langchain OpenAI, so we can use LM Studios OpenAI endpoint in there, and then Langchain open router in there. Now, if I wanted to make it for

17:23 Gemini or for something else, I could certainly add that there. I've also got then the actual code that is going to run once this is all installed in here. So, this is going to be just a super

17:35 duper simple little agent, which is basically a chat. There's no real tools here. There's nothing all like that. But, if I wanted to, I could put all of that in here if I wanted to have

17:47 something like that going on. And they've got a read me of just basically how to set this up. Okay. So now that I've built that, that's what's called a kit. Right? So all the code that I was

17:58 showing you there is a custom kit that I've made for deep agents. To actually set this up now, what I'm going to do is I'm going to run sbx run deep agents. I'm going to basically tell it the

18:10 folder that I want it to create in. So I'm actually in a folder called my deep agent here, right? So that's what the dot is there. Then I pass in the URL to the kit, right? So that kit is under my

18:23 docker sandboxes and there's the deep agents kit there. You'll see that when I run this the first time, it would download any images etc that it needs to do that. In this case, because they're

18:36 shell, I've already got them. I've already used this for other projects, etc. It doesn't need that. What it is going to do though is that it's going to set up the actual folder. It needs to

18:47 install Python. It needs to install those packages. It needs to create the virtual environment. So, you will find that it will take a minute or a couple of minutes to actually get this going

18:56 the first time. Sure enough, it's just done. Hopefully, you saw all of that that it basically set it all up and then it has run that script that we saw before that was setting up a deep agent

19:10 in there. And you can see that okay this is what we're actually running. We can see if we chat to this because we've already got our open router set globally the deep agents is able to use that.

19:23 It's actually proxying through and using it. So if I run this off I should be able to get it so that it's talking to deepsek version 4 flash latest. You can see sure enough it's saying hi you're a

19:35 coding assistant ready to help out. Let's see. Now we've got everything locked down, so it shouldn't be able to do any sort of searches or anything like that. Let's just try this out. Okay, so

19:46 I'm asking it, can we search Google for the latest AI news? And even if it's going to try and ping one of the URLs there, it's going to come back and it's just saying, look, I'm sorry, but I

19:58 don't have the ability to search the web. Here's what we're working with. So the file systems is actually limited in here. That's what we put in there. What we can do, you can see network access

20:10 says in this sandbox is restricted to just open router.ai and local lm studio. So it can't get out of the sandbox in here. If I ask it to give me a list of files in users, it's

20:24 going to go through the same process and realize that even though this time it's got reading tools and writing tools and editing tools, even though it's got those tools, you can see here that it

20:36 basically found out that there are no files accessible in this environment at all cuz we've just set up the environment, right? So, it says that it checked users, found it empty, slash,

20:46 all these things. really it doesn't have access to any of those on my Mac. So, it can't find them. It can't do anything with them in here. So, you can see this is how I can lock this down. At any

20:58 point, if I want to get out of it, I can just exit just like normal. And now that I've got it set up, I don't even need to refer to the kit or anything again. If I want to run it, the way it's set up is

21:08 that it's using the kit name plus the folder name to create the actual name of the sandbox in here. But you can see that now I've got that. I can run this and it just goes straight into it really

21:19 quickly. So I don't need to worry anything about it having to set everything up again each time and stuff like that. I can now just go in and I've now got this deep agents agent in a

21:32 totally secure sandbox where I could have it running lots of different tools, having a scratch pad, having the ability to write things into its local file system, but not having to worry about it

21:46 going and messing up things from my entire computer, etc. So just to finish up, I would say Docker Sandboxes is really something you should be using on any machine where you want to confine an

21:59 agent, whether that's a coding agent, which is the sort of most common examples that they're showing out there, but also custom agents. If you want to build a custom agent and you want to

22:11 make sure that it's locked down, that you don't have to worry about it doing stuff. And the cool thing is just like I showed you there, I can have that deep agents agent just talking to LM Studio.

22:22 So it can still use the local model that's on my machine. I could give it access to something like Tavilli or to Duck Duck Go search. I could give it access to certain websites that I wanted

22:34 to pull information from. And I could just run that 24/7, not having to worry about is this going off the rails and suddenly starting to wipe things on my drive or running up a huge bill, etc.

22:48 Because in that case, the model would be totally local, etc. So, we all know that security is a key issue with agents. This basically just solves a lot of the problems in a very simple and elegant

23:02 way that you can use for a variety of different things. whether that's coding agents, whether that's your own agents, etc. So, let me know in the comments if you've checked this out. All the links

23:12 for all of this will be in the description. It's very easy to set up. You can try it out yourself. And let me know in the comments what you think. Anyway, as always, if you like the

23:21 video, please click like and subscribe. And I will talk to you in the next video. Bye for now.

Frontier News · by Hyperjump Technology