# Source notes — Docker Sandboxes AI Agent Guide

- Video: [Docker Sandboxes Hands-On Guide – A Safe Space for AI Agents!](https://www.youtube.com/watch?v=kNGXuIPXR24)
- Channel: [Bijan Bowen](https://www.youtube.com/channel/UCOCahKBCEUuzDJawM7yN1dg)
- Video ID: `kNGXuIPXR24`
- Duration: 25:08
- Upload date from metadata: 20260522
- Transcript segments: 733
- Local transcript: `/Users/alanwheat/.hermes/guide-publishing/youtube-kNGXuIPXR24/transcript.txt`
- Local metadata: `/Users/alanwheat/.hermes/guide-publishing/youtube-kNGXuIPXR24/metadata.txt`
- Retrieval date: 2026-05-23

## Video chapter map from description

Timestamps:

00:00 - Intro
00:31 - First Look
01:46 - Setup Overview
05:15 - Network Access Look
06:29 - Sandbox Agent
08:05 - Sandbox Creation
10:00 - Sandbox Function Demo
11:36 - Network Access Policy Demo
15:18 - Local AI Sandbox Demo
16:54 - Local AI Sandbox Config
20:51 - Local AI Sandbox Demo
22:34 - Closing Thoughts

Get started with Docker Sandboxes: https://dockr.ly/43hl5vT

In this video, we take a first look at Docker Sandboxes, exploring how they can be used to create safer, isolated environments for AI agents and local AI workflows.

We begin with a setup overview, then walk through sandbox creation, agent behavior, network access controls, and sandbox function demos. We also test how local AI can be integrated into sandboxed environments and configured for safer agent-style workflows.

## Official/supporting references captured

- Docker Sandboxes get started: https://docs.docker.com/ai/sandboxes/get-started/
- Docker Sandboxes usage: https://docs.docker.com/ai/sandboxes/usage/
- Docker Sandboxes policies: https://docs.docker.com/ai/sandboxes/security/policy/
- Docker Sandboxes isolation layers: https://docs.docker.com/ai/sandboxes/security/isolation/
- Docker Sandboxes default security posture: https://docs.docker.com/ai/sandboxes/security/defaults/
- Docker Sandboxes Codex agent: https://docs.docker.com/ai/sandboxes/agents/codex/
- Docker Sandboxes credentials: https://docs.docker.com/ai/sandboxes/security/credentials/
- Codex CLI official docs: https://developers.openai.com/codex/cli
- Homebrew: https://brew.sh/
- Docker sbx releases: https://github.com/docker/sbx-releases/releases
- Docker Personal Access Tokens: https://app.docker.com/settings/personal-access-tokens
- Git worktree docs: https://git-scm.com/docs/git-worktree

## What the video contributed

- Practical first look at Docker Sandboxes for AI agents.
- Mac-oriented setup path using Homebrew and `sbx login`.
- Recommendation to choose Balanced network policy for a normal first run.
- Codex agent demo, with `sbx secret set -g openai` and `sbx run codex`.
- Side-by-side filesystem isolation demonstration: host terminal sees many files; sandbox sees only mounted workspace.
- Network policy demonstration: a ping/script that runs on the host is blocked/logged in the sandbox.
- Local model demo with LM Studio running on host localhost/port 1234 and an sbx policy rule to permit the sandbox to reach it.

## Transcript excerpt

```text
Today we're going to be taking a look at Docker sandboxes, which as the name may be indicative of, is a sandbox for our AI agents to be able to work from within, which will allow them to perform actions safely, but non-destructively as opposed to having full access on our native host system. So this is a very interesting tool and it really does coincide with what is being spoken about right now pretty frequently in some of the AI and security circles which is just the whole concept of AI and its impact on cyber security as a whole. Now, with the recent introduction of the Claude Mythos model, which is potentially looming on the horizon for folks who are not handpicked to be able to use, but don't quote me on that cuz I cannot confirm or deny that. There has been a ton of folks talking about using AI for cyber security purposes. But a broader theme is just talking about what form of accessibility or capabilities we allow them to have on the systems that we're actually running them from within. And this is the whole thing that Docker Sandboxes is designed to approach, which is giving our agent full access. So, as we scroll down here on this page, we're actually going to see the concept of this yolo mode or something of the sort, where this is designed by nature to actually allow our agents to autonomously perform all of the actions that they otherwise would want to were they in a dangerously skip permission state or something of the sort. So, this is designed to allow us to not have to babysit and click approve every time the agent actually wants to perform an action, which depending on how much you use them can definitely be kind of tiring to have to deal with. But in a safe environment where we are the guard rail, we are basically telling it what it is allowed to access. And there's a whole bunch of other security things that we'll touch upon related to this here, but it's really just an interesting feature to have. And for today's video, we're going to be testing it on a Mac computer. Now, before we go any further, I do want to say that this video is sponsored by Docker. So, thank you to Docker for one, supporting the channel, and two, having an exemplary taste in content creators, if I do say so myself. But more seriously, it is really quite simple to actually get started with this. So, as I may have mentioned, we are going to be working on a Macintosh system today. This is also prominently listed here as working with Windows, but if we go into the docs, we see that it also does have Linux support as one would expect it to. Though, because we are on Mac, we are going to be focused on the Mac installation command. And really, this is not going to be as much of an installation tutorial as it is just a quick runrough of the setup. Partially because this is just really extremely easy to actually install and set up. It does culminate in just running one specific command right here. I do apologize for the um rather not attractiveness of my terminal here, but this is the one hangup that we may see if you are on a Mac that does not have Brew installed on it. If you go to run this command, you are going to be met with this issue where brew is not found. So I did just want to showcase that so I can explain to folks how to get past that so then we can get started with our sandboxes. So if we encounter this issue here where brew is not on our system and keep in mind this is only going to be a Mac OS specific issue that we would encounter right here. It is really simple to rectify. We will just go to brew.sh this website right here. And from there, there is a single line command that we will go back to our terminal and enter here, which will basically handle all of the prerequisites for actually using this on Mac OS, which is kind of cool. Now, interestingly, you don't actually even need Docker Desktop installed to use these sandboxes, which I just find cool as it's simplifies the installation process, I suppose could be said. So, now that Brew has been installed, our next step is to go back here to the Docker page and just copy paste this command back into our terminal. You can also just use the up- down arrow keys to cycle through previously entered commands if you would like. And we now see that our sandbox installation is currently in process. And after a short bit of time, we will see that SBX was successfully installed. SBX referring to the Docker sandboxes, of course. So our next step here is really quite simple, but it does culminate in something that I would make as a suggestion to anyone interested in doing this themselves, as this is not really fully like a walkthrough tutorial. The documentation for this is pretty verbose in a good way. So it gives you a lot of specific information about using this. I would very much suggest that anyone interested just read through the documentation here. It is just this specific like area in the doc. So if we do this drop down arrow right here, all of these things and up are specific to Docker sandboxes and it just gives you a good bit of information about specific things for setup and what kind of agents we can configure and things of that sort. So, I suppose the only other real prerequisite here is that you do need to have an account and you need to be able to authenticate just through the SBX login command right here, which I am going to do. There's not like a paid thing or anything like that. You just sign up and then that works. Now, okay, so I do have Chrome. Uh the default browser on this system is Chrome. But the thing that we're going to notice that I did want to mention before I was distracted by a different browser opening is that it is going to show you a code right here to have you verify that this is also what is appearing in the terminal or referred to as a one-time device confirmation code. So I can just confirm that that this is correctly the specific code that I see. And then once you click that you will just log in with your credentials for Docker. And once you've logged in you'll just get this message that you're all set. But the terminal will then change to reflect that you have logged in. So once we've authenticated, the next thing we see is a network policy allow feature. And essentially what this is is we can choose from the most open to the most stringent lockdown variation of the network policy for the sandbox. Really the simplest way is to just go to the specific policy page. Right here we can see that open will just allow all outbound traffic. Balanced is default deny, but it has an allow list for a bunch of common things that would be related to what the agent in our sandbox may specifically need. things like AI provider APIs, package managers, etc. You can also modify this policy by just allowing specific domains that you would then whitelist. And then finally, we have locked down where all outbound traffic is locked including model provider APIs. So this would be something um you would need a special use case for that because you would not really be able to have this thing even confirming that the API key is good for the specific model agent that you are using. because I do want to just stick with the default one for now. I am just going to choose option two which is balanced. And once we do that, we can see that okay, we get a little bit of feedback here just saying if you want to change things or whitelist things, you can do this. Our next step following that is to actually run one of these sandboxes but with a chosen specific agent. And we'll get into that now. So our next step before we actually start a sandbox is essentially to define what specific agent we're going to be using with that sandbox. Now, if we click on agents right here linked in the documentation, we're going to see that there are a bunch of different configurations depending on what specific coding agent we're going to want to run in the sandbox. So, if I was to use Claude code within the agent sandbox, basically allowing Claude from within the sandbox to run with dangerously skip permissions enabled, or as they referred to it back in the introductory page, YOLO mode, we would select the Claude code sandbox. However, for today's video, I am going to be using an open AI model. And because of that, I will be selecting the codeex option for my sandbox agent. And if we click on that, we just get a bit of pertinent information in how to specifically set up this agent, which I will be following now as that is the one I would like to use. To begin, we would just type SBX run codeex. And then you could point it to a specific directory as well. But prior to that, I need to actually get my API key here hooked up so that the model actually works and has access through the open AI API. They do have a couple of different options for doing that here. You can just use this command to set your credential right here from within the terminal. Or you can do the export open AI key equals in the shell session tha
...
```