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

131–140 of 450 posts

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

#131

Post by eli »

espadrine wrote: post #125

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

That incident was with a model that had the guardrails disabled.

Still obviously you should run all untrusted code in a sandbox, but extreme actions like that would be very unusual with the model that shipped.

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

#132

Post by weinzierl »

TheRoque wrote: post #121
weinzierl wrote: post #111

Earlier quoted context omitted.

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 ?

Container escapes are more common than you think. Common enough for AWS not to rely on containers for their serverless functions, common enough for Google to say: "Untrusted code shouldn't rely on the container security boundary [..]" [1]

The same is not applicable for any kind of sandboxing for two reasons:

1. The boundary is in the kernal’s own code, enforced by the thing you are trying to be protected from. -> Use a VM

2. The kernal is a gigantic attack surface -> Use gVisor

[1] https://docs.cloud.google.com/kubernetes-engine/docs/resourc...

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

#133

Post by SwellJoe »

d2p wrote: 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 still create and manage containers of its own using podman's rootless mode, etc. It's nearly instant to start because it's just a namespace (plus a few copied files for the container support and session history); no container needs to be built/fetched/updated/whatever. bubblewrap is extremely well-tested as it is used by flatpak and several other large projects, so I trust it quite a bit (more than I trust Docker).

https://github.com/swelljoe/flar

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

#134

Post by eli »

rusch wrote: post #100
throwaw12 wrote: post #88

Earlier quoted context omitted.

I havent used nor gondolin neither docker's solution, but curious to know what gondolin is missing (evaluating both for my personal use)? is it only the DX or something else, if DX, can you what exactly is missing? thanks

Yes, the stated "target workload"[0] is not what i'm looking for. I want my agent to run for long, spin up dedicated local stack while developing etc. It seems with gondoling i need to explain the agent to run commands in the sandbox, but then where does the agent run itself? [0]: https://earendil-works.github.io/gondolin/workloads/

You can run the agent in the gondolin sandbox if you wish.

Their example implementation with pi uses a pi extension so that pi runs on the host but the read/write/bash/etc tools run in the guest. Doesn’t have to be that way though.

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

#135

Post by eli »

_ink_ wrote: post #87
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…

Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?

It’s injected into an outbound api call, not into an env var the agent can read.

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

#136

Post by SwellJoe »

stefanka wrote: post #55
hokkos wrote: post #39

Wow, 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)

What about bubblewrap? It also provides a sandbox

Yes, bubblewrap is superior to Docker for this. I wrote a tool to use bubblewrap for the purpose. It needs a tool to start it, or is at least much more convenient with a tool, because you need to take your session/auth data into the container, and if you want the agent to be able to start containers (agents love containers) within the container, you need some config magic mounted inside. You could manually do all that, or do it with a shell script, as well. But, this is how I did it, and you're likely to run into all the same little quirks I ran into:

https://github.com/swelljoe/flar

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

#137

Post by petesergeant »

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…

What specifically do you want? I have:

https://github.com/pjlsergeant/byre -- slightly different security model, but lazer-focused on developer experience; my daily driver and I love it not just because I wrote it. The TUI is great for configuring and setting up instant boxes just how you want

https://pleasedonotescape.com/ -- a list of every other agent jail I could find, filterable by open-source and whatever else you want

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

#138

Post by duxuev »

d2p wrote: 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 also hit the same issue recently. No Linux and no Windows on arm. AI sandboxing has a lot of options but none feel complete just yet. It's hard to commit to something, especially if reviewing tools to aide in company policies.

Regardless, I'm hoping something that isn't behind a login screen is going to win out.

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

#140

Post by defraxi »

sureglymop wrote: post #72

What is the main benefit over doing something like: docker run --runtime krun --rm -it -v $(pwd):/workspace/$(basename $(pwd)) -w /workspace/$(basename $(pwd)) --network restricted-net ghcr.io/openai/codex-universal:latest sh That runs the codex OCI in a qemu microvm. From what I can see, more fine grained network and filesystem access control as well as convenience?

The credentials part...

https://docs.docker.com/ai/sandboxes/security/credentials/

Post reply on HN