The 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…
Docker Sandboxes – Disposable, isolated sandboxes for AI agents
231–240 of 416 posts
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#232Does this support Linux yet? When I previously looked it did not (the reason being that they were already using VMs on Windows/macOS but not on Linux). Every time I see an announcement I think "great, they must've added Linux now then", but the linked pages always have Windows + macOS instructions but not Linux. All the open GH issues about supporting Linux that I subscribed to have gone unresponded to. OpenShell loo…
I think Linux has a better solution than Docker. I wrote a tool to use `bubblewrap` to containerize any agent (at least all the agents I've used a couple of times), and bind mount the system stuff read-only, so the agent has your "usual" environment, but they can only see the project. Their history persists (either through a bind mount or a "shadow" copy of the history that only the wrapped agent sees), the agent can…
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#233Earlier quoted context omitted.
What is the advantage of copying rather than a bind-mount?
"Oops I deleted everything under $FOLDER – that mistake is on me" doesn't kill it on your host system
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#234Finally, a way to run --dangerously-skip-permissions without having a mild heart attack every time the agent decides to rm -rf a mystery directory.
'su agent'
'curl domain/install.sh | sh'
'runagent'
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#235Earlier quoted context omitted.
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
#236The other day I saw this: https://nono.sh/ Haven't tested it yet, but it seems to address the same issue as Docker Sandboxes, but in a different way.
I have tested it and the big advantage is that is has access to the local development tools. But it’s not as well sandboxed for sure.
(I'm sure you can spend time to come up with a proper bubblewrap configuration that allows go build to succeed, but it's probably not worth the effort.)
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#237The 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…
maintainer, I would recommend trying out: https://github.com/smol-machines/smolvm It has network filtering + placeholders for secrets. OSS, no logins needed
(Not affiliated with them, just tried it out last week.)
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#238Earlier 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.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#239Earlier quoted context omitted.
Oh no, you should definitely be worried about that. Podman might make it harder to escalate to host root, or manipulate other containers, but it is still vulnerable. Now I'm curious to know how hardened the Docket Sandbox orchestration interface is. I guess we can assume they have run Mythos against it for a few weeks maybe? It's unclear.
BS. Unless we're talking 0-day/CVE, running an unprivileged container is as trustable as a VM. The only difference is how strictly you want to hold the memory/CPU bar. Infact on linux, containers are more lightweight than VMs. So yeah, not "vulnerable".
Containers have access to the kernel ABI, and as shown in the latest kernel exploits, all the memory handling surface that exposes. The virtualisation interface, offering fewer services, is significantly harder.
Containers are obviously lighter than VMs, both to start and to schedule, but firecracker is pretty fast. gVisor pays overhead per syscall vs at startup.
So yeah, more vulnerable.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#240Earlier 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.
Why microVMs? I never ever run a container, AI harness or other, in something else than a full on VM. I could use a microVM but in any case I really don't see why I'd run a container on one of my bare metal OS: the place of a container is inside a VM (or microVM).
Especially for AI harnesses where the threat of an escape is very real: the more defense in depth, the better.
And If I can use rootless Podman instead of "rootfull" Docker, the better. Most of my containers are Podman btw.
> My goto solution for this are apple/containers.
To each his own: my goto solution is an actual server on my LAN with shitload of cores and memory and plenty of scripts to provision VMs etc.
I really don't understand why people are YOLO'ing containers on their bare metal OS.