Running several coding agents with full access safely: Docker Sandboxes (sbx), a network policy, secrets kept outside, and three tests

What Docker Sandboxes are (checked)

From Docker's Docker Sandboxes documentation, read 2026-11-10: they run AI coding agents in isolated environments, locally or on Docker-managed cloud infrastructure, and are managed with the sbx CLI. The CLI and local sandbox compute are free, including for commercial work; cloud compute is pay-as-you-go. The docs have separate guides for installing, configuring secrets, network policies, running agents and the CLI reference, and those are the place to get exact command syntax: the captions of the video garble the commands, so we do not reproduce them.

The three tests he runs

1. Its own machine. He sets the agent to full permissions inside a sandbox (a named sandbox with its own clone of the repository). Asked to show its home folder, the agent shows the sandbox's, not his. Told to delete every file in the project, it does, and his laptop is untouched, because the agent only ever had its own copy.
2. Its own allowed websites. He picks a network policy; the "Balanced" policy allows common developer services such as GitHub and npm and blocks everything else. To simulate prompt injection (a package telling an agent to send your .env to a website), he requests an attacker URL: 403 from inside the sandbox, 200 from his own machine. The tool lists every site the agent tried to reach and whether it got through, and you can allow a new site on purpose.
3. Its own keys. He stores a GitHub token as a sandbox secret rather than in the sandbox. Inside, the token variable shows a placeholder, yet GitHub still recognises him, because a proxy on his machine adds the real token on the way out.

His reasoning for a micro VM over a container: a container shares the host's kernel, and an agent that needs Docker itself can end up with control of the host. That is his argument; check Docker's security guide for the exact isolation model.

The team and the build

• Orchestrator. A lead (a CTO agent) and one developer, extendable. You give the lead a project phase; it reads your docs, splits the work into tasks and asks only what the docs do not answer, with a recommendation for each. Its desk turns red when it needs you. Actions that must happen outside a sandbox (creating an account, adding a key) land in an "action items" list with exact steps.
• Parallel work. Two agents on one codebase can break each other, which he calls the hardest part; the team shares a task board with owners.
• Shared memory. Because every session starts empty, the project gets three context files that every agent reads at the start of each session.
• Production keys. Agents build against a development database project, so production keys never go into a sandbox. Pull requests go through an automated code review before reaching main.

Caveats

• The exact sbx commands, policy names and flags in the video are unverified here; use Docker's CLI reference.
• A sandbox protects your machine, not your accounts: anything you put in a sandbox as a secret can still be used through the proxy, and the sandbox can still reach every site its policy allows.
• The Replit and Gemini CLI incidents he cites are described as he tells them and were not checked.
• JSM Headquarters is the creator's own free, open-source project; we have not reviewed it.