Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker Sandboxes – Disposable, isolated sandboxes for AI agents

docker.com

Post reply on HN
Print view View original

121–130 of 450 posts

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

#121

Post by TheRoque »

weinzierl wrote: post #111
TheRoque wrote: post #96

Earlier quoted context omitted.

Would you say podman is better, or is it the same as docker ?

In general running containers rootless is better from a security standpoint and podman makes this much easier. So, yes. This is not my main point though. Both are based on cgroups and cgroups are the wrong tool for the job.

Wouldn't it need a super critical exploit, I mean zero-day vulnerability, to escape from that kind of sandbox ? And if you think further, then isn't that risk also applicable to pretty much any kind of sandboxing ?

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

#122

Post by huflungdung »

TheqO wrote: post #115
Grimburger wrote: post #37

> Each agent runs inside a dedicated microVM with your dev environment What's a "microVM" and what's the security model here compared to using real virtual machines with actual constraints on breakouts? Is it marketing fluff? Incus/LXD has had VM's for a long time now. incus launch images:ubuntu/26.04 my-ubuntu-vm --vm incus exec my-ubuntu-vm -- bash

There are many devs that have little to no experience of Linux, like the hundreds of thousands of .Net and Java CRUD devs in enterprise companies using Windows. There is a need for a Docker desktop like GUI for this market.

[dead]

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

#123

Post by speedgoose »

dethos wrote: 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.

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

#124

Post by mihaelm »

eloisius wrote: post #84
angry_octet wrote: post #74

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.

Unsettling. I mean, is there any reasonable way to develop software in 2026? I've already sworn off ever installing npm directly on my host. Containerizing everything is laborious enough, but running a separate VM for everything?

You just need to work out the threat model for what you're working on. For trusted containerized workloads, where the attack surface is minimal, just containerization is fine. However, agents can do just about anything on your computer if you allow it and people aren't really shying away from `--dangerously-skip-permissions`, so better hardening (VMs, microVMs) is desirable.

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

#125

Post by espadrine »

Models start going to extreme, damaging lengths to achieve ambiguous prompts[0]. Having good sandboxes is now a must IMO.

But sbx is a bit annoying to use with OpenCode for instance (which has zero sandboxing by default, unlike codex CLI or Claude Code). You cannot easily change ~/.config/opencode/opencode.jsonc AFAIK.

[0]: Black Hat OpenAI-Hugging Face incident: https://www.youtube.com/watch?v=87DyyMV0kCY&t=1021s

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

#126

Post by dist-epoch »

Grimburger wrote: post #37

> Each agent runs inside a dedicated microVM with your dev environment What's a "microVM" and what's the security model here compared to using real virtual machines with actual constraints on breakouts? Is it marketing fluff? Incus/LXD has had VM's for a long time now. incus launch images:ubuntu/26.04 my-ubuntu-vm --vm incus exec my-ubuntu-vm -- bash

An Ubuntu Server VM, like the ones started by Incus, use at least 512 MB of RAM per instance. If you spawn 10 sandbox VMs, you already pay 5 GB RAM just to sit there idle. You also pay a CPU cost, you have 10 kernels managing stuff, but arguably it doesn't matter that much given CPU core counts.

I use something in between - a single Ubuntu VM, into which I spawn multiple Incus LXC containers for the agents. The containers only use 50 MB or so per instance (separate systemd, ...). This way I pay the VM RAM tax only once, and the agents are still contained inside the VM if they manage to escape the LXC containers.

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

#127

Post by GZGavinZhao »

I'm confused: 1. If I run this on Mac, then inside the sandbox / microVM, am I still running MacOS or some Linux distribution? 2. If the only thing that's mounted from the host is the $PWD, how does it guarantee that it has all the system libraries that I have installed on my host system? e.g. my `/opt/homebrew` libraries or `sudo apt install libfoo-dev` headers

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

#128

Post by dist-epoch »

jsiepkes wrote: post #118
masklinn wrote: post #108

Earlier quoted context omitted.

“microvms” are real vms but the hypervisor and vm (guest kernel) shed most of the hardware / device emulation, support, and discovery which makes traditional VMs look / feel like real computers, as well as most guest interactions. This gives them extremely low overhead. Firecracker is designed to start a VM in under 125ms and 5MB. Netbsd advertises that you can direct-boot a MICROVM kernel configuration in under 10ms…

If an agent fires up NPM, takes a boatload of memory, is that memory released back to the OS after NPM shuts down in the VM?

In principle yes, in practice it's complicated, using something called "balloon drivers"

https://en.wikipedia.org/wiki/Memory_ballooning

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

#129

Post by reddec »

binsquare wrote: post #98
rusch wrote: 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

I've put some effort to integrate it to my agentic workflow. The problem, however, with docker in smolvm: it work-ish (there is example), but quite hacky. Another problem which I wasnt able to solve - persistent image without Dockerfile. CloudInit will be ideal.

Documention at this moment in an early stage.

Overall, its a great project but for me was simpler just use Virtual Machine Manager (libvirt GUI).

I wish all luck to the maintainers, but probably DX-wise I will prefer to have more granular or predictable controls (eg micro cloud from Canonical).

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

#130

Post by masklinn »

dist-epoch wrote: post #128
jsiepkes wrote: post #118

Earlier quoted context omitted.

If an agent fires up NPM, takes a boatload of memory, is that memory released back to the OS after NPM shuts down in the VM?

In principle yes, in practice it's complicated, using something called "balloon drivers" https://en.wikipedia.org/wiki/Memory_ballooning

There’s also memory hotplugging via virtio-mem. But generally speaking downscaling live vm memory can’t be said to be a solved problem, it’s more of an active area of research.
Post reply on HN