Source: Docker Blog — Oleg Šelajev — 2026-08-03

Summary

Docker argues that isolated agent sandboxes fail developers not because isolation is wrong, but because empty sandboxes lack the tools, files, and credentials a real coding session needs — so agents either can't finish the task or developers bypass isolation to get work done. Docker's fix is "kits": versioned, YAML-defined bundles (mixin kits and sandbox kits) that declare install commands, dropped-in files, environment variables, network domain allow/deny lists, and a proxy-managed credential injection scheme so agents never handle raw secrets directly.

Key Takeaways

• Kits are spec.yaml files (schemaVersion, kind: mixin, commands.install) that install a tool into a sandbox in one declarative block — the example given installs jq via a single apt-get command.
• Network access is scoped explicitly through allowedDomains / deniedDomains lists (with wildcard support like *.cdn.example.com), so a sandbox can only reach the endpoints a kit author approved.
• Credentials never enter the microVM: kits define a proxyManaged environment variable that shows the agent a sentinel value, while a host-side proxy injects the real secret only when a request targets an approved serviceDomain.
• Kits compose: a single sbx run command can stack multiple kits (e.g., --kit java-kit --kit gcloud-kit --kit tessl-kit) to assemble a fully provisioned environment from reusable pieces.
• Core thesis: isolation only survives contact with real developers when it's at least as convenient as skipping it — kits turn sandbox setup into something repeatable, reviewable, and shareable instead of a per-run tax.

Reel Script

Hook (~18s, ~40 words) Your coding agent just spent ten minutes reinstalling jq and curl inside a fresh sandbox — again. Or worse: it pasted your real API key straight into a shell command because there was no other way to authenticate. That's the actual cost of an "empty" sandbox.

Core Concept (~65s, ~150 words) Here's the tension. Agent sandboxes exist to isolate a coding agent from your real machine — good for safety, bad for productivity, because a stripped-down sandbox has none of the tools, configs, or logins a real dev environment has. Docker's answer is something they call "kits." Think of a kit like a packing manifest for a shipping container: instead of building a sandbox from scratch every time, you attach a YAML file that says exactly what goes in — which tools to install, which files to drop into the workspace, which environment variables to set. The smallest kit, a "mixin," can be a few lines of YAML that installs one tool. Bigger "sandbox kits" bundle multiple mixins together — Java tooling, cloud CLIs, whatever a specific job needs — and you stack them on the command line like Lego pieces.

Hands-On (~75s, ~170 words) The part worth screenshotting is credential handling. Kits define network rules as explicit allow and deny lists — you literally write out which domains a sandbox can talk to, like api.example.com, and block others like a telemetry endpoint you don't want called home. Then for auth, instead of copying your real API key into the sandbox, the kit marks an environment variable as "proxy-managed." The agent sees something like MY_SERVICE_API_KEY=proxy-managed — a sentinel, not a secret. The actual key stays on your host machine, inside a proxy. When the agent's code makes a request to that approved domain, the proxy intercepts it and injects the real credential into the outgoing request. The agent never reads it, never logs it, never leaks it in a stray print statement. That's the whole trick: the agent gets working access without ever holding the keys.

Takeaway (~22s, ~55 words) This is the boring-but-correct fix for agent security theater: stop giving agents secrets, give them a proxy that holds the secrets for them. If you're running coding agents in sandboxes today and they're not this, you're either slowing your team down or you're one bad prompt away from a leaked key. Go read the kit spec before you build your own version badly.

Discussion