Live data from Hacker News

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

231–240 of 420 posts

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#231
post #58

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…

what about coder (and coder workspaces)? https://github.com/coder/coder

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#232
post #117

Does 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…

bubblewrap may work well for you and your specific workflows/projects but not in an enterprise setting where everyone already has a different setup on the host and needs something different inside the container. It's impossible to deploy a solution like that with bubblewrap -- configuration itself is going to be a nightmare. Which is why Docker Sandbox is aimed at teams/enterprises.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#233
post #44

Earlier 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

Sure, but all projects are version controlled? You only mount the project dir so you can only loose your current changes - which is the same if you copy...

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#235
post #199

Earlier 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.

The AI launches new kernel bugs as matter of course.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#236
post #99

The 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.

As you as your Go build fails because you haven't put the local cache dir in the "allowed directories", you'll understand how painful this is, as well as most tools based on bubblewrap/sandbox-exec. There is a difference between a clean environment with standard setup vs a layer on top of everyone's existing tools/setup, especially in a enterprise environment.

(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

#237
post #58

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…

maintainer, I would recommend trying out: https://github.com/smol-machines/smolvm It has network filtering + placeholders for secrets. OSS, no logins needed

There's also microsandbox which has similar features: https://github.com/superradcompany/microsandbox

(Not affiliated with them, just tried it out last week.)

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#238
post #199

Earlier 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.

There were not the solution for a while now, that is why Kata containers came to be in first place.

Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents

#239

Earlier 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".

LLMs are great at finding 0-day, and people are rubbish at updating their containers and hosts to patch b-day.

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

#240
post #199

Earlier 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.

> 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.

Post reply on HN