I work at Docker. Lot of valid and useful feedback here that we're looking closely at. One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more effective across platforms. Explained a bit more here about the architecture and why those choices were made: https://www.dock…
Docker Sandboxes – Disposable, isolated sandboxes for AI agents
391–400 of 434 posts
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#392Earlier quoted context omitted.
Ooh - can you share more about your setup with superset? I tried getting it integrated with superset a while ago with no dice.
Currently running codex. I run one sandbox per repo. So I create the sandbox in the repo root. Then it's a custom terminal preset: sbx run --name "yoursandbox" -- --cd "$PWD" This boots a sbx session in the worktree directory. For Claude there is no --cd so it's more hacky, but I solved it by creating a sbx kit with entrypoint script that reads a flag (e.g --cwd) from the terminal preset command and then inside the s…
Def makes integrating easier but I try to avoid using direct mode for security (exposes .git folder, though there's probs a better way to protect it by disabling hooks or something)
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#393Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#394How do you solve the issues of private key sharings that are stored in cwd .env? I haven’t found a satisfactory way to preserve them while letting the agent have access.
Stop putting sensitive stuff there.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#395Earlier 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.
I'm not sure where "vast majority" cuts in but I would say a huge number of developers use docker and it is inconvenient at best if your AI harness can't actually run and test the infra it is building against
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#396I work at Docker. Lot of valid and useful feedback here that we're looking closely at. One correction: this isn't containers. Each session is a microVM with its own kernel on the platform's native hypervisor: Hypervisor.framework, WHP, KVM. We wrote a new VMM (not Firecracker) to make it more effective across platforms. Explained a bit more here about the architecture and why those choices were made: https://www.dock…
Concept is great - works quite well - I often have multiple short lived sandboxes running at once.
Docs [1] on overriding auth are incorrect. Sbx ignores inject[].username for basic auth and instead the stored secret needs to be the complete Authorization header. This should be made clear, or fixed.
Having to log in every couple of days SUCKS!! Opening the browser so I can login (which we shouldn't have to do) interfers with my scripts that create and destroy sandboxes as I need them.
I miss the old worktree functionality - I dislike the new clone concept - So I've created my own scripts that create a worktree for a feature, and run sbx create/run from there.
[1] https://docs.docker.com/ai/sandboxes/customize/kit-reference...
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#397Earlier quoted context omitted.
Your agent writes secret.txt with the placeholder, and the tokenizing proxy replaces it with the token, then the agent reads secret.txt
It only replaces the token in the HTTP header that is sent to the server. Whatever you wrote in your files isn't touched by the proxy.
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#398- They can securely consume ANY service of ANY cloud without needing credentials - They can securely communicate to any VPC or private network resource - When you're ready to go to prod - you simply deploy to the Global Virtual Cloud (GVC) which can run in one region, multi-region, hybrid, any number of regions and clouds and data centers.
our website is https://controlplane.com
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#399The 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…
Re: Docker Sandboxes – Disposable, isolated sandboxes for AI agents
#400Earlier quoted context omitted.
What is WHP?
Windows Hypervisor Platform, to my understanding. https://learn.microsoft.com/en-us/virtualization/api/hypervi... https://www.qemu.org/docs/master/system/whpx.html