[dead]
Docker Sandboxes – Disposable, isolated sandboxes for AI agents
221–230 of 421 posts
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#222Before you use no sandbox at all use this or one the many similar projects but it's alway worth remembering that Docker is not a security boundary. It never has been meant to be and never will become one. cgroups are a mechanism designed for hierarchical organization and resource distribution. Against a malicious and capable actor, and that is how we have to treat AI agents, cgroups will not withstand. Also, the kern…
Which is fine but this thread is about a feature that provides hypervisor isolation, not cgroups.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#223The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders. I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in. Closest open source I have seen is https://earendil-works.github.io/gondol…
Isn't Nvidia's openshell exactly what you're looking for? I'm asking because I'm just learning about this stuff myself and tested openshell yesterday with pi for the first time. https://github.com/NVIDIA/openshell
I have a colleague who's using openshell. The advantage is it's independent of the containerization layer, yes?
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#224Finally, a way to run --dangerously-skip-permissions without having a mild heart attack every time the agent decides to rm -rf a mystery directory.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#225Earlier quoted context omitted.
Don't want to say it's better, but I implemented Agent Circus ( https://github.com/Embedded-Focus/agent-circus ) which allows to lock AI agent harnesses into docker containers. I'm using it as my main driver since months. Support for running agent harnesses in unprivileged podman containers is on my feature list. :-)
Docker containers are not enough isolation for anyone that cares about jailbreak scenarios. Only real alternative is to use microvms. My goto solution for this are apple/containers.
> Docker containers are not enough isolation for anyone that cares about jailbreak scenarios.
For the vast majority of developers, containers are enough, which is why they are ubiquitous while vms are less common. Ofc that ubiquity has led to lazy configuration, which is how the jailbreaking can occur. Knowing what you are doing with containers is a requirement to use containers as an AI sandbox.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#226Apple Container is an interesting work in progress: https://github.com/apple/container
I am developing a project that makes running in Apple Container (Docker is an alternate runtime for Linux) more convenient: https://github.com/gregwebs/claude-contained/
It blocks network access by default, mounts only what you specify, and you can add a customization layer. This is all done in the container itself (srt for network blocking). It doesn't implement a central point for secret sharing, MCP exposure, etc. So it might not have enough features for some but it works well for my needs.
I just found through this thread yoloai which has an apple container backend, so its quite similar using that. My main issue would be that network access is allowed by default. https://github.com/kstenerud/yoloai
Several other projects listed here use libkrun which is an alternate implementation that works with Mac's HVF. smolvm, microsandbox, podman (with likrun backend), gondolin.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#227The login is annoying but, lacking an open source alternative, this has been my daily driver for a while now because it works great out of the box with two key features: outbound firewall and secret injection with placeholders. I run it with superset and then each git worktree is mounted in a sandbox that is configured for each repo i work in. Closest open source I have seen is https://earendil-works.github.io/gondol…
I wrote one that has both of those: yoloAI (MIT, Go, single binary, no login).
https://github.com/kstenerud/yoloai
Outbound firewall is `--network-isolated`: egress is denied except the agent's own API endpoints plus domains you allow, enforced sandbox-side (working on host-side enforcement now). `--network-none` if you want nothing.
Credential brokering works the way you describe (currently Claude-only, I'll add more as time allows). The API key stays on the host, a local proxy injects it into the outbound request, and the sandbox never holds anything worth stealing. Other agents' credentials currently arrive as read-only file mounts instead (weaker, and something I'll fix soon). Generalising the injector is the obvious next thing.
One difference from your setup: yoloAI copies your worktree instead of mounting it. The agent works on the copy, you `yoloai diff`, and `yoloai apply` replays the commits into your real repo. That's deliberate. Docker's own security docs talk about the dangers of bombs being left behind in a live-mounted dir (git hooks, package.json scripts, Makefiles, IDE task config), which diff/apply avoids.
Isolation is per-sandbox rather than fixed: runc, gVisor, or Kata VMs (QEMU or Firecracker) on Linux; Seatbelt or full macOS VMs via Tart on a Mac.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#228I just made my own devcontainer that I copy on any project and load whatever harness I want in that repo. Harnesss' config and auth are simply mounted from the host, so no setup required at all. https://github.com/iodize6399/ai-devcontainer/tree/main/.dev...
yeah, I actually just re-use claude-code .devcontainer: https://github.com/anthropics/claude-code/tree/main/.devcont... I especially like the firewall it has.
I don't get how it works, or works well -- presumably those domains are behind CDNs, and IP addresses are unpredictable. So the firewall allows traffic to specific IPs that are resolved at the time the script is run, but not after that? What if the same domain is resolved again without going through the cache, and it becomes a different IP?
And even if that works, this is a very short list. As soon as you reach for Go, Rust tooling etc nothing works. So you need to manually maintain this list which is nothing but painful trial and error.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#229I don't want this that bad. I want the agent to have open access to my system because it actually does important administrative things for me. It is THAT convenient and powerful.
Here's what I want: REALTIME OBSERVABILITY/POWERPOINT.
I don't want to just see what command it ran. I need graphics... what part of the file system it is touching, what network entities it is contacting. If it's running SQL I want the parsed query handed to me in a syntax highlighted and well formatted interface. Imagine that star trek computer presenting automated infographics while someone is doing a presentation, you know what I'm talking about? It's like a automated powerpoint as the agent does it's thing.
I need to understand my agent and what it typically does so I can dangerously wield it. I treat the agent like a gun in a live shooting scenario. That's how I want to use the LLM.
Sandboxes have their purpose. Just like how shooting ranges have their purposes. But I need to fire my gun in the real world and real world is a warzone.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#230Wow, I hope one day Linux will be able to support the exclusive MacOs/Windows technology of Docker Sandboxes. (it's in the doc, but kinda strange to not see some instructions on the main page, probably distro related)
Whoah. I took for granted it'd work on Linux.