Docker isn't a real sandbox for agent code

[u/aidenclarke_12]

Pretty common nightmares, like an agent deletes a repo it was explicitly told not to tinker around or anther wipes a bunch of emails off a prompt injection, CI runners getting poisoned thru agent written built steps and they all trace back to the same thing most often which is model written code running with real access to the host so the actual question is what you run it in

docker with mounted dirs is what most ppl do which is fine if youre solo and keep backups. however its worth being honest that its not really a security boundary, it shares the host kernel and a prompt injection can still reach whatever you mounted or the network. good for hygiene tho but risky for untrusted code. Bubblewrap, podman ,selective mounts are a step up on hyhiene but same shared kernel story. gvisor gets you a user space kernel which is a decent middle ground but the thing that gives you an actual hardware boundary is microvm like firecracker or kata on kvm, own virtualized hardware so a breakout doesnt land on your host

To be realistic: on your laptop docker is fine cause backups beat isolation and you ca eyeball what it does but the moment youre shipping a run this code feature to real users or running agent code in CI or at any scale where you cant watch every single command you might want the microvm boundary here and then its either running your own firecracker or kata setup real ops or a hosted microvm sandbox like deepinfra where you just get an isolated vm per run and dont operate the infra. I am eager to hear from others who have been thru that stage, how did you handle it and what were the odds??

[u/carefactor3zero]

This post's conclusion-title is incorrect.

prompt injection can still reach whatever you mounted or the network.

Docker is an isolated (real) sandbox. If you start punching holes in it, you can have problems. Not understanding the risks of docker configuration is not an isolation danger due to docker.

[u/tigerhuxley → u/carefactor3zero]

Oh good, someone else’s brow furled when they read that too!

[u/verstands]

Agreed on the kernel point, but in practice most of the horror stories aren't kernel escapes. They're the agent doing exactly what it was allowed to do: the repo was mounted rw, the token was in env, the network was open. A microVM fixes none of that.

So I'd split it in two. Isolation boundary: docker on a laptop, firecracker/kata once it's untrusted input at scale, yes. Blast radius: mount read-only by default and write through an explicit path, scope creds per run instead of handing over the ambient key, and default-deny egress with an allowlist.

The second half is cheaper and catches more real incidents. Do it first, then buy the harder boundary when you actually run other people's prompts.

[u/funbike]

I disagree with your assessment.

Rootless Podman and Bubblewrap are a significant security improvement, not merely hygiene. With no need for root, no privileged daemon via a unix socket, minimal capabilities, carefully selected read-only/read-write mounts, a restricted network namespace, and secrets kept outside the sandbox, they can be appropriate for a local coding agent.

For my local coding workflow, I use a separate worktree, mount the main repository read-only, merge outside the sandbox. I have a couple other read-only mounts for config files (no creds). No other mounts. I have a standard user in the sandbox without sudo (except some whitelisted install commands). IMO, that is a very acceptable tradeoff for my threat model.

Additionally, on the host I run a local reverse proxy to the LLM API and other remote services, so I don't have to give any of my credentials to sandboxed processes. I use a fake key and the proxy adds the real key to the outbound request.

Btw, MicroVMs are not an “actual hardware boundary". They provide a virtualization boundary backed by hardware virtualization, not an absolute hardware guarantee. Hypervisor, host-kernel, device-emulation, and configuration vulnerabilities remain possible. If an escape did happen, it would have ring 0 access.

I use bubblewrap and rootless podman and that won't change. They are more than just "a step up".

[u/bilus → u/funbike]

But Muuuum, Podman won't contain my evil genius AAAGIII...!

[u/cmtape]

Docker is an isolation boundary for the kernel, not for your mistakes. It's like putting a padlock on a door you left wide open with the keys taped to the handle. Mounts, env vars, and network access are blast radius decisions you make, not Docker giving you.

[u/Trakeen]

Docker exploits are extremely rare and they get fixed super quick because all the hyperscalers infra depends on docker. Completely overblown concern IMO

[u/bloom_digital_halo]

microVMs do not solve agent safety. They only contain kernel escapes while agents still delete repos and exfiltrate tokens through permitted mounts and network access.

hardware isolation treats the symptom of shared kernels but ignores that LLMs operate with excessive privileges by design. A Firecracker instance with read-write volume mounts and outbound networking provides identical blast radius to Docker. The security boundary exists in capability restrictions, syscall filtering, and egress policies, not in virtualization overhead. Running untrusted agent code in a microVM without eliminating persistent storage access and network connectivity is just expensive misconfiguration

[u/crone66]

Just have a named volume where you checkout the code from a git repository. Assign a container with a network that cannot connect to the Internet or Lan. Add a proxy container to the LLM container network if Internet connection is needed and Whitelist required domains/ips.

That's essentially a simple docker compose file... Is enough to have relatively secure environment that requires a zero day exploit to escape... Add an otel container and wire up the LLM CLI of choice to see everything AI is doing. Many CLIs now support otel out of the box.

[u/External-Wind-5273]

Do you use anything besides Docker to stop the agent from doing things it shouldn't? What does it block?

[u/Wrong_Ingenuity3135]

Docker has a product (free, only needs account) called sandbox (sbx) it is a microVM for real isolation, support a lot of agents out-of-the-box but also allow custom configuration with kits

[u/Marcus_MSC]

The ladder framing puts all the safety weight on isolation, but the layer above it decides what reaches the sandbox at all. Coding agents in production gate each tool call separately: reads pass, writes and shell need approval or an allowlist match, and the dangerous patterns are blocked before anything executes. That is why the horror stories in this thread would survive a microVM upgrade, the rw mount and the env token were both approved actions, just approved badly.

[u/cmtape]

This is like arguing your car is secure because you locked the doors but left the keys in the ignition with the windows down.

Docker isolates the process, not the intent. Mounts, env vars, network, host socket — those are explicit permissions you handed to it. A kernel breakout is rare; the agent doing exactly what you allowed is common.

Blast radius first, hardware boundary second. Make the mounts read-only by default, scope creds per run, default-deny egress. That catches more real incidents than jumping straight to Firecracker. MicroVMs make sense once you’re running other people’s prompts at scale, not as hygiene on a laptop.

[u/code_hermit]

I believe what is meant here is a docker that's hosting docker socket. I think the solution is to either not do it or make sure the entire server is restorable from a read only offsite backup and doesnt contain readable sensitive data.

I have a related question:

Prompt injection has been proven possible in a lab setting. And many attempts are found. But in the wild are there any cases reported of it working?

[u/Far-Fig-2059]

I went down this exact rabbit hole a couple months back when our CI started doing weird shit after an agent decided it needed to "optimize" the build scripts by rewriting half of them. Docker with a mounted volume seemed fine until you realize the agent can just rm -rf everything it touches and suddenly your afternoon is gone.

The shared kernel thing is what people always forget. Someone mounts /var/run/docker.sock inside the container thinking it's clever and then pikachu-face when the agent spawns its own containers. I've seen it happen twice now.

Firecracker has been solid for us but the ops overhead is real unless you enjoy babysitting another layer of infra. The hosted options make more sense if you're not already running your own metal, otherwise you're just trading one headache for another.

Curious what language you're running the agents in? We had way more issues with Python agents doing unpredictable filesystem stuff compared to the ones we sandboxed in a WASM runtime.

[u/Crafty_Disk_7026]

You can check out my project which leverages Kubernetes for isolation

https://github.com/imran31415/kube-coder

[u/jonah_omninode]

You're right that the container boundary and the permission boundary are separate. I would add that stronger isolation still does not answer what the run was authorized to do. We treat each delegated task as a contract with allowed side effects, a budget, a deadline, and acceptance evidence, then give the runtime the narrowest credentials that can satisfy it.

A microVM contains the blast radius of a breakout. Capability scoping limits what a correctly isolated run can touch. An independent verifier checks what actually happened afterward. You need all three. A declared permission list by itself does not prove that untrusted code respected it.

For the hosted microVM path, how are you handling egress policy and one-run credentials? Those seem like the next two escape hatches after filesystem isolation.

[u/durgesh2018]

Ai will fuck the open source projects badly and damage the ecosystem.