Coding Agents In Docker Sandboxes: Test The Boundary
Tech GuruQuick Answer
Identify which sandbox runtime you actually use before testing a coding agent. Docker Sandboxes documents microVM-based isolation; that is different from an ordinary Docker container. In either case, review mounted workspaces, credentials, control sockets, network rules and resource limits. Test denied access with dummy markers and controlled endpoints, then recreate the environment. Passing those checks reduces known exposure but does not prove escape is impossible.
Evidence status: Docker's product description and release notes through 0.46.0 were checked. No sandbox was started, attacked, load-tested or recreated. The read-only inspection examples below are documentation-backed and unperformed.
What To Check
Docker describes dedicated microVMs with Docker execution inside the VM, not access to the host Docker daemon. Do not transfer that architecture claim to an arbitrary container launched for an agent.
The release notes document credential-revocation fixes and 0.46.0 changes to host-side secret-command working directories. They explicitly caution against keeping credential helpers or dependencies in writable sandbox mounts. Review the installed version and restart requirements before trusting a saved policy.
Key Concepts In Plain Language
- Allowed workspace: the files deliberately shared with the agent; writes there can affect real project data.
- Host control surface: a daemon socket, helper or credential path that may grant authority beyond that workspace.
- Boundary test: a benign attempt to access an explicitly prohibited resource, not a proof against every escape technique.
Technical Checklist
- List every filesystem mount, environment variable, credential source, socket, device, network, process capability, and resource assigned to the agent.
- Plant non-sensitive canary credentials and attempt workspace escape, host socket access, DNS, HTTP, process discovery, and prohibited file reads.
- Cap CPU, memory, disk, process count, runtime, and egress while confirming the agent can still complete the approved task.
- Inspect audit evidence, destroy the sandbox, and recreate it from reviewed configuration to prove cleanup does not depend on in-place trust.
Interactive Operating Model
Use the planned checks below with this overview. No test result is implied by the diagram.
Before You Start: Safe Defaults
Use a disposable project copy with synthetic secrets and no customer data. Place dummy markers in allowed and deliberately excluded test locations. Preserve reviewed project changes outside disposable runtime state before any recreation. Define a resource ceiling and controlled network destinations.
- Do not expose an unauthenticated inference, upload, tool, MCP, or Docker control surface beyond the host that needs it.
- Use non-sensitive canary data and test accounts rather than real secrets when checking isolation.
- Cap CPU, RAM, GPU memory, disk, process count, context length, and outbound access before concurrency testing.
- Keep the environment reproducible so a compromised or wedged sandbox can be destroyed instead of repaired in place.
Go, Hold, Recover, Or Escalate
Proceed only when the approved task still works and prohibited paths fail. Hold on unexplained mounts, host daemon access, credential injection or network exceptions. If an actual secret becomes reachable, stop the test and assess exposure; recreating the sandbox does not revoke a copied credential.
Planned Checks And Recovery
For the documented sbx releases, sbx version identifies the CLI version and sbx ls --json lists sandbox records, including recorded CPU and memory limits in recent releases. Use the installed command help before additional inspection. These read-only checks do not exercise limit enforcement or prove which host files an agent can access.
Step 1: Review the actual environment
List mounts and write permissions, inherited variables, credential sources, host helpers, sockets, devices, capabilities and network allowances. Keep host credential helpers outside agent-writable project paths. Distinguish the VM's internal Docker daemon from the host daemon.
Step 2: Try prohibited reads and connections benignly
From the test agent environment, attempt to read the excluded dummy marker and reach only the preselected denied DNS/HTTP endpoints. Test access to forbidden control sockets without invoking destructive operations. Preserve clear allow/deny results and the policy that produced them.
Step 3: Check task function and resource enforcement
Run the approved task with synthetic input, then a bounded CPU/memory/process/runtime test. Observe actual enforcement and host impact, not just configured numbers. Stop at the agreed ceiling; do not use a host-disrupting stress test as the default.
Step 4: Revoke and recreate
Verify that removing a test credential ends its use in the running environment, including proxy-mediated requests. Preserve approved work, destroy only the identified disposable environment and recreate it from reviewed inputs. Retest mounts, egress and credential absence after recreation.
Validation Checklist
- Only the intended project paths and dummy credentials are accessible; prohibited markers/control sockets are not.
- Allowed task traffic works and prohibited controlled destinations are denied with usable evidence.
- Limits constrain the bounded workload without unexpected host impact.
- Revoked test authority stays revoked in the running and recreated environment; project changes are deliberately preserved or discarded.
Troubleshooting
- Excluded file is readable: Inspect parent-directory mounts and helper access before assuming the agent bypassed the hypervisor.
- Secret removal does not end requests: Check the installed release, running proxy state and upstream revocation, not just whether the local secret listing changed.
- Recreation restores an exception: Review the saved environment and policy inputs; deleting runtime state does not correct a permissive template.
Security, Privacy, Legal, And Recovery Boundaries
Security
Containers and application RBAC reduce risk but do not prove kernel, runtime, tool, model, or plugin isolation; use layered controls and negative tests.
Privacy
Prompts, files, embeddings, retrieved documents, tool output, and logs can expose confidential material to other users or administrators.
Legal
Confirm rights to models, documents, code, and generated output, and do not use production secrets or customer data in an unapproved test.
Recovery
Store configuration as code where practical, preserve only required state, and prove that the service can be destroyed and recreated without losing authoritative data.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
No test proves a sandbox immune to kernel, hypervisor, runtime or tool defects. Read-only version and inventory commands do not validate enforcement. The exact platform, runtime, mounts and agent permissions still require a controlled trial; plain-container results do not certify Docker Sandboxes or vice versa.
Related TechGeeks Resources
References
Next Action
Keep the allowed task and denied-path results together with the runtime version and reviewed configuration. Treat unexplained host access or persistent credentials as a stop condition.
One thought on “Coding Agents In Docker Sandboxes: Test The Boundary”