What you will build
An annotated boundary diagram and a small process/filesystem observation record. Your goal is to explain what the design separates without confusing one successful test with a proof against every possible escape.
- Host resources
- Explicit shared paths
- Separate guest kernel
- Processes and private files
Conceptual flow. Follow the lesson for prerequisites, exact commands and verification limits.
Read the mechanism
A conventional container generally shares its host kernel. Namespaces and control groups constrain its view and resources. A microVM introduces a separate guest kernel behind a hypervisor boundary. Docker Sandboxes uses that stronger boundary for an agent with broad privileges inside its own environment.
“Root inside” describes the guest’s authority. It does not mean root on your laptop. Conversely, guest isolation does not make an explicitly shared path private. Filesystem passthrough, forwarded credentials, allowed network destinations, skills and MCP integrations require their own analysis.
A useful drawing places assets first: host documents, guest working files, source repository, private Docker images, model API and external tools. Then draw each permitted connection. A diagram that simply says “secure sandbox” hides the decisions an engineer must actually review.
Worked lab · observe, then qualify
Use the disposable sandbox from chapter 1. These commands inspect the guest; they do not enumerate private host directories or attempt to defeat isolation.
sbx exec handbook-first uname -s
sbx exec handbook-first sh -c 'printf "process 1: "; cat /proc/1/comm'
sbx exec handbook-first sh -c 'printf "guest-only\n" > /tmp/handbook-marker'
sbx exec handbook-first cat /tmp/handbook-marker
sbx exec handbook-first sh -c 'test -f note.txt && printf "workspace visible\n"'Create a table in your notebook with three rows: /tmp/handbook-marker, the direct workspace’s note.txt, and a host file outside all configured mounts. For each, record the intended owner, whether it was deliberately shared, and the evidence needed to establish visibility. For the outside file, use a synthetic fixture in a separate disposable directory if you choose to test it; do not probe personal directories.
Expected observations
The guest identifies as Linux and sees its own process namespace. The marker is an in-guest file; the note is a shared-workspace file. Identical path strings on two machines do not establish identical storage. On a Linux host, uname alone cannot tell you which kernel instance a process uses.
Do not present “I could not read one file” as a full security validation. The architecture claim is supported by the product design; your experiment demonstrates only a specific configured path and operation.
Troubleshooting
If a supposed guest-only file is visible outside, check whether the path is actually under a configured mount. If a command is unavailable in a minimal template, record that limitation instead of installing a large diagnostic suite. Avoid privileged host introspection just to make a teaching diagram more impressive.
Interview practice
Why is Docker-in-Docker not automatically equivalent to a microVM?
A nested daemon describes where containers are managed. It does not establish a separate kernel. Explain the hypervisor boundary, privileges and mounted resources independently of daemon nesting.
What evidence would you want before approving an isolation claim?
A documented architecture, explicit configuration, version information, scoped negative tests and an account of the remaining attack paths. A single command failure is insufficient.
Completion check
Draw host and guest as separate boxes. Label every shared mount, network/proxy connection and host integration. State which observation supports each claim and which properties remain untested.
Sources and version notes
Checked 6 October 2026; current baseline: sbx v0.46.0. Isolation layers · Architecture
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.