A working multi-agent system on Docker.

This 2-hour hands-on workshop walks through the Docker primitives that let you hand AI agents meaningful autonomy without losing control over what they do. Over eight steps you'll start a sandbox, prove its isolation guarantees, govern its network, harden the containers it ships, attach tools via MCP, standardize the setup as a kit, compose multiple agents with Docker Agent, and observe how per-role tool scoping holds as a runtime boundary.

Before you start, you'll need:

• A Docker account. Sign up at hub.docker.com if you don't have one (takes 30 seconds), then sign in.
• An AI provider API key: Anthropic (for Claude Code), OpenAI (for Codex), or OpenCode (free tier on Zen).
• A terminal of your choice (MacOS Terminal, iTerm2, Warp, PowerShell, or any equivalent).
• A supported platform: MacOS Apple Silicon, Linux x86_64 with KVM access, or Windows 11 x86_64. MacOS Intel is not supported.

The detailed install and configuration steps are in Getting Started.

Docker's stack for safe, auditable, and compliant AI-agent adoption.

AI agents are moving from experiments to production, and enterprises need to answer three governance questions before they let one loose in their stack: what does the agent ship, what can the agent see, and what can the agent do. This workshop takes each of those in order and shows the Docker primitive that answers it. Every module ends in an artifact your security or compliance team can review: a hardened image, an audit log, a scoped yaml, or a portable kit.

The three governance questions

• What does the agent ship? Any container an agent produces will go to production somewhere. If the base image has known CVEs, so does everything you ship. Docker Hardened Images (DHI), the foundational module below, give you a supply-chain-grade base to build on.
• What can the agent see? An agent that can reach anything on the internet, read any file on your host, or grab any credential is a compliance nightmare. Docker Sandboxes and their network policy bound the agent's environment and audit every outbound request.
• What can the agent do? Even inside a sandbox, the agent's tool set determines the scope of its actions. The Docker MCP Gateway, sbx kits, and Docker Agent yaml let you declare tool sets, scope them per team or per role, and enforce the boundary at the runtime.

What you'll leave with

• A mental model of each governance question, mapped to a Docker primitive.
• A running sandbox on your laptop with every primitive in place.
• A kit template you can adapt and commit to your team's repo.
• A per-role Docker Agent yaml that reads as an auditable compliance artifact.

Before you start, you'll need:

• A Docker account. Sign up at hub.docker.com if you don't have one (takes 30 seconds), then sign in.
• An AI provider API key: Anthropic (for Claude Code), OpenAI (for Codex), or OpenCode (free tier on Zen).
• A terminal of your choice (MacOS Terminal, iTerm2, Warp, PowerShell, or any equivalent).
• A supported platform: MacOS Apple Silicon or Windows 11 x86_64. Linux users should run the workshop inside a supported guest OS (VMware Fusion, Parallels, UTM). Native Linux is not yet supported by the workshop's sbx path.

The detailed install and configuration steps are in Getting Started. LP2 needs Docker Desktop installed before the Foundational DHI module, so make sure it's up and running by the time you finish Getting Started.

Confirm your environment before Step 1.

Platform support

Required

• A Docker account (free tier works), signed in.
• An AI provider API key: Anthropic (for Claude Code), OpenAI (for Codex), or OpenCode (free tier on Zen).
• A terminal of your choice (MacOS Terminal, iTerm2, Warp, PowerShell, or any equivalent). Windows users on WSL can follow the MacOS commands.

Install sbx

MacOS users The MacOS install commands in this workshop use Homebrew. If you don't already have it, install it from brew.sh first (one terminal command, takes a couple of minutes). Once brew --version prints a version, come back here.

brew install docker/tap/sbx

winget install -h Docker.sbx
# Or download the MSI from
# https://github.com/docker/sbx-releases/releases

Windows users Close and reopen your terminal after the install so sbx picks up on PATH. Otherwise the next command will report "sbx not found".

Verify the install

sbx version

sbx version: v0.33.0 xxxxx

Log in to Docker

Heads up: personal Docker account only If your Docker Hub account is part of an organization that has Docker AI Governance enabled, that org's policies will override the workshop's defaults and several steps won't behave as documented. Sign in with a personal Docker Hub account for this workshop, not with an org-linked one. If you don't have a personal account, create a free one at hub.docker.com before continuing.

sbx login

Opens a browser-based device confirmation flow. After sign-in, depending on your version, you may be prompted to pick a default network policy. If you are, pick Balanced (option 2).

If you weren't prompted, set the default explicitly with:

sbx policy reset

You'll see the three options:

Select a default network policy for your sandboxes:

     1. Open         - All network traffic allowed, no restrictions.
  >  2. Balanced     - Default deny, with common dev sites allowed.
     3. Locked Down  - All network traffic blocked unless you allow it.

  Use the arrow keys or 1-3 to navigate, Enter to confirm.

Pick Balanced. This is the policy we'll use throughout the workshop.

Get your API key

Follow the steps for the provider you picked at the top of the page. Name the key sbx so you can recognize it later.

Heads up The last two steps of the workshop are optimized specifically for Claude / Anthropic, which is one of the reasons we encourage an Anthropic key for this workshop. If you just created one above, keep the value handy; you'll need to paste it again later. If you're on a different provider, you can follow along, but certain parts of those later steps might not work for you.

Store your API key

Store the key you just created with sbx so the sandbox can use it. The CLI walks you through pasting the key:

sbx secret set -g anthropic

sbx secret set -g openai

sbx secret set -g google

sbx secret set -g opencode

Verify it's stored:

sbx secret ls

SCOPE    TYPE     NAME        SECRET
global   service  anthropic   ****...****

SCOPE    TYPE     NAME      SECRET
global   service  openai    ****...****

SCOPE    TYPE     NAME      SECRET
global   service  google    ****...****

SCOPE    TYPE     NAME        SECRET
global   service  opencode    ****...****

To remove it later:

sbx secret rm -g anthropic

sbx secret rm -g openai

sbx secret rm -g google

sbx secret rm -g opencode

Install Docker Desktop (LP2)

brew install --cask docker

winget install -h Docker.DockerDesktop

open -a Docker

Start-Process "$env:ProgramFiles\Docker\Docker\Docker Desktop.exe"

docker info

docker login

Create your workshop directory

We'll keep everything we create today inside a single umbrella folder, ~/workshop, with the sbx workspace at ~/workshop/sbx. That way nothing sprays into your home directory and everything is easy to clean up at the end.

mkdir -p ~/workshop/sbx

New-Item -ItemType Directory -Force -Path $HOME/workshop/sbx | Out-Null

cd ~/workshop/sbx

cd $HOME/workshop/sbx

The supply-chain anchor. Ground here first, before we look at anything the agent does.

Before we go anywhere near sbx, let's ground on the piece your security and platform teams already recognize: Docker Hardened Images (DHI). An AI agent that builds and ships containers ends up putting whatever base image you started from into production. If that base has known CVEs, so does everything you ship on top of it. Hardening the base is the single-highest-leverage supply-chain move you can make, and it's the one a security reviewer will ask about first.

The rest of the workshop assumes the base your agent builds on is trustworthy. This foundational module makes sure it is.

F.1 What a DHI is

Think of DHIs the way a chef thinks about ingredients. Before you make a meal you want to know the flour doesn't have worms, the eggs aren't spoiled, and the oil didn't come out of a can that was already open. In software, "the ingredients aren't rotten" translates to: the base image your agent builds on doesn't ship with known CVEs, is signed by someone you trust, and has a documented list of what's inside. A Docker Hardened Image is that trustworthy ingredient.

Concretely, a DHI is a base image (python, node, nginx, alpine, etc.) that Docker has stripped down, patched, and re-signed to have near-zero known CVEs. Each DHI ships in two variants:

• A dev variant with a shell and a package manager, used in the build stage of a multi-stage Dockerfile.
• A prod variant with no shell, no extras, no package manager, just what the runtime needs. This is the variant that actually ships.

Docker maintains DHIs with enterprise SLAs on vulnerability remediation, and each ships with a signed SBOM (Software Bill of Materials) listing every package inside. That SBOM is the telemetry your compliance team uses to prove and instantiate every supply-chain claim you make about the image: "this component, this version, this license, this vulnerability status." Without the SBOM you're vouching for the image from memory; with the SBOM you're pointing at a signed document. DHIs live under the dhi.io namespace and require a one-time login with your Docker Hub credentials before you can pull them.

Prep for this module The commands below need Docker Desktop running and you signed in to Docker Hub, both set up in Getting Started's Install Docker Desktop substep. If you skipped it, go do it now, then come back here. Otherwise you're set.

F.2 Sign in to the DHI registry

DHI pulls require a login to dhi.io. Same Docker Hub credentials, different registry endpoint:

docker login dhi.io

F.3 Compare a standard base to its hardened variant

Pull a standard Python base and its DHI equivalent, then scan both with Docker Scout to see the delta:

docker pull python:3.14-slim

docker pull dhi.io/python:3.14

Scan the standard base first:

docker scout quickview python:3.14-slim

Take note of the CVE counts under Critical, High, Medium, and Low. On a recent build of python:3.14-slim you'll typically see a handful of Highs and a longer tail of Mediums and Lows. That's normal for a general-purpose base: it packs a shell, a package manager, dev headers, and the transitive dependencies of everything it might need.

Now the hardened variant:

docker scout quickview dhi.io/python:3.14

Same Python version, same runtime capability, near-zero CVEs. That's the payoff. The image is smaller too: no shell, no package manager, nothing you don't need to run the code.

F.4 Why this is the foundational module for the rest of the workshop

Everything that follows assumes a hardened base. When Step 5 has the agent build a research app and swap in a DHI, the CVE delta you just observed is the delta you'll see there too. Same mechanic, applied to code the agent wrote. When the Docker Agent team in Step 7 produces artifacts, the images backing those tools are DHIs. The rest of the workshop is about what the agent does with a trustworthy base; this module is the base itself.

Governance takeaway: the artifact from this module is the CVE quickview output, which your compliance team can attach to a supply-chain review. In the Extended path (2-4 hour delivery), we go deeper on SBOMs, provenance attestations, and Docker Scout policies applied against the images.

Spin up a Docker Sandbox with an agent inside, and confirm it's alive.

The primitive that answers "what can the agent see?", plus the artifact that documents the boundary.

You'll create a sandbox on the host, verify it's running, attach your terminal to the agent inside, and then ask the agent three quick questions about its environment. By the end you'll have proved that the agent really is running on Linux in a microVM with its own kernel, its own user, and access to exactly the directory you mounted. Nothing more.

Governance framing: the sandbox is a VM with a hostname, an audit trail, and no residue outside the workspace mount. Every artifact in this workshop, from the policy log in the next step through the yaml in Step 7, assumes this boundary as the trust anchor. If the boundary isn't real, none of the downstream artifacts mean anything to your auditor. This step establishes the boundary and the artifacts that prove it.

Assumes you completed Getting Started (install, login, secret, workspace setup).

1.1 Create your sandbox

sbx create registers a new sandbox with the local sbx daemon and starts it. By the time the command returns, the microVM is up and the agent is running inside it. Your terminal isn't connected to the agent yet; that's the next step. The --name flag gives the sandbox a label you'll use to refer to it later (in sbx run, sbx stop, sbx rm, and the policy / log commands in Step 3). The final argument is the directory to mount as the sandbox's workspace; whatever lives in that directory is what the agent will see, and the only host directory it will have access to.

You can write that argument two ways. . is shorthand for "the current directory" and works if you're already cd'd into the folder you want mounted. An explicit path like ~/workshop/sbx works from any terminal, regardless of where you've cd'd. We'll use the explicit form throughout this workshop so the commands are reliable across terminals.

Run the command for the provider you picked at the top:

sbx create --name sandbox-alpha claude ~/workshop/sbx

sbx create --name sandbox-alpha claude $HOME/workshop/sbx

sbx create --name sandbox-alpha codex ~/workshop/sbx

sbx create --name sandbox-alpha codex $HOME/workshop/sbx

sbx create --name sandbox-alpha gemini ~/workshop/sbx

sbx create --name sandbox-alpha gemini $HOME/workshop/sbx

sbx create --name sandbox-alpha opencode ~/workshop/sbx

sbx create --name sandbox-alpha opencode $HOME/workshop/sbx

First run pulls the agent's template image from Docker Hub if it isn't already cached locally (1-2 minutes).

Windows users: if this fails with "Windows Hypervisor Platform is not enabled" sbx boots each sandbox as a Linux microVM, and on Windows that requires the Hypervisor Platform feature to be turned on. To turn it on, open PowerShell as Administrator (right-click PowerShell in the Start menu, choose Run as administrator) and run:

dism /Online /Enable-Feature /FeatureName:HypervisorPlatform /All

You'll likely need to restart your computer afterward for the change to take effect, then re-run sbx create.

1.2 See what's running

sbx ls lists every sandbox the sbx daemon knows about along with its agent type, status, exposed ports, and workspace path. It's the command you'll come back to any time you want to see what sandboxes exist on your machine. Right after sbx create the sandbox you just made should show running.

sbx ls

SANDBOX         AGENT   STATUS   PORTS   WORKSPACE
sandbox-alpha   claude  running          /Users/<you>/workshop/sbx

SANDBOX         AGENT   STATUS   PORTS   WORKSPACE
sandbox-alpha   codex   running          /Users/<you>/workshop/sbx

SANDBOX         AGENT    STATUS   PORTS   WORKSPACE
sandbox-alpha   gemini   running          /Users/<you>/workshop/sbx

SANDBOX         AGENT      STATUS   PORTS   WORKSPACE
sandbox-alpha   opencode   running          /Users/<you>/workshop/sbx

1.3 Connect to the agent

sbx run attaches your terminal to the agent that's already running inside the sandbox. It doesn't start anything new. From this point on, what you type goes to the agent, not to your host shell. To get back to the host you'll exit the agent (typically Ctrl+C twice) or open a second terminal.

sbx run --name sandbox-alpha

The first time you connect, your agent might ask something like:

  Do you trust the contents of this directory? Working with untrusted
  contents comes with higher risk of prompt injection.

› 1. Yes, continue
  2. No, quit

If you see it, that's the agent's own startup safety check, asking you to confirm you intended to give it access to this workspace. Pick 1. Yes, continue. If you don't see this prompt, no action needed; the agent will go straight to its own prompt and you can start talking to it.

1.4 Ask the agent what it sees

To prove the agent is actually running inside the sandbox (not on your host), have it print three things: the kernel string, its user identity, and its current directory. Each tells us something about the environment it's in.

Linux <vm-hostname> 7.0.11 #1 SMP ... Linux
agent
/Users/<your-username>/workshop/sbx

The first line confirms it's on Linux with its own kernel, even though your host is MacOS or Windows. The second line shows it's running as a non-root agent user, not as you. The third line shows the working directory is the one you mounted, accessible at the same absolute path inside the VM as it has on your host.

sbx create --name sandbox-bravo claude ~/workshop/sbx

sbx create --name sandbox-bravo claude $HOME/workshop/sbx

sbx create --name sandbox-bravo codex ~/workshop/sbx

sbx create --name sandbox-bravo codex $HOME/workshop/sbx

sbx create --name sandbox-bravo gemini ~/workshop/sbx

sbx create --name sandbox-bravo gemini $HOME/workshop/sbx

sbx create --name sandbox-bravo opencode ~/workshop/sbx

sbx create --name sandbox-bravo opencode $HOME/workshop/sbx

sbx ls

sbx run --name sandbox-bravo

sbx stop sandbox-bravo

sbx rm sandbox-bravo

sbx ls

Three quick tests prove the boundary: the workspace shares both ways, host files outside are unreachable, secrets are usable but not exfiltrable.

We'll run three tests to show that the sandbox boundary is enforced by the runtime, not by trust in the agent. First, we drop a file into the workspace from the host and have the agent read it (and vice versa) to confirm the shared workspace works in both directions. Second, we drop a file outside the workspace on the host and ask the agent to read that. It should fail. Third, we check whether the API key the agent is using to talk to its model provider right now is actually visible anywhere inside the sandbox. By the end you'll have direct evidence that the access boundary is a mount table, not a permission dialog.

You'll need two terminals: Terminal A is the agent inside the sandbox (already running from Step 1). Terminal B is your host shell.

2.1 The workspace IS shared, both directions

Host to agent. On your host terminal, drop a file in the workspace:

echo "Written from the host" > ~/workshop/sbx/host-to-agent.txt

"Written from the host" | Out-File $HOME/workshop/sbx/host-to-agent.txt

Now inside the sandbox, ask the agent to read it:

Written from the host

Agent to host. Now ask the agent to write a file:

Back on your host terminal, first list the workspace to see the file appear, then open it to confirm the contents:

ls -la ~/workshop/sbx

Get-ChildItem $HOME/workshop/sbx

cat ~/workshop/sbx/agent-to-host.txt

Get-Content $HOME/workshop/sbx/agent-to-host.txt

total 16
drwxr-xr-x   4 you  staff   128 ... .
drwxr-xr-x  20 you  staff   640 ... ..
-rw-r--r--   1 you  staff    22 ... agent-to-host.txt
-rw-r--r--   1 you  staff    22 ... host-to-agent.txt
Written from the agent

Heads up Inside the sandbox, ~ is the agent's home (/home/agent), not the workspace. Use relative paths or the workspace's absolute path (/Users/<you>/workshop/sbx) when working inside the sandbox.

2.2 Outside the workspace, host files are invisible

echo "This file lives in your home, not the workspace" > ~/workshop/host-marker.txt

"This file lives in your home, not the workspace" | Out-File $HOME/workshop/host-marker.txt

cat: /home/agent/workshop/host-marker.txt: No such file or directory
cat: /Users/<your-username>/workshop/host-marker.txt: No such file or directory

The file is right there on your host. The sandbox can't see it. Only ~/workshop/sbx is mounted in.

2.3 Secrets exist on host, agent can't read them

sbx secret ls

SCOPE    TYPE     NAME        SECRET
global   service  anthropic   ****...****

ANTHROPIC_API_KEY=

SCOPE    TYPE     NAME      SECRET
global   service  openai    ****...****

OPENAI_API_KEY=

SCOPE    TYPE     NAME      SECRET
global   service  google    ****...****

GOOGLE_API_KEY=

SCOPE    TYPE     NAME        SECRET
global   service  opencode    ****...****

OPENCODE_API_KEY=

The secret demonstrably exists on the host. Inside the sandbox it's not in any environment variable. Yet the agent is talking to you right now using that exact key. The credential proxy injects the auth header at the network layer.

Cleanup

rm ~/workshop/host-marker.txt ~/workshop/sbx/host-to-agent.txt ~/workshop/sbx/agent-to-host.txt

Remove-Item $HOME/workshop/host-marker.txt, $HOME/workshop/sbx/host-to-agent.txt, $HOME/workshop/sbx/agent-to-host.txt

mkdir -p ~/workshop/sbx-docs

New-Item -ItemType Directory -Force -Path $HOME/workshop/sbx-docs | Out-Null

echo "Read only reference material" > ~/workshop/sbx-docs/README.txt

Set-Content $HOME/workshop/sbx-docs/README.txt "Read only reference material"

sbx create --name sandbox-bravo claude ~/workshop/sbx ~/workshop/sbx-docs:ro

sbx create --name sandbox-bravo claude $HOME/workshop/sbx $HOME/workshop/sbx-docs:ro

sbx create --name sandbox-bravo codex ~/workshop/sbx ~/workshop/sbx-docs:ro

sbx create --name sandbox-bravo codex $HOME/workshop/sbx $HOME/workshop/sbx-docs:ro

sbx create --name sandbox-bravo gemini ~/workshop/sbx ~/workshop/sbx-docs:ro

sbx create --name sandbox-bravo gemini $HOME/workshop/sbx $HOME/workshop/sbx-docs:ro

sbx create --name sandbox-bravo opencode ~/workshop/sbx ~/workshop/sbx-docs:ro

sbx create --name sandbox-bravo opencode $HOME/workshop/sbx $HOME/workshop/sbx-docs:ro

sbx run --name sandbox-bravo

Read only reference material
bash: ../sbx-docs/agent-wrote.txt: Read-only file system

sbx stop sandbox-bravo

sbx rm sandbox-bravo

rm -rf ~/workshop/sbx-docs

Remove-Item -Recurse -Force $HOME/workshop/sbx-docs

sbx run --name sandbox-alpha

ps aux | head -20

Get-Process | Select-Object -First 20

See the five default allow groups, watch allow vs deny vs default-deny in action, add a custom deny rule that breaks pip install, then clean up.

Every outbound request the agent makes goes through a proxy that logs it. That log is your audit trail.

We'll list the network policies the sandbox starts with, then have the agent hit four URLs (two allowed by default, two not) to watch the proxy let some through and block others. We'll check the audit log on the host to see what got allowed and what got blocked, then add a custom deny rule for pypi.org. Once that rule is live we'll watch every workaround the agent might try fail in the same place. By the end you'll see that the network boundary is enforced at the host-side proxy, not in the agent. It doesn't matter how creative the model gets. Blocked traffic stays blocked.

Governance framing: the network policy answers "what can the agent reach?" and the policy log answers "what did the agent actually try to do?" Together they're the highest-value pair of artifacts an auditor can ask for. The compliance-ready audit report at the end of this step is what you hand a security reviewer to demonstrate that agent behavior is bounded AND observable.

You'll need two terminals open side by side throughout Step 3.

Terminal A: the agent inside sandbox-alpha. If you went through any of the Step 2 go-deepers, you may have exited the agent or switched to bravo (which we've since removed). If your terminal isn't currently sitting at the agent prompt, reconnect:

sbx run --name sandbox-alpha

If you never exited the agent (i.e., you skipped the Step 2 go-deepers), you're already attached and can skip the command above.

Terminal B: your host shell. This is where you'll run sbx policy commands and check the audit log. Position the two windows side by side so you can watch the agent's behavior in Terminal A while you change policy and read the log in Terminal B.

3.1 See the defaults

sbx policy ls

POLICY                                 SOURCE  APPLIES TO             SUMMARY
907eda6d-fde5-4f68-ad90-42d2ecf2fa7f   kit     sandbox:sandbox-alpha  network: 3 allow
local-policy                           local   all                    network: 192 allow; filesystem read: 1 allow; filesystem write: 1 allow

Two rows, two levels of policy. The local-policy row (source local, applies to all) is the Balanced default you selected in Getting Started: 192 allowed hosts covering the destinations a coding workflow actually needs (Docker Hub, package managers for common languages, GitHub / GitLab, cloud provider APIs, OS package repos, popular AI-service endpoints). The other row (source kit, scoped to sandbox-alpha) is a small per-sandbox add-on that ships with the default agent kit. Everything not covered by these rules falls under default-deny.

3.2 Allow vs deny in action

Inside the sandbox, ask the agent to hit five URLs. Two that should be allowed by default (GitHub and PyPI, both in the defaults above), three that are not (Reddit, Wikipedia, and the official FIFA site). For each one we print the status code and the number of bytes downloaded, which makes "passed through" vs "blocked at the proxy" obvious at a glance.

github.com: 200 (254301 bytes)
pypi.org: 200 (147832 bytes)
reddit.com: 403 (0 bytes)
wikipedia.org: 403 (0 bytes)
fifa.com: 403 (0 bytes)

github.com and pypi.org are in default-allow lists, so the proxy forwards the request and you get a full page back (status 200, non-zero byte count). reddit.com, wikipedia.org, and fifa.com aren't on any allow list, so default-deny kicks in: the proxy refuses (status 403, zero bytes, nothing left the VM).

3.3 Check the audit trail

After the agent ran those curls, print the connection log on your host:

sbx policy log sandbox-alpha

Blocked requests:
HOST                REASON                                  COUNT
reddit.com:443      No matching allow rule (default deny)   1
wikipedia.org:443   No matching allow rule (default deny)   1
fifa.com:443        No matching allow rule (default deny)   1

Allowed requests:
HOST              RULE             COUNT
github.com:443    domain-allowed   1
pypi.org:443      domain-allowed   1

Every outbound connection from the sandbox is recorded, split into two sections (Blocked requests and Allowed requests), with which rule each matched and why. For a regulated team, this answers "what did the agent do on the network, and when?" Re-run the command later to see new entries.

sbx policy allow network fifa.com

3.4 Add a custom deny rule

Block a domain that IS in the default allow list. We'll use pypi.org.

Exit the agent in Terminal A: press Ctrl+C twice.

sbx policy deny network pypi.org

sbx policy ls

local:9701dc6e-...   network   deny   pypi.org

3.5 Restart the sandbox if needed

New policy rules apply immediately on most setups. If you find the rule isn't taking effect (for example a sandbox in the middle of a long-lived connection), restart it:

sbx stop sandbox-alpha

sbx run --name sandbox-alpha

3.6 Verify the deny rule is enforced

pypi.org: 403 (0 bytes)

ERROR: Could not find a version that satisfies the requirement requests
ERROR: No matching distribution found for requests

The agent may try multiple workarounds. All fail because every approach hits the same blocked TCP connection at the proxy.

3.7 Remove a rule

Add commands create rules. sbx policy rm network takes them away. The cleanest form removes a rule by the resource (domain) it applies to. Let's practice on a throwaway rule so we don't disturb the ones we'll need going into Step 5. First, add a sample deny rule for a domain we won't actually use:

sbx policy deny network example.com

Confirm it's there:

sbx policy ls

Then remove it:

sbx policy rm network --resource example.com

--resource tells sbx which rule to drop by the domain it applies to. If you prefer to remove by rule ID, swap --resource example.com for --id <UUID>; find the UUID in the first column of the policy list. Either form removes the rule.

Run the list one more time to confirm the row is gone:

sbx policy ls

The example.com row is gone. That same mechanic works on any rule, including the fifa.com allow and the pypi.org deny we added earlier. When you're done with this workshop, you can clean up everything you added with sbx policy rm network --resource <domain> per rule. For now, leave fifa.com allowed and pypi.org denied. Step 4 (MCP) won't touch policy; Step 5's prep step removes the pypi.org deny so pip installs work in the research demo.

sbx policy allow network 1.1.1.1

sbx policy log sandbox-alpha

sbx policy allow network --help

sbx policy rm network --resource 1.1.1.1

sbx policy log sandbox-alpha | grep -E 'Blocked|Denied'

sbx policy log sandbox-alpha | Select-String -Pattern 'Blocked|Denied'

sbx policy log sandbox-alpha | grep github.com

sbx policy log sandbox-alpha | Select-String -SimpleMatch 'github.com'

sbx policy log sandbox-alpha | grep '(default deny)'

sbx policy log sandbox-alpha | Select-String -SimpleMatch '(default deny)'

Give the sandboxed agent access to tools beyond reading and writing files by registering an MCP server and attaching it to sandbox-alpha.

The primitive that answers "what can the agent do?": every tool declared, every invocation observable.

In Step 3 you saw what happens when the agent reaches for something outside the default allow list: the proxy blocks it, the audit log records it, and you decide whether to open a targeted hole. That's a network-level lever. MCP gives you a different one: instead of unblocking a domain, register a specific tool (web search, GitHub access, file operations, an internal API) and let the agent invoke that tool through a controlled channel. The agent can do what the tool exposes and nothing more.

Governance framing: tool access, not network access, is the granularity your compliance team wants. "The agent can reach Wikipedia" is coarse; "the agent has the get_summary and search_wikipedia tools" is precise. Each MCP registration is a documented capability grant. The Docker MCP Gateway (introduced in 4.2.1 below) is where team-scale tool governance lives: profiles, catalogs, and per-client scoping so different teams see different tool subsets from the same shared infrastructure.

MCP (Model Context Protocol) is an open standard for how agents call tools. An MCP server exposes one or more tools, and the agent invokes them through the protocol. sbx mcp is how we register servers so that agents running inside a sandbox can use them. For this step we'll register two MCP servers (Wikipedia and DuckDuckGo web search), attach both to sandbox-alpha, and have the agent retrieve information through them.

4.1 Enable the sbx mcp subtree

The sbx mcp subtree is hidden by default. It only appears when the SBX_MCP_URL environment variable is set to an absolute http/https URL. The simplest path is to point it at the public MCP community registry, which unlocks the subcommands without requiring any additional infrastructure:

export SBX_MCP_URL=https://registry.modelcontextprotocol.io

$env:SBX_MCP_URL = "https://registry.modelcontextprotocol.io"

Restart the sbx daemon so it picks up the new SBX_MCP_URL:

sbx daemon stop

sbx daemon start -d

Confirm the subtree is now available:

sbx mcp --help

You'll see subcommands like add, ls, inspect, rm, and bundle. SBX_MCP_URL is a per-shell variable, so if you open a new terminal you'll need to set it again or persist it in your shell's rc file (~/.zshrc, ~/.bashrc, or ~/.config/fish/config.fish).

If MCP commands later fail with a gateway error Two common causes: (1) the sbx daemon doesn't know about SBX_MCP_URL because it was started before you exported the env var; the daemon restart we did in this step is what fixes that. (2) Docker Desktop isn't signed in to Docker Hub, so it can't pull the MCP image; open Docker Desktop and sign in. Keep these two causes in mind if you hit an MCP error later on.

4.2 Register a local MCP server

sbx mcp add supports four registration modes: remote OAuth, community registry (managed), community registry (local), and local stdio. We'll use the fourth: a local stdio MCP server that runs as a Docker container on the host. It's the most reliable path and needs nothing beyond your machine.

Register the Wikipedia MCP server:

sbx mcp add wiki-mcp --command docker --args "run,-i,--rm,mcp/wikipedia-mcp"

Walking through that command piece by piece:

sbx mcp add registers a new MCP server so sbx-managed sandboxes can attach to it later. wiki-mcp is just a name we picked for this registration; you can call it whatever you want. It's the handle you'll reference in later commands like sbx mcp inspect wiki-mcp or as the value of --static-mcp wiki-mcp when creating a sandbox.

--command docker tells sbx what executable to invoke when it starts the MCP server, so the server runs in a container rather than on the bare host. --args is comma-separated (not space-separated, a common gotcha), and these args translate to docker run -i --rm mcp/wikipedia-mcp. Of those Docker flags: -i keeps stdin open, which is what makes stdio transport work in the first place (without it sbx can't pipe JSON-RPC into the container); --rm auto-removes the container on exit so you don't accumulate stopped containers every MCP session.

mcp/wikipedia-mcp is the OCI image, published in Docker's MCP catalog as a Verified Publisher image. It wraps Wikipedia's API in the MCP protocol and exposes 22 read-only tools that the agent can call once the server is attached to a sandbox: search_wikipedia, get_article, get_summary, extract_key_facts, get_sections, get_links, and friends. We're using Wikipedia here because every tool the server exposes is scoped to Wikipedia (no general web access), it's free and requires no API key, and it gives the agent a capability that's clearly distinct from anything in its default toolkit. Any MCP server published to the catalog could take its place: a GitHub MCP, a Notion MCP, a Slack MCP, a custom one you built.

Now inspect the server you just registered to see what it actually exposes. This pulls the server's tool list, descriptions, and metadata back from the underlying MCP server, so you can confirm both that the registration worked and what the agent will be able to call:

sbx mcp inspect wiki-mcp

You'll see the server's name, transport mode (stdio), the underlying command sbx will launch when an agent attaches to it, and the tools it advertises (the 22 Wikipedia-scoped tools listed above). If anything looks wrong here, sbx never got to a clean working state with that registration; fix it before moving on.

If sbx mcp add reported any error Even when add fails, sbx sometimes caches a broken registration that will block subsequent attach attempts on this name. If sbx mcp inspect wiki-mcp above showed anything unexpected, remove the bad entry and re-add it: sbx mcp rm wiki-mcp, then re-run the sbx mcp add command from the step above.

If you want to see every MCP server registered so far in one view, list them:

sbx mcp ls

wiki-mcp should appear in the output.

Heads up Local stdio MCP servers run on the HOST, not inside the sandbox. They execute with your full user permissions: filesystem, network, secrets, everything. The sandbox boundary you built in Steps 1-3 still holds for the agent's own actions; the MCP server is just a tool the agent can call through that boundary. Use local stdio MCP servers for development and code you trust, not for arbitrary third-party code.

4.2.1 Zoom out: the Docker MCP Gateway

Everything you just did with sbx mcp add registered a server with sbx's own MCP layer, scoped to sandboxes managed by this daemon. That's the right shape for a single developer running one or two sandboxes at a time. As soon as you scale past that (a team using the same MCP servers, or one client wanting to see a curated subset of tools), you want a broader primitive. Docker ships one: the Docker MCP Gateway.

The Gateway is a local proxy that sits between MCP clients (agents, IDEs, Docker Agent, LM Studio, Cursor) and MCP servers. You register servers against the Gateway, group them into profiles, and connect each client to the profile that fits its role. Bundled with Docker Desktop 4.62+, also installable as a CLI plugin. Explore the command surface:

docker mcp --help

Conceptual only in this workshop The rest of this subsection describes the Gateway workflow at a high level. The commands are illustrative, not for copy-paste in Step 4 (they don't cleanly fit the sandbox-first shape of this step). If you want to actually stand a Gateway up on your machine, follow the walkthrough in the LP2 Go Deeper section (MCP Gateway at scale) or the official docs at docs.docker.com/ai/mcp-gateway/.

Conceptually, a minimal profile-based workflow looks like this: you create a profile with a name (something like workshop), add MCP servers to that profile (from Docker's MCP catalog or from OCI images you host), then run the Gateway pinned to that profile. Once it's running, an MCP client (an IDE, a Docker Agent yaml, or any custom client) binds to the profile, and from then on that client sees exactly the tools the profile grants, no more, no less. Different clients bind different profiles; that's how a team gets per-client tool scoping without duplicating registrations.

We're keeping the rest of the workshop on the per-sandbox sbx mcp path because it makes the sandbox-as-trust-boundary story cleaner. But if you're planning an MCP setup that a team is going to share, the Gateway is the primitive to know about.

4.2.2 Register a second MCP

One MCP gets the agent Wikipedia access; a second MCP with a different tool surface makes the "the agent picks the right tool for the sub-question" story real. Register the DuckDuckGo web-search server:

sbx mcp add duck-mcp --command docker --args "run,-i,--rm,mcp/duckduckgo"

Same shape as the wiki registration, different image. mcp/duckduckgo wraps DuckDuckGo's web-search API in the MCP protocol and exposes web search, image search, news search, and content fetching. Different tool surface from Wikipedia, which is the point. The agent will pick each tool based on the sub-question.

Confirm it registered and inspect what it exposes:

sbx mcp inspect duck-mcp

List all your registrations to confirm both are there:

sbx mcp ls

wiki-mcp and duck-mcp should both appear.

Other registration modes sbx mcp add also accepts remote MCP endpoints (--url https://mcp.notion.com/mcp, OAuth handled automatically) and, in a preview state as of this workshop, a direct OCI image reference mode (--url docker.io/mcp/<image>:<tag>) where sbx auto-detects the transport from the image's labels. OCI-native mode registers today but live-attach isn't fully wired for local sandboxes yet, which is why this workshop stays on the stdio-with-docker-command path for both servers. To see the full surface:

sbx mcp add --help

4.3 Try without MCPs, then with both attached

Two MCPs are registered but neither is attached to a sandbox yet. Before we attach them, let's prove the agent really can't reach Wikipedia or web search through normal channels. The contrast is the whole point of this step.

Part 1: confirm both destinations are blocked. Attach to the existing sandbox-alpha (still running from Step 3):

sbx run --name sandbox-alpha

Ask the agent to fetch a specific Wikipedia URL. Don't tell it how. Whichever tool it picks (built-in web fetch, curl, anything else) the request still has to leave the sandbox, and the sandbox's network policy doesn't allow Wikipedia:

The agent picks a tool, makes the request, and the proxy refuses it with a 403 (or the connection fails outright) because wikipedia.org isn't on any default allow list. The agent reports the failure. Same story for a general web search: duckduckgo.com isn't on any allow list either. That confirms the baseline: with no MCP attached, the sandbox can't reach either source, regardless of which tool the agent reaches for.

Switch to Terminal B (your host shell) and confirm the block in the audit log:

sbx policy log sandbox-alpha

You'll see a fresh Blocked requests entry for en.wikipedia.org with the reason "No matching allow rule (default deny)." That's the network-policy-only baseline.

Part 2: attach both MCPs at sandbox creation time. The agent in sandbox-alpha has no Wikipedia or web-search tool right now. We're going to give it both by recreating the sandbox with the MCPs declared up front via --static-mcp. This is the reliable path in current sbx builds; the runtime-attach flow (sbx mcp load) has known constraints, and the create-time flow works cleanly.

Exit the agent (Terminal A) with Ctrl+C twice to free the sandbox. Then switch to Terminal B and remove sandbox-alpha (it currently has no MCPs, so we're going to swap it for one that does):

sbx rm sandbox-alpha

Confirm the removal at the y/N prompt. Now recreate sandbox-alpha with both MCPs declared at create time:

sbx create --name sandbox-alpha --static-mcp wiki-mcp --static-mcp duck-mcp claude ~/workshop/sbx

sbx create --name sandbox-alpha --static-mcp wiki-mcp --static-mcp duck-mcp claude $HOME/workshop/sbx

sbx create --name sandbox-alpha --static-mcp wiki-mcp --static-mcp duck-mcp codex ~/workshop/sbx

sbx create --name sandbox-alpha --static-mcp wiki-mcp --static-mcp duck-mcp codex $HOME/workshop/sbx

sbx create --name sandbox-alpha --static-mcp wiki-mcp --static-mcp duck-mcp opencode ~/workshop/sbx

sbx create --name sandbox-alpha --static-mcp wiki-mcp --static-mcp duck-mcp opencode $HOME/workshop/sbx

The --static-mcp flag tells sbx "spin up the sandbox with the per-sandbox MCP gateway pre-wired to these registrations." The create command doesn't print anything MCP-specific when it succeeds; the gateway wiring happens in the background.

Reconnect to the sandbox (Terminal A):

sbx run --name sandbox-alpha

The agent inside this fresh sandbox has both Wikipedia and DuckDuckGo tools available from the start. Ask an open question that naturally needs both background and current information. Don't tell the agent which tools to use; let it decide:

Watch how the agent responds. With both MCPs attached, it should reach for a Wikipedia-shaped tool for the background and a web-search-shaped tool for the recent news, picking each based on the sub-question. The final summary is the interesting part: the agent tells you which tool calls it made, and if it tried anything direct that got blocked, it should say so. Same sandbox, same agent session as Part 1; what changed is the set of capabilities the agent has to work with.

Part 3: confirm what actually happened at the network layer. Whatever the agent said it did, the audit trail is the source of truth. Switch to Terminal B and check the policy log:

sbx policy log sandbox-alpha

Two things are worth looking for in the log. First, if the agent tried to reach any domain directly before falling back to the MCP tools, you'll see that as a Blocked entry with a "no matching allow rule" reason. Some models do try the direct network path first; that attempt hits the default-deny policy and shows up in the log. Second, and this is the important half: there should be no successful Allowed entries for the information sources themselves (like wikipedia.org or duckduckgo.com). The agent got its answer through the MCP tools, which means every tool call traveled from the agent, through the MCP protocol, to the host-side MCP server, out to the underlying API on the host's network, and back. The sandbox boundary stayed in place. MCP added a new lane that runs alongside the network policy, not through it.

4.4 Wrap up

Exit the agent (Ctrl+C twice) to free your terminal for Step 5's host commands. Don't tear down sandbox-alpha or either MCP registration. Step 5 will keep using sandbox-alpha for its research demo, and the agent will have both Wikipedia and DuckDuckGo available there if it decides to use them. We'll clean up the MCP registrations in the Cleanup section at the end of the workshop.

Where the model runs matters, not just what tools it can invoke. Local inference is a governance option, one that matters for regulated data, air-gapped environments, and cost control.

What it is. Docker Model Runner (DMR) is Docker Desktop's local LLM inference feature. You pull a model with docker model pull ai/smollm2, and it runs on your machine, exposing an OpenAI-compatible endpoint at http://model-runner.docker.internal (from containers) or http://localhost:12434 (from the host, when TCP is enabled). Any client that speaks the OpenAI API (Docker Agent, IDEs, custom code) can point at that endpoint and get inference without a cloud call.

Why it matters for AI governance. The model layer is where your data goes when the agent thinks. For regulated industries (healthcare, financial services, government) and any organization with data-sovereignty policies, "the model can't see this data" is a hard constraint. Model Runner lets you satisfy that constraint at the runtime layer, not by trusting a cloud provider's data-handling policy. Same shape as the other pillars in this workshop: the capability boundary is enforced by the runtime, not by the prompt or the model.

How it composes with the other pillars. A fully-governed AI-agent setup pairs a hardened base image (DHI), a bounded environment (sbx), a curated tool surface (MCP + Gateway), and, where policy demands, a local model (DMR). You'll see a preview of this in Step 7's Core team.yaml, where the writer role runs on ai/smollm2 via provider: dmr. The Go Deeper section at the end of LP2 has a fully-local Docker Agent team where every role runs on DMR, the shape you'd start from for a regulated deploy where no cloud call is acceptable.

Confirm DMR is enabled and available on your Docker Desktop:

docker model status --json

Running status confirms DMR is up. List the models pulled locally:

docker model list

If ai/smollm2 shows up (from the Quick Setup pre-pull), you're already set. If it doesn't, pull it now:

docker model pull ai/smollm2

Docker's model catalog lives at hub.docker.com/u/ai: verified publisher, signed images, small-to-medium models suited for local inference.

The governance takeaway. Model choice is a per-role architectural knob AND a per-workload compliance constraint. Local for the roles that touch regulated data, cloud for the roles that need frontier synthesis, hybrid teams where the yaml documents the split. The Docker Agent yaml is the compliance artifact; DMR is what makes "local" a real option.

Give the agent a creative open-ended task that'll bump into the sandbox boundary. Watch the policy log while it works. Build and run what it produced, scan it with Scout, swap the base for a DHI variant, rebuild, run, and rescan.

Foundational DHI, applied end-to-end: the agent writes code, you build the container, Docker Scout scans, then you swap in the hardened base and rescan.

Governance framing: the Foundational module at the top of this workshop showed the DHI delta at the base-image level. This step applies the same swap to a real artifact the agent produced: code inside a container. The comparison here is what your supply-chain reviewer actually wants to see: same code, same Dockerfile shape, hardened vs unhardened base, side-by-side CVE reports. The artifact from this step is the Scout scan output of the hardened build.

5.1 Set up the project and the Dockerfile

On your host, create a project directory inside the workspace and a starter Dockerfile that points at python:3.14-slim. The Dockerfile stays exactly the same across both builds. We only swap the base image later. The EXPOSE 8000 line declares the port the app will listen on.

mkdir -p ~/workshop/sbx/research-app

New-Item -ItemType Directory -Force -Path $HOME/workshop/sbx/research-app | Out-Null

cd ~/workshop/sbx/research-app

cd $HOME/workshop/sbx/research-app

Write the starter Dockerfile (the agent will fill in app.py later):

echo 'FROM python:3.14-slim
WORKDIR /app
COPY app.py .
EXPOSE 8000
CMD ["python", "app.py"]' > Dockerfile

@'
FROM python:3.14-slim
WORKDIR /app
COPY app.py .
EXPOSE 8000
CMD ["python", "app.py"]
'@ | Set-Content Dockerfile

The folder is shared into the sandbox, so the agent will see the Dockerfile too. It just needs to fill in the missing app.py.

5.2 Ask the agent to build a research dashboard

Switch to the sandbox terminal. We're going to give the agent an open-ended task: build a small polished World Cup dashboard. The prompt doesn't tell the agent it's in a workshop or what we've blocked and allowed; it just describes the build. As the agent works, it'll naturally reach for sources outside the default allow list (Wikipedia, news outlets, random stats APIs), in addition to fifa.com which we unblocked in 3.3. That gives us a chance to watch the sandbox boundary you built in Step 3 enforce itself on a task you didn't anticipate. Because the prompt is open-ended, each attendee's dashboard will look a little different.

The agent will work on this for a minute or two. Network calls, attempted package installs, code generation: all of it happens inside the sandbox. While it works, leave the agent running and head back to a host terminal for the next substep.

5.3 Watch the sandbox boundary in action

On a host terminal, print the policy log for the sandbox:

sbx policy log sandbox-alpha

You'll see every network call the agent has made so far, split into two sections: Blocked requests and Allowed requests. Hostnames in the default-allow groups (AI providers, package managers like PyPI, code and container registries like GitHub, cloud APIs, OS package repos) appear under Allowed. Anything outside those groups (Wikipedia, news sites, weather APIs, whatever else the agent reaches for) lands under Blocked with the reason "No matching allow rule (default deny)". Re-run the command every minute or so to see new entries as the agent keeps trying things.

This is the proof Step 3 set up: the boundary holds on a task the agent invented for itself, with no extra work from you. The agent didn't agree to obey the policy. The policy holds whether the agent likes it or not.

5.4 Build and run what the agent produced

Once the agent says it's done, move into the project directory on the host:

cd ~/workshop/sbx/research-app

cd $HOME/workshop/sbx/research-app

Build the image:

docker build -t research-app:v1 .

Run the container in the background, mapping port 8000 from the container to your host:

docker run -d --rm -p 8000:8000 --name research-app research-app:v1

Open http://localhost:8000 in your browser. The dashboard the agent built will render with whatever topic it picked. Look for the "Notes" or "Constraints" section. That's where the agent documented what the sandbox stopped it from doing.

When you're done looking at it, stop the container:

docker stop research-app

5.5 Scan the image with Docker Scout

Scan the image we just built and ran to see the CVEs it inherits from python:3.14-slim:

docker scout quickview research-app:v1

  Target     │  research-app:v1
    digest   │  sha256:abc123...
  Base image │  python:3.14-slim

  CVES  │  C    H    M    L
  ──────┼─────────────────────
        │  1    2    3    25

Read off the critical / high / medium / low counts. Every CVE here comes from the base image, not from the dashboard code the agent just wrote.

To see the actual list of CVEs that quickview just counted, run:

docker scout cves research-app:v1

This prints every CVE Scout found, with severity, package, and a short description. Scroll through it. The dozens of items that quickview summarized are real, named, and attributable to specific packages in the base image.

5.6 Swap the base for the DHI variant, rebuild, run, and rescan

DHI images live under the dhi.io namespace, which requires a one-time login with your Docker Hub credentials before the pull works:

docker login dhi.io

Username is your Docker Hub username. Password is a Docker Hub access token (or your password if you don't use tokens).

Now change exactly one line of the Dockerfile to point at the DHI equivalent:

sed -i.bak 's|FROM python:3.14-slim|FROM dhi.io/python:3.14|' Dockerfile

(Get-Content Dockerfile) -replace 'FROM python:3.14-slim', 'FROM dhi.io/python:3.14' | Set-Content Dockerfile

mv Dockerfile.bak Dockerfile 2>/dev/null || sed -i.bak 's|FROM dhi.io/python:3.14|FROM python:3.14-slim|' Dockerfile

(Get-Content Dockerfile) -replace 'FROM dhi.io/python:3.14', 'FROM python:3.14-slim' | Set-Content Dockerfile

sbx run --name sandbox-alpha

grep -n '^FROM' Dockerfile

Select-String -Path Dockerfile -Pattern '^FROM'

Rebuild the image with the same flags as before, this time tagged :v2:

docker build -t research-app:v2 .

Run it the same way as before to confirm it still serves the page:

docker run -d --rm -p 8000:8000 --name research-app research-app:v2

Hit http://localhost:8000 again. Same dashboard, same content, same behavior. Then stop the container:

docker stop research-app

And rescan with Scout:

docker scout quickview research-app:v2

  Target     │  research-app:v2
    digest   │  sha256:def456...
  Base image │  dhi.io/python:3.14

  CVES  │  C    H    M    L
  ──────┼─────────────────────
        │  0    0    1    2

The app code stays the same, the Dockerfile structure stays the same, the runtime command stays the same, and the page in your browser looks identical. The only difference between the two scans is a single substitution: python:3.14-slim becomes dhi.io/python:3.14. The application code, the build steps, the runtime command, and the deployment pipeline all stay identical.

And as before, get the detail listing for the v2 image:

docker scout cves research-app:v2

Compare what you see here against the v1 image's list from 5.5. The v2 image's CVE list is dramatically shorter, often just a small handful of low-severity items, sometimes none at all.

5.7 Compare the two scans side by side

You now have both images locally. Docker Scout has a compare subcommand that prints a direct diff of the vulnerabilities between two images, which makes the v1-vs-v2 delta unmissable:

docker scout compare --to research-app:v1 research-app:v2

The output shows which CVEs are present in research-app:v1 but no longer in research-app:v2, which (if any) appeared in v2 that weren't in v1, and a summary count diff for critical / high / medium / low. The "removed" list is the security debt the hardened base eliminated without you changing a single line of application code.

Package the sandbox setup you've been doing by hand into a declarative kit anyone on your team can pull and run with one command.

One directory. One commit. One artifact your compliance team can review as your team's governed environment.

In Steps 1 through 5 you set up a sandbox, proved its isolation, configured a network policy, added an MCP tool, and ran a hardened build. This is a useful pattern, but the setup was ad-hoc. You typed the commands by hand, edited the files manually, and attached the MCP one piece at a time. The next person on your team would have to repeat all of it from memory. An sbx Kit packages that setup into a declarative artifact: a spec.yaml plus an optional files/ tree. You commit it to git. Anyone on your team clones the kit, runs one sbx command, and gets the same configured sandbox you have.

Governance framing: a kit turns "our team's governance policy" from a wiki page (that people forget to check) into a runtime artifact (that the sandbox enforces on every launch). Network rules, allowed MCPs, permitted skills: bake them into the kit, commit the kit, and every future sandbox on your team gets the same policy. This is the artifact your compliance team can point at when they need to answer "how do we enforce our AI-usage policy across the org."

Kits come in two flavors. Mixin kits (kind: mixin) add capability to one of the built-in agents: skills, network rules, config files, credentials. You can stack several on the same sandbox. Agent kits (kind: agent) replace the agent definition itself: container image, entrypoint, base policy, the lot. The built-in claude agent you've been using this whole workshop is itself an agent kit, and you can fork it to change one thing (a different model, stricter permissions, a custom system prompt) without rebuilding the rest. For this step we'll build a mixin kit called docker-review. It ships a Claude Code skill with a five-point Dockerfile checklist: base image, layer order, image size, security, and reproducibility. Without the kit, asking the agent to "review my Dockerfile" gets you whatever the model decides to look at on a given day. With the kit installed, every reviewer on your team applies the same checklist consistently.

6.1 Create the kit directory structure

Kits live in their own directory, separate from the sandbox workspace. We'll put ours at ~/workshop/kits/docker-review. The structure is two pieces: a spec.yaml (the kit metadata) and a files/workspace/ tree that maps directly to the sandbox workspace. Anything you put under files/workspace/ gets injected into the workspace at sandbox creation.

Create the directory tree:

mkdir -p ~/workshop/kits/docker-review/files/workspace/.claude/skills/docker-review

New-Item -ItemType Directory -Force -Path $HOME/workshop/kits/docker-review/files/workspace/.claude/skills/docker-review | Out-Null

Claude Code automatically discovers skills from .claude/skills/ in the workspace. By dropping a SKILL.md there, the kit makes the skill available the moment the sandbox starts. There's no install command to run and no manual "load this skill" prompt to issue; the kit just drops files into the right place at create time.

Other providers The .claude/skills/ path originated as Claude Code's convention and is also honored by OpenCode. Codex uses its own skill-loading path; if your agent doesn't auto-discover the skill, change the path under files/workspace/ to match your harness. The kit machinery is identical either way.

6.2 Write the kit spec

Create the spec.yaml at ~/workshop/kits/docker-review/spec.yaml:

echo 'schemaVersion: "1"
kind: mixin
name: docker-review
displayName: Dockerfile review skill
description: Ships a Claude Code skill that reviews Dockerfiles for best practices' > ~/workshop/kits/docker-review/spec.yaml

@'
schemaVersion: "1"
kind: mixin
name: docker-review
displayName: Dockerfile review skill
description: Ships a Claude Code skill that reviews Dockerfiles for best practices
'@ | Set-Content $HOME/workshop/kits/docker-review/spec.yaml

The fields: schemaVersion is the spec format version. kind is either mixin (extends an existing agent) or agent (defines a new one from scratch). name is the kit identifier. displayName and description are human-readable. That's the whole spec for a file-only mixin kit. There are no network rules and no install commands, only the file injection handled by the files/ tree we'll populate next.

6.3 Write the skill

Create SKILL.md at ~/workshop/kits/docker-review/files/workspace/.claude/skills/docker-review/SKILL.md. The file has YAML frontmatter (the skill's name and when to use it) followed by the instructions Claude Code follows when the skill loads:

echo '---
name: docker-review
description: Review a Dockerfile for best practices. Use when the user asks to review, audit, or improve a Dockerfile.
---

When reviewing a Dockerfile, output ONLY a Markdown table with exactly the columns and exactly the five rows below, in this exact order. Do not write any prose before or after the table.

| # | Aspect | Status | Findings | Recommendation |
| --- | --- | --- | --- | --- |
| 1 | Base image | Pass / Warn / Fix | What the Dockerfile does (pinned tag or digest? minimal? appropriate for the workload?) | What to change, or None |
| 2 | Layer order | Pass / Warn / Fix | What the Dockerfile does (dependencies installed before application source? cache reuse?) | What to change, or None |
| 3 | Image size | Pass / Warn / Fix | What the Dockerfile does (multi-stage build? .dockerignore present? package-manager cache flags like --no-cache, --no-install-recommends?) | What to change, or None |
| 4 | Security | Pass / Warn / Fix | What the Dockerfile does (non-root USER? secrets kept out of ARG/ENV? no --privileged?) | What to change, or None |
| 5 | Reproducibility | Pass / Warn / Fix | What the Dockerfile does (pinned package versions? explicit COPY targets?) | What to change, or None |

Rules:
- Use exactly one of Pass, Warn, or Fix in the Status column. Pass = meets best practice. Warn = works but could be tightened. Fix = real problem.
- Always produce all five rows in the exact order shown. Never add a row, drop a row, or reorder.
- Fill Findings with what you actually see in the Dockerfile under that aspect, not generic advice.
- Fill Recommendation with the specific change to make. If Status is Pass, write the word None.
- No commentary outside the table.' > ~/workshop/kits/docker-review/files/workspace/.claude/skills/docker-review/SKILL.md

@'
---
name: docker-review
description: Review a Dockerfile for best practices. Use when the user asks to review, audit, or improve a Dockerfile.
---

When reviewing a Dockerfile, output ONLY a Markdown table with exactly the columns and exactly the five rows below, in this exact order. Do not write any prose before or after the table.

| # | Aspect | Status | Findings | Recommendation |
| --- | --- | --- | --- | --- |
| 1 | Base image | Pass / Warn / Fix | What the Dockerfile does (pinned tag or digest? minimal? appropriate for the workload?) | What to change, or None |
| 2 | Layer order | Pass / Warn / Fix | What the Dockerfile does (dependencies installed before application source? cache reuse?) | What to change, or None |
| 3 | Image size | Pass / Warn / Fix | What the Dockerfile does (multi-stage build? .dockerignore present? package-manager cache flags like --no-cache, --no-install-recommends?) | What to change, or None |
| 4 | Security | Pass / Warn / Fix | What the Dockerfile does (non-root USER? secrets kept out of ARG/ENV? no --privileged?) | What to change, or None |
| 5 | Reproducibility | Pass / Warn / Fix | What the Dockerfile does (pinned package versions? explicit COPY targets?) | What to change, or None |

Rules:
- Use exactly one of Pass, Warn, or Fix in the Status column. Pass = meets best practice. Warn = works but could be tightened. Fix = real problem.
- Always produce all five rows in the exact order shown. Never add a row, drop a row, or reorder.
- Fill Findings with what you actually see in the Dockerfile under that aspect, not generic advice.
- Fill Recommendation with the specific change to make. If Status is Pass, write the word None.
- No commentary outside the table.
'@ | Set-Content $HOME/workshop/kits/docker-review/files/workspace/.claude/skills/docker-review/SKILL.md

The frontmatter's description field is critical: Claude Code uses it to decide when to invoke the skill. When the user asks something matching the description ("review my Dockerfile", "audit this Docker setup"), Claude pulls the skill content into its context and follows the structured checklist. The user doesn't have to invoke the skill by name or load it manually.

6.4 Validate the kit

Before spinning up a sandbox with the kit attached, validate the spec to catch any errors early:

sbx kit validate ~/workshop/kits/docker-review/

sbx kit validate $HOME/workshop/kits/docker-review/

If anything's wrong (malformed spec, missing required fields, broken file references), validate surfaces it before sandbox creation. A clean validation prints "kit valid" or similar and exits 0.

6.5 Create a sandbox with the kit attached

Create a fresh sandbox with the kit attached at create time. We'll call it sandbox-kits so it sits alongside sandbox-alpha (which still has the MCP from Step 4) rather than disturbing it. Run the command for the provider you picked at the top:

sbx create --name sandbox-kits --kit ~/workshop/kits/docker-review/ claude ~/workshop/sbx

sbx create --name sandbox-kits --kit $HOME/workshop/kits/docker-review/ claude $HOME/workshop/sbx

sbx create --name sandbox-kits --kit ~/workshop/kits/docker-review/ codex ~/workshop/sbx

sbx create --name sandbox-kits --kit $HOME/workshop/kits/docker-review/ codex $HOME/workshop/sbx

sbx create --name sandbox-kits --kit ~/workshop/kits/docker-review/ gemini ~/workshop/sbx

sbx create --name sandbox-kits --kit $HOME/workshop/kits/docker-review/ gemini $HOME/workshop/sbx

sbx create --name sandbox-kits --kit ~/workshop/kits/docker-review/ opencode ~/workshop/sbx

sbx create --name sandbox-kits --kit $HOME/workshop/kits/docker-review/ opencode $HOME/workshop/sbx

Attach to the new sandbox:

sbx run --name sandbox-kits

Once the agent is up, ask it to review the Dockerfile from Step 5. The skill we just shipped tells it how:

The agent loads the docker-review skill and applies its five-row review table (base image, layer order, image size, security, reproducibility). You'll see a Markdown table come back with the same five rows in the same order, each with a Pass / Warn / Fix status, the specific finding, and a recommendation. The point: what you'd get without the kit is whatever the model decides to look at and however it decides to present it; with the kit, every reviewer on your team gets the same structured table back regardless of model or run.

6.6 Wrap up

What you just did is the team-scale story: the skill traveled into the sandbox automatically. The user didn't run an install command, didn't read shared documentation, and didn't have to remember to enable anything. The kit is one directory, git-committable, copy-paste-shareable. The next person on your team clones the kit, runs the same sbx command, and gets the same skill loaded the same way.

Exit the agent (Ctrl+C twice), then tear down the kit sandbox so we're back to just sandbox-alpha for the rest of the workshop:

sbx stop sandbox-kits

sbx rm sandbox-kits

Leave ~/workshop/kits/docker-review/ in place; it's the artifact you'd commit to your team's repo. The full cleanup of the kit directory is in the Cleanup section at the end of the workshop.

Step out of the single-agent model. Spin up a small team where each role has its own tools, its own instruction, and they hand off work to each other.

The yaml declares what each role can do. The runtime enforces it. Your security team can read the yaml and know exactly what capabilities you granted where.

A single agent is fine when the task is bounded. The pattern starts to fray when the work spans roles that each want different tools: a researcher who needs to read sources, a writer who needs to edit files, a reviewer who shouldn't have either. The choice becomes give one agent everything (which violates the least-capability instinct we've been building all workshop) or split the work across specialized agents.

Governance framing: a multi-agent team is the point where per-role scoping becomes essential, and where a compliance-ready artifact becomes possible. The yaml you're about to write names each role, lists its tools, and declares its instruction. The runtime enforces the toolset boundary (Step 8 tests this). That yaml is legible to a non-engineer security reviewer: "the wiki-researcher has these three tools, the writer has these two, the analyst has none other than think." No hidden capability, no prompt-injection route to a tool the role wasn't granted. This is what your compliance team wants to see.

Docker Agent is a different piece of Docker's agent platform from sbx. sbx is the foundational sandbox runtime; Docker Agent is the multi-agent orchestrator. Instead of one agent with one set of tools, Docker Agent runs a small declared team. You write a yaml that names the roles, what each one does, what tools each one gets, and how they hand off. Docker Agent runs the whole team in one process on your host.

Two ideas land in this step. First, a glimpse of the platform: Docker Agent sits at a different layer than sbx, complementary rather than stacked. Steps 7 and 8 step outside the sandbox you've been working with to show what multi-agent orchestration looks like today. Second, per-role scoping: the team inside Docker Agent is declarative, and each role's tools are scoped at definition time. The yaml is the contract.

7.1 Confirm Docker Agent is available, then set your API key

Docker Agent is a Docker CLI plugin, invoked as docker agent <command> (the same shape as docker scout earlier in the workshop). If you're on Docker Desktop 4.63 or newer (which you should be, since you installed it before Step 4), the docker-agent plugin is already bundled. Verify it:

docker agent version

If it prints a version line, you're done with install. Skip to the API key block below.

If docker agent isn't recognized Your Docker Desktop is older than 4.63, or the plugin wasn't installed for some reason. On Mac, install via Homebrew. On Windows, download the docker-agent-windows-*.exe binary from the GitHub releases page and drop it in %USERPROFILE%\.docker\cli-plugins\ (create that folder if it doesn't exist).

brew install docker-agent

# See the GitHub releases link above for the binary download.
# Or, if Docker Desktop has just updated, restart it and try docker agent version again.

Docker Agent reads its API key from ANTHROPIC_API_KEY in the shell environment. sbx stored your key in its own secret store for sandbox-internal use, but Docker Agent runs on the host, so the key needs to be exported as a shell env var here. Paste the Anthropic key you saved during prereq setup, or grab a fresh one from console.anthropic.com if you don't have it handy (the free credit for new accounts covers what this step uses).

export ANTHROPIC_API_KEY=sk-ant-...

$env:ANTHROPIC_API_KEY = "sk-ant-..."

This sets the variable for the current shell only. If you open a new terminal between here and 7.3 (where we'll run Docker Agent), re-run the export there too.

7.2 Write the team's spec

Docker Agent reads a yaml that declares the team. We'll write a six-role team that produces a research report end-to-end:

• root (coordinator): delegates work, does no research, writing, or publishing itself.
• wiki-researcher: gathers encyclopedic background through the Wikipedia MCP you already used in Step 4.
• paper-researcher: searches peer-reviewed academic literature through the Paper Search MCP, which can query arXiv, PubMed, Semantic Scholar, OpenAlex, CrossRef, Google Scholar, and a dozen other scholarly databases (new for this step, pulls on first use).
• analyst: synthesizes both researchers' findings into the important insights. This is the hardest task, so it runs on Claude Opus instead of Sonnet.
• writer: produces the markdown report and saves it to ./report.md.
• publisher: reads the markdown and renders it as a self-contained academic-paper-styled HTML page, saved to ./report.html. The publisher's job is presentation, not content.

Three notes on the model mix. Four of the six roles run on Claude Sonnet (fast, cheap, plenty smart for delegation, search, and HTML rendering). The analyst runs on Claude Opus because synthesis across two disparate research streams is where a heavier model earns its keep. The writer runs on a small local model via Docker Model Runner: prose assembly from an already-synthesized analysis is one of the lightest tasks in the team, and running it locally proves the point that model choice is a per-role architectural knob, not a per-team decision. Docker Agent lets you mix providers freely; if you'd rather run the writer on Sonnet too, change the writer's model: from local to fast before saving the yaml.

Before we wire it into the team, a quick word on what the Paper Search MCP actually is. mcp/paper-search is a Verified Publisher image in Docker's MCP catalog. It wraps roughly seventeen scholarly databases (arXiv, PubMed, bioRxiv, medRxiv, Semantic Scholar, OpenAlex, CrossRef, Google Scholar, Europe PMC, DOAJ, Zenodo, and others) behind the MCP protocol and exposes 57 tools: per-source search (search_arxiv, search_pubmed, search_semantic, etc.) plus a unified search_papers that hits multiple sources at once, plus download tools that fetch PDFs by ID and read tools that extract text from those PDFs. The paper-researcher role in this workshop primarily uses the search tools and returns structured lists of papers with titles, authors, DOIs, and abstracts. No API key is required; the image talks to public academic APIs directly.

Optionally, pre-pull the image now so the first delegation to the paper-researcher doesn't pause for a Docker pull:

docker pull mcp/paper-search

Create a folder and the yaml file:

mkdir -p ~/workshop/docker-agent

New-Item -ItemType Directory -Force -Path $HOME/workshop/docker-agent | Out-Null

cd ~/workshop/docker-agent

cd $HOME/workshop/docker-agent

Now write team.yaml with the six roles. Each role names its model, what it's for, and the toolsets it has access to:

cat > team.yaml <<'EOF'
version: "2"

models:
  fast:
    provider: anthropic
    model: claude-sonnet-4-6
    max_tokens: 8192

  deep:
    provider: anthropic
    model: claude-opus-4-6
    max_tokens: 8192

  local:  # small model running on host via Docker Model Runner; no cloud API call
    provider: dmr
    model: ai/smollm2
    max_tokens: 4096

agents:
  root:
    model: fast
    description: Coordinator of a research and report-writing team
    instruction: |
      You coordinate a research-and-report team. Your team:

      - wiki-researcher: gathers encyclopedic background from Wikipedia
      - paper-researcher: searches peer-reviewed academic literature via Paper Search
      - analyst: synthesizes findings from the researchers (running on Opus)
      - writer: produces the markdown report and saves it as ./report.md
      - publisher: reads the markdown and renders an academic-paper-styled ./report.html

      When the user gives you a topic, decide which team members to call and in what
      order based on the request. Before each delegation, narrate what you are about
      to do and why in one or two short sentences, so the user can see your reasoning.
      Briefly note what you got back after each delegation. Do not pad the narration.

      The deliverable is two files in the working directory: ./report.md and
      ./report.html. When both files are saved, return a one-line summary to the user.

      You do not research, analyze, write, or publish yourself. You only delegate,
      narrate, and report.
    sub_agents: [wiki-researcher, paper-researcher, analyst, writer, publisher]
    toolsets:
      - type: think  # internal scratchpad for delegation reasoning, no external side effects

  wiki-researcher:
    model: fast
    description: Wikipedia background researcher
    instruction: |
      You gather encyclopedic background from Wikipedia. Use the Wikipedia tools to search
      and retrieve relevant articles. Return a tight bulleted list of AT MOST 8 key facts,
      one short line each, with the source article title in parens. Be terse; the writer
      downstream has a compact ~800-word cap and you should not crowd them out. Do not write prose.
      Do not save files.
    toolsets:
      - type: mcp  # Wikipedia search and article retrieval (22 tools, no API key needed)
        command: docker
        args: ["run", "-i", "--rm", "mcp/wikipedia-mcp"]

  paper-researcher:
    model: fast
    description: Academic literature researcher
    instruction: |
      You search peer-reviewed academic literature. Use the Paper Search tools to query
      arXiv, PubMed, Semantic Scholar, OpenAlex, and similar sources. Return AT MOST 6
      papers, each on one line: title, first author, year, source, and a one-sentence
      finding. Do not download or read full PDFs. Be terse; the writer downstream has
      a compact ~800-word cap. Do not write prose. Do not save files.
    toolsets:
      - type: mcp  # academic literature search across arXiv, PubMed, Semantic Scholar, OpenAlex, and others (57 tools, no API key needed)
        command: docker
        args: ["run", "-i", "--rm", "mcp/paper-search"]

  analyst:
    model: deep
    description: Synthesis specialist
    instruction: |
      You receive findings from the wiki-researcher (encyclopedic background) and the
      paper-researcher (peer-reviewed literature). Distill them into AT MOST 5 key
      insights, one short paragraph each. Surface tensions or contradictions between
      the two streams when they exist. Be ruthlessly concise; the writer downstream has
      a compact ~800-word cap and your analysis must fit inside that envelope. Use the think
      tool to reason. Do not search anything yourself. Do not write the final report.
    toolsets:
      - type: think  # internal scratchpad for synthesis, no external side effects

  writer:
    model: local  # runs on host via Docker Model Runner; flip to 'fast' for higher-quality prose
    description: Briefing writer (running locally)
    instruction: |
      You receive an analysis and write a short briefing as ./report.md.
      Target 500 to 800 words. Structure it in three parts: a short Abstract
      (2 to 3 sentences), a Findings section (bulleted list of the analyst's
      key insights, one line each), and a Sources section (the papers the
      paper-researcher returned, one per line with title, authors, year, source).
      Keep sentences short and direct. Do not invent facts beyond what the analyst
      provided. Do not search anything.
    toolsets:
      - type: filesystem  # read and write files in the working directory (writes report.md)

  publisher:
    model: fast
    description: Academic-paper publisher
    instruction: |
      You read ./report.md and produce a self-contained HTML version that looks like
      a real academic paper. Save it as ./report.html.

      Embed CSS in a <style> tag. Style targets: serif body font (Crimson Text or
      Charter via Google Fonts, with a system serif fallback), max-width around 720px,
      centered page on white background. Centered title at the top. Italic abstract
      block with a small "Abstract" label. Section headings in small caps or bold
      serif at a modest size. Justified body text with reasonable line-height (1.5
      to 1.6). References at the bottom with hanging indent. No navigation, no
      footer, no Docker or workshop branding, no decorative emoji or icons. Just
      the paper.

      Transcribe the markdown structure into the HTML faithfully. Preserve every fact
      and citation. Do not invent content, do not summarize, do not editorialize. The
      publisher's only job is presentation, not authorship.
    toolsets:
      - type: filesystem  # read and write files in the working directory (reads report.md, writes report.html)
EOF

@'
version: "2"

models:
  fast:
    provider: anthropic
    model: claude-sonnet-4-6
    max_tokens: 8192

  deep:
    provider: anthropic
    model: claude-opus-4-6
    max_tokens: 8192

  local:  # small model running on host via Docker Model Runner; no cloud API call
    provider: dmr
    model: ai/smollm2
    max_tokens: 4096

agents:
  root:
    model: fast
    description: Coordinator of a research and report-writing team
    instruction: |
      You coordinate a research-and-report team. Your team:

      - wiki-researcher: gathers encyclopedic background from Wikipedia
      - paper-researcher: searches peer-reviewed academic literature via Paper Search
      - analyst: synthesizes findings from the researchers (running on Opus)
      - writer: produces the markdown report and saves it as ./report.md
      - publisher: reads the markdown and renders an academic-paper-styled ./report.html

      When the user gives you a topic, decide which team members to call and in what
      order based on the request. Before each delegation, narrate what you are about
      to do and why in one or two short sentences, so the user can see your reasoning.
      Briefly note what you got back after each delegation. Do not pad the narration.

      The deliverable is two files in the working directory: ./report.md and
      ./report.html. When both files are saved, return a one-line summary to the user.

      You do not research, analyze, write, or publish yourself. You only delegate,
      narrate, and report.
    sub_agents: [wiki-researcher, paper-researcher, analyst, writer, publisher]
    toolsets:
      - type: think  # internal scratchpad for delegation reasoning, no external side effects

  wiki-researcher:
    model: fast
    description: Wikipedia background researcher
    instruction: |
      You gather encyclopedic background from Wikipedia. Use the Wikipedia tools to search
      and retrieve relevant articles. Return a tight bulleted list of AT MOST 8 key facts,
      one short line each, with the source article title in parens. Be terse; the writer
      downstream has a compact ~800-word cap and you should not crowd them out. Do not write prose.
      Do not save files.
    toolsets:
      - type: mcp  # Wikipedia search and article retrieval (22 tools, no API key needed)
        command: docker
        args: ["run", "-i", "--rm", "mcp/wikipedia-mcp"]

  paper-researcher:
    model: fast
    description: Academic literature researcher
    instruction: |
      You search peer-reviewed academic literature. Use the Paper Search tools to query
      arXiv, PubMed, Semantic Scholar, OpenAlex, and similar sources. Return AT MOST 6
      papers, each on one line: title, first author, year, source, and a one-sentence
      finding. Do not download or read full PDFs. Be terse; the writer downstream has
      a compact ~800-word cap. Do not write prose. Do not save files.
    toolsets:
      - type: mcp  # academic literature search across arXiv, PubMed, Semantic Scholar, OpenAlex, and others (57 tools, no API key needed)
        command: docker
        args: ["run", "-i", "--rm", "mcp/paper-search"]

  analyst:
    model: deep
    description: Synthesis specialist
    instruction: |
      You receive findings from the wiki-researcher (encyclopedic background) and the
      paper-researcher (peer-reviewed literature). Distill them into AT MOST 5 key
      insights, one short paragraph each. Surface tensions or contradictions between
      the two streams when they exist. Be ruthlessly concise; the writer downstream has
      a compact ~800-word cap and your analysis must fit inside that envelope. Use the think
      tool to reason. Do not search anything yourself. Do not write the final report.
    toolsets:
      - type: think  # internal scratchpad for synthesis, no external side effects

  writer:
    model: local  # runs on host via Docker Model Runner; flip to 'fast' for higher-quality prose
    description: Briefing writer (running locally)
    instruction: |
      You receive an analysis and write a short briefing as ./report.md.
      Target 500 to 800 words. Structure it in three parts: a short Abstract
      (2 to 3 sentences), a Findings section (bulleted list of the analyst's
      key insights, one line each), and a Sources section (the papers the
      paper-researcher returned, one per line with title, authors, year, source).
      Keep sentences short and direct. Do not invent facts beyond what the analyst
      provided. Do not search anything.
    toolsets:
      - type: filesystem  # read and write files in the working directory (writes report.md)

  publisher:
    model: fast
    description: Academic-paper publisher
    instruction: |
      You read ./report.md and produce a self-contained HTML version that looks like
      a real academic paper. Save it as ./report.html.

      Embed CSS in a <style> tag. Style targets: serif body font (Crimson Text or
      Charter via Google Fonts, with a system serif fallback), max-width around 720px,
      centered page on white background. Centered title at the top. Italic abstract
      block with a small "Abstract" label. Section headings in small caps or bold
      serif at a modest size. Justified body text with reasonable line-height (1.5
      to 1.6). References at the bottom with hanging indent. No navigation, no
      footer, no Docker or workshop branding, no decorative emoji or icons. Just
      the paper.

      Transcribe the markdown structure into the HTML faithfully. Preserve every fact
      and citation. Do not invent content, do not summarize, do not editorialize. The
      publisher's only job is presentation, not authorship.
    toolsets:
      - type: filesystem  # read and write files in the working directory (reads report.md, writes report.html)
'@ | Set-Content team.yaml

Three things to notice in this yaml. The models block declares three model profiles: fast (Sonnet, cloud), deep (Opus, cloud), and local (smollm2 running on your host via Docker Model Runner). Each role picks the profile that fits. The agents block lists the team: root is the coordinator, and its sub_agents field names the five roles it can delegate to. The toolsets field on each role is the per-role capability scoping: wiki-researcher gets only the Wikipedia MCP, paper-researcher gets only the Paper Search MCP, analyst gets only think, writer and publisher each get only filesystem (writer to produce the markdown, publisher to read it and write the HTML), and the coordinator gets only think. That scoping is the boundary Step 8 will test.

7.3 Run the team

Make sure you are in ~/workshop/docker-agent and your ANTHROPIC_API_KEY is set in the current shell. Here's the prompt the team will work from:

Two ways to run the team. Both produce the same output; pick whichever fits your style.

Option A: one-shot mode. The prompt is passed as the second argument and the team runs end-to-end without interactive chat. Docker Agent exits cleanly when the team finishes. Best for predictable runs and clean log capture.

docker agent run team.yaml "Write me a short academic-style briefing on the 2026 FIFA World Cup. Use Wikipedia for background, and the academic literature for findings on World Cup economic impact, infrastructure, and host-country outcomes. Keep it tight. Save as report.md."

Option B: interactive mode. Run without a prompt argument and Docker Agent opens a chat session. Paste the prompt above when prompted, watch the team work, and follow up with revisions or extensions if you want. Best for iterating on the team's behavior.

docker agent run team.yaml

Watch the output. The coordinator narrates each step as it goes ("I'm about to delegate to wiki-researcher because..."), so its reasoning is visible in plain language. The coordinator picks who to call and in what order based on the request, so the exact sequence is its decision and may vary slightly between runs. A typical run looks like this: wiki-researcher invokes Wikipedia tools and returns encyclopedic background on the tournament, paper-researcher queries arXiv, PubMed, Semantic Scholar, and the other academic sources and returns a list of papers on World Cup economics and hosting impact (real titles, authors, DOIs), analyst (running on Opus) synthesizes the two streams into the most important insights, writer (running on the local ai/smollm2 model via Docker Model Runner) assembles a short briefing with Abstract, Findings, and Sources sections and saves report.md, and publisher reads the markdown and produces a self-contained report.html styled to look like a real academic paper. The coordinator's narration between each step shows you why it chose to call that role next. You'll notice the writer step feels a beat slower than the others (local inference is single-machine, no distant datacenter), which is the tell that this role is running on your laptop.

Verify both files landed. Read the markdown first:

cat ~/workshop/docker-agent/report.md

Get-Content $HOME/workshop/docker-agent/report.md

You should see a short briefing on the 2026 FIFA World Cup with Abstract, Findings, and Sources sections. Sources enumerates every paper the paper-researcher returned, with real titles, authors, year, and source. No hallucinated content beyond what the researchers gathered. If the writer's prose reads a little basic or the structure looks off, that's the local model showing its limits. Flip the writer's model: from local back to fast in the yaml and re-run to see the same team on Sonnet.

Now open the HTML version in your browser:

open ~/workshop/docker-agent/report.html

Start-Process $HOME/workshop/docker-agent/report.html

The HTML page should look like an academic paper: serif body font, centered title, italic abstract block, small-caps section headings, justified body text, and a properly-formatted References list with hanging indent. Same content as the markdown, just typeset.

The boundary held end to end: each researcher gathered through its own MCP and nowhere else; the analyst reasoned without searching; the writer wrote without searching; the publisher read and re-rendered without searching or analyzing. Each role stayed in its lane because the yaml said so.

7.4 Wrap up

One-shot mode exits cleanly after the team finishes. Leave team.yaml in place; Step 8 uses the same yaml to demonstrate the per-role boundary. report.md and report.html can stay or be deleted; they're byproducts and Step 8 doesn't depend on them.

docker mcp gateway run --port 8811 --transport streaming --catalog docker-mcp --servers wikipedia-mcp,duckduckgo,paper-search

> Gateway URL: http://localhost:8811/mcp
> Use Bearer token: Authorization: Bearer <random-per-session-token>

export GATEWAY_TOKEN=<paste-your-token-here>

$env:GATEWAY_TOKEN = "<paste-your-token-here>"

cat > team-gateway.yaml <<'EOF'
version: "9"

models:
  fast:
    provider: anthropic
    model: claude-sonnet-4-6
    max_tokens: 8192

  deep:
    provider: anthropic
    model: claude-opus-4-6
    max_tokens: 8192

  local:
    provider: dmr
    model: ai/smollm2
    max_tokens: 4096

agents:
  root:
    model: fast
    description: Coordinator of a research and report-writing team
    instruction: |
      You coordinate a research-and-report team. Team members: wiki-researcher,
      paper-researcher, analyst, writer, publisher. Delegate work, narrate what
      you are doing between delegations, and return report.md and report.html
      when done. Do not research, analyze, write, or publish yourself.
    sub_agents: [wiki-researcher, paper-researcher, analyst, writer, publisher]
    toolsets:
      - type: think

  wiki-researcher:
    model: fast
    description: Wikipedia background researcher (via Gateway)
    instruction: |
      Use the Wikipedia tools from the MCP Gateway. Return AT MOST 8 key
      facts, one short line each. Be terse. Do not write prose. Do not save files.
    toolsets:
      - type: mcp
        remote:
          url: http://localhost:8811/mcp
          transport_type: streamable
          headers:
            Authorization: Bearer $GATEWAY_TOKEN
        allow_private_ips: true

  paper-researcher:
    model: fast
    description: Academic literature researcher (via Gateway)
    instruction: |
      Use the Paper Search tools from the MCP Gateway (arXiv, PubMed, Semantic
      Scholar, OpenAlex). Return AT MOST 6 papers, one line each. Do not
      download PDFs. Be terse. Do not write prose. Do not save files.
    toolsets:
      - type: mcp
        remote:
          url: http://localhost:8811/mcp
          transport_type: streamable
          headers:
            Authorization: Bearer $GATEWAY_TOKEN
        allow_private_ips: true

  analyst:
    model: deep
    description: Synthesis specialist
    instruction: |
      Receive findings from both researchers. Distill into AT MOST 5 key
      insights, one short paragraph each. Surface tensions between the two
      streams when they exist. Use the think tool. Do not search anything.
    toolsets:
      - type: think

  writer:
    model: local
    description: Briefing writer (running locally)
    instruction: |
      Write a short briefing as ./report.md. Target 500 to 800 words:
      Abstract (2 to 3 sentences), Findings (bulleted key insights), Sources
      (papers the paper-researcher returned). Do not invent facts.
    toolsets:
      - type: filesystem

  publisher:
    model: fast
    description: Academic-paper publisher
    instruction: |
      Read ./report.md and produce a self-contained ./report.html styled as
      an academic paper. Serif body font, centered title, italic abstract,
      justified body, hanging-indent references. No emoji, no branding.
    toolsets:
      - type: filesystem
EOF

@'
version: "9"

models:
  fast:
    provider: anthropic
    model: claude-sonnet-4-6
    max_tokens: 8192

  deep:
    provider: anthropic
    model: claude-opus-4-6
    max_tokens: 8192

  local:
    provider: dmr
    model: ai/smollm2
    max_tokens: 4096

agents:
  root:
    model: fast
    description: Coordinator of a research and report-writing team
    instruction: |
      You coordinate a research-and-report team. Team members: wiki-researcher,
      paper-researcher, analyst, writer, publisher. Delegate work, narrate what
      you are doing between delegations, and return report.md and report.html
      when done. Do not research, analyze, write, or publish yourself.
    sub_agents: [wiki-researcher, paper-researcher, analyst, writer, publisher]
    toolsets:
      - type: think

  wiki-researcher:
    model: fast
    description: Wikipedia background researcher (via Gateway)
    instruction: |
      Use the Wikipedia tools from the MCP Gateway. Return AT MOST 8 key
      facts, one short line each. Be terse. Do not write prose. Do not save files.
    toolsets:
      - type: mcp
        remote:
          url: http://localhost:8811/mcp
          transport_type: streamable
          headers:
            Authorization: Bearer $GATEWAY_TOKEN
        allow_private_ips: true

  paper-researcher:
    model: fast
    description: Academic literature researcher (via Gateway)
    instruction: |
      Use the Paper Search tools from the MCP Gateway (arXiv, PubMed, Semantic
      Scholar, OpenAlex). Return AT MOST 6 papers, one line each. Do not
      download PDFs. Be terse. Do not write prose. Do not save files.
    toolsets:
      - type: mcp
        remote:
          url: http://localhost:8811/mcp
          transport_type: streamable
          headers:
            Authorization: Bearer $GATEWAY_TOKEN
        allow_private_ips: true

  analyst:
    model: deep
    description: Synthesis specialist
    instruction: |
      Receive findings from both researchers. Distill into AT MOST 5 key
      insights, one short paragraph each. Surface tensions between the two
      streams when they exist. Use the think tool. Do not search anything.
    toolsets:
      - type: think

  writer:
    model: local
    description: Briefing writer (running locally)
    instruction: |
      Write a short briefing as ./report.md. Target 500 to 800 words:
      Abstract (2 to 3 sentences), Findings (bulleted key insights), Sources
      (papers the paper-researcher returned). Do not invent facts.
    toolsets:
      - type: filesystem

  publisher:
    model: fast
    description: Academic-paper publisher
    instruction: |
      Read ./report.md and produce a self-contained ./report.html styled as
      an academic paper. Serif body font, centered title, italic abstract,
      justified body, hanging-indent references. No emoji, no branding.
    toolsets:
      - type: filesystem
'@ | Set-Content team-gateway.yaml

docker agent run team-gateway.yaml "Write me a short academic-style briefing on the 2026 FIFA World Cup. Use Wikipedia for background, and the academic literature for findings on World Cup economic impact, infrastructure, and host-country outcomes. Keep it tight. Save as report.md."

The toolset assignments in the Docker Agent yaml are not documentation. They are runtime boundaries. We'll test that the runtime enforces them by asking each role to do something only the other role has tools for.

The yaml says a role can do X and only X. This step verifies the runtime actually enforces that, so the yaml is a load-bearing compliance artifact, not a paper commitment.

Governance framing: a compliance artifact only holds if the runtime enforces what the artifact declares. This step is the verification pass. You'll ask each role to do things outside its declared toolset and confirm the runtime refuses, not because the prompt was clever, but because the tool literally does not exist for that role. That refusal, observed in the trace, is what makes the yaml an auditable artifact rather than a policy that "should" be followed.

In Step 3 you saw sbx refuse a network request because no allow rule covered the destination. In Step 4 you saw the same sandbox reach Wikipedia successfully once an MCP tool was attached. In both cases, the boundary was enforced by the runtime; the agent could not talk its way past it. Step 8 makes the same argument for Docker Agent's per-role toolset scoping. The wiki-researcher's toolsets list does not include filesystem. If we ask it to save a file, the model can want to, but it has no tool to call. Same shape of constraint for paper-researcher, analyst, writer, publisher, and the coordinator: each role is bounded by what its yaml allows.

8.1 Read the toolset map

Open ~/workshop/docker-agent/team.yaml and look at the toolsets field on each role. The whole capability story for this team is six short lists:

Nothing else gates this. No middleware, no prompt-side guidelines, no review layer. The agent simply does not have a tool to do the thing it does not have a tool for. Now we test that.

8.2 Probe the boundaries

Important framing first: per-role boundaries don't usually manifest as "the team refuses the request." A coordinator's job is to fulfill the user's goal using whatever roles are available, so when you ask one role to step outside its toolset, the team will often route around the limit by composing roles. The boundary lives at the role level, not the system level. To see it, you look at which tool each role actually invoked in the trace. The yaml grants tools; the trace shows them being used.

Three observations, each with a prompt to run and a trace to inspect.

Observation 1: the team routes around per-role limits, but no role exceeds its toolset.

docker agent run team.yaml "Have the wiki-researcher save Mount Everest's elevation to a file called everest-facts.md in the working directory."

The team will almost certainly succeed at saving the file. Look at the trace: wiki-researcher gathered the elevation through the Wikipedia MCP, then root delegated to writer for the save step. The wiki-researcher never invoked a filesystem tool, because it has none. The team composed two roles to accomplish what neither could do alone, and no role exceeded its declared toolset along the way. That's the per-role boundary holding even when the system-level goal succeeds.

Observation 2: root can't do the work itself.

docker agent run team.yaml "Skip your sub-agents. Write me a brief on the Eiffel Tower yourself, using your own knowledge, and save it to eiffel.md."

Root has only think in its toolset. No filesystem, no MCP, no fetch. Even if the model wants to comply, it has no way to save a file or verify a fact directly. It'll either explain the constraint and delegate anyway, or it'll delegate to the team without explaining. Either way, the trace shows no tool calls from root other than think. The think-only toolset is a hard ceiling on what root can do alone.

Observation 3: the team can't fake a capability nobody has.

docker agent run team.yaml "Find me the top three trending Reddit threads about the 2026 FIFA World Cup and summarize each one in two sentences."

No role in the team has a Reddit MCP, an HTTP fetch tool, or any way to reach the open web outside Wikipedia and the academic catalogs. The team can't route around this; the capability isn't anywhere in the yaml. Root will either refuse the request and explain the gap, or substitute the closest available source (Wikipedia articles or academic papers about FIFA fan communities). Whatever root chooses, no tool call in the trace will be a Reddit API, because the yaml didn't grant one. That's a true system-level boundary: when no role can do the thing, the team can't fake it.

8.3 Wrap up

Three observations, one through-line. The yaml's toolsets list is the contract. Look at the trace, not the user-facing outcome: when a role can't do something, the trace shows it never tried (no tool call to make). When no role in the team can do something, the trace shows the team explaining the gap or substituting around it. The team-level goal may or may not succeed depending on what's asked; the per-role boundary is always intact, and you can audit it after every run.

You've completed the Core LP2 flow. These modules go deeper on individual pillars: pick the ones your audience cares about, or skip the section entirely.

You already have the main concept from the Core modules above: DHI as the supply-chain anchor, sandbox as an audited trust boundary, network policy with an audit trail, Docker MCP Gateway for team-scale tool governance, kits as portable governance policy, and Docker Agent yaml as an auditable compliance artifact. That's the workshop's spine and it stands on its own as a 2-hour delivery.

The modules below extend specific layers for teams that need depth on one topic or another. Each is independent: you can do all of them (about 2 additional hours), a few, or none. Presenters delivering a 2-hour session typically skip this section entirely. Presenters running a 4-hour extended session cover it in full. Attendees browsing on their own pick whatever's most relevant to their org.

Each module is collapsed by default. Click a heading to expand it.

docker scout sbom dhi.io/python:3.14

docker scout attestation dhi.io/python:3.14 --predicate-type https://slsa.dev/provenance/v0.2

dhictl verify dhi.io/python:3.14

docker scout policy list

docker scout policy evaluate dhi.io/python:3.14

sbx policy log sandbox-alpha > audit-alpha.log

awk '/^Blocked requests:/{f=1;next} /^Allowed requests:/{f=0} f && $1 ~ /:/ {print $1}' audit-alpha.log | sort | uniq -c | sort -rn

Get-Content audit-alpha.log | Select-String -Pattern '^\S+:\d+' | ForEach-Object { ($_ -split '\s+')[0] } | Group-Object | Sort-Object Count -Descending | Format-Table Count, Name

awk '/^Allowed requests:/{f=1;next} f && $1 ~ /:/ {print $1 "," $2}' audit-alpha.log | sort -u

Get-Content audit-alpha.log | Select-String -Pattern '^\S+:\d+\s+\S+' | ForEach-Object { $_.Line } | Sort-Object -Unique

awk 'BEGIN{print "destination,rule,count"} /^Blocked requests:/{f=1;next} /^Allowed requests:/{f=2;next} f && $1 ~ /:/ {print $1 "," (f==1?"blocked":"allowed") "," $NF}' audit-alpha.log > audit-alpha.csv

Get-Content audit-alpha.log | Select-String -Pattern '^\S+:\d+' | ForEach-Object { $line = $_ -split '\s+'; "$($line[0]),$($line[-1])" } | Set-Content audit-alpha.csv

toolsets:
  - type: mcp
    remote:
      url: http://localhost:<team-port>/mcp
      transport_type: streamable
      headers:
        Authorization: Bearer $<TEAM>_TOKEN
    allow_private_ips: true

cat > team-local.yaml <<'EOF'
version: "2"

models:
  local-small:
    provider: dmr
    model: ai/smollm2
    max_tokens: 4096
  local-medium:
    provider: dmr
    model: ai/qwen3
    max_tokens: 4096

agents:
  root:
    model: local-medium
    description: Coordinator (local)
    instruction: |
      You coordinate a local-only research team. Delegate to wiki-researcher,
      paper-researcher, analyst, writer, publisher. Narrate briefly between
      delegations. Save report.md and report.html.
    sub_agents: [wiki-researcher, paper-researcher, analyst, writer, publisher]
    toolsets:
      - type: think
  # (researchers, analyst, writer, publisher, each on local-small or
  # local-medium with the same toolsets as the Core team.yaml)
EOF

@'
version: "2"

models:
  local-small:
    provider: dmr
    model: ai/smollm2
    max_tokens: 4096
  local-medium:
    provider: dmr
    model: ai/qwen3
    max_tokens: 4096

agents:
  root:
    model: local-medium
    description: Coordinator (local)
    instruction: |
      You coordinate a local-only research team. Delegate to wiki-researcher,
      paper-researcher, analyst, writer, publisher. Narrate briefly between
      delegations. Save report.md and report.html.
    sub_agents: [wiki-researcher, paper-researcher, analyst, writer, publisher]
    toolsets:
      - type: think
  # (researchers, analyst, writer, publisher, each on local-small or
  # local-medium with the same toolsets as the Core team.yaml)
'@ | Set-Content team-local.yaml

docker model pull ai/qwen3

docker agent run team-local.yaml "Write me a short briefing on Docker Sandboxes and save it as report.md."

docker mcp profile push <registry>/<org>/gateway-profile:v1

docker mcp profile pull <registry>/<org>/gateway-profile:v1

mkdir -p ~/workshop/governance-package && cd ~/workshop/governance-package

New-Item -ItemType Directory -Force -Path $HOME/workshop/governance-package | Out-Null; cd $HOME/workshop/governance-package

docker scout sbom dhi.io/python:3.14 > sbom-dhi-python.json

docker scout attestation dhi.io/python:3.14 --predicate-type https://slsa.dev/provenance/v0.2 > provenance-dhi-python.json

sbx policy ls > policy-config.txt

sbx policy log sandbox-alpha > audit-log.txt

sbx mcp ls > mcp-registrations.txt

cp -r ~/workshop/kits/docker-review ./sbx-kit

Copy-Item -Recurse $HOME/workshop/kits/docker-review ./sbx-kit

cp ~/workshop/docker-agent/team.yaml ./

Copy-Item $HOME/workshop/docker-agent/team.yaml ./

cat > MANIFEST.md <<'EOF'
# Governance package

- sbom-dhi-python.json - SBOM for the DHI base image
- provenance-dhi-python.json - SLSA provenance attestation for the DHI base
- policy-config.txt - sbx network policy in effect
- audit-log.txt - full outbound-request log
- mcp-registrations.txt - MCP servers registered with sbx
- sbx-kit/ - portable governance policy (network + MCPs + skills)
- team.yaml - Docker Agent per-role capability declaration

Generated by LP2 workshop assembly on the local host.
EOF

@'
# Governance package

- sbom-dhi-python.json - SBOM for the DHI base image
- provenance-dhi-python.json - SLSA provenance attestation for the DHI base
- policy-config.txt - sbx network policy in effect
- audit-log.txt - full outbound-request log
- mcp-registrations.txt - MCP servers registered with sbx
- sbx-kit/ - portable governance policy (network + MCPs + skills)
- team.yaml - Docker Agent per-role capability declaration

Generated by LP2 workshop assembly on the local host.
'@ | Set-Content MANIFEST.md

ls -la ~/workshop/governance-package/

Get-ChildItem $HOME/workshop/governance-package/

The artifacts your compliance team can hand to auditors.

Recap the three governance questions from the top:

• What does the agent ship? A DHI base image with a CVE quickview attached. Verified in the Foundational module.
• What can the agent see? A sandbox VM with an explicit network policy. Every outbound request is in the policy log. That is your audit trail.
• What can the agent do? Two MCP servers registered by name (Wikipedia and DuckDuckGo), attached to the sandbox at create time via --static-mcp. The Docker MCP Gateway sits behind it as the team-scale primitive for scoping tools per client. In Step 7 the Docker Agent yaml declares per-role tools; the yaml itself reads as an auditable compliance artifact.

The concrete artifacts you now have on disk

• The DHI CVE quickview output from the Foundational module: proof that the base image your builds run on has near-zero known CVEs.
• The sbx policy log output from Steps 3 and 5: a complete audit trail of every outbound request your sandboxed agent made. Sliceable by rule, domain, and time. This is the report an auditor asks for.
• The docker-review sbx kit in ~/workshop/kits/docker-review/: a portable governance profile (network rules + allowed MCPs + skill set) you can commit to your team's repo. One artifact, one commit, whole-team enforcement.
• The Docker Agent team.yaml in ~/workshop/docker-agent/: a per-role compliance artifact. Your security team can read it and know exactly what capabilities each role of the team has. The runtime enforces the boundary declared there.

What to hand off, and to whom

Different governance stakeholders in your org want different artifacts:

• Supply-chain / AppSec reviewer: the DHI CVE quickview output and the base image name.
• Governance / audit officer: the sbx policy log export, plus the docker-review kit as the "here's how our team runs sandboxed agents" reference.
• Security engineering / platform team: the Docker Agent team.yaml, plus the kit. Both are the ongoing configuration; both are what changes when the team adjusts what agents can do.

Where LP2 sits in your governance journey

You've now walked through Docker's stack from the base image up to a scoped multi-agent team. Each layer answers a governance question, and each ends in an artifact. Where you go from here depends on your org's shape:

• If your team wants the developer intro to sbx before the governance framing, point them at LP1: SBX 101. Same primitives, developer-friendly narrative.
• If you want to go deeper on any single layer: supply chain (SBOMs, provenance attestations, dhictl, Docker Scout policies), MCP Gateway at scale (multi-client fan-out, portable profiles, Docker AI Governance control plane), the four-pillar ecosystem view, per-team Gateway scoping, fully-local agent teams, or full governance-package assembly. Flip open the Go Deeper section above. Each module there is self-contained; do one, do all, or skip the section entirely.

You've got the primitives, you've got the artifacts. What's left is applying them to your team's specific stack.

When you're done with the workshop and want your machine roughly back to the state it was in before you started, run the commands below in order.

This is a soft reset: it removes what the workshop created but does NOT uninstall sbx, Docker Desktop, or Docker Agent, in case you have other projects using them.

1. Stop and remove the workshop sandboxes

Each of these commands stops the sandbox's microVM and then deletes the sandbox record. sbx will ask you to confirm each removal; type y at the prompt. Sandboxes not present on your machine will silently no-op. This does not touch other sandboxes you may have created outside the workshop.

for name in sandbox-alpha sandbox-bravo sandbox-charlie sandbox-kits; do sbx stop "$name" 2>/dev/null; sbx rm "$name"; done

2. Remove the workshop MCP registrations

These are the two MCP server registrations you added in Step 4 (Wikipedia and DuckDuckGo). Removing them clears them from sbx mcp ls. The underlying MCP container images are removed in a later step.

sbx mcp rm wiki-mcp; sbx mcp rm duck-mcp

3. Remove the custom network policy rules

Step 3 added a deny rule for pypi.org (later removed in the Step 5 prep) and an allow rule for fifa.com. This command removes them if they're still present. Anything else in your policy list stays in place.

sbx policy rm network --resource pypi.org; sbx policy rm network --resource fifa.com

4. Log out of Docker Hub and dhi.io

Two logins were performed during setup: one for Docker Hub (used for MCP images and Docker Scout) and one for the DHI registry (used in Step 5 for hardened base images). This clears both credential entries from your local Docker config.

docker logout; docker logout dhi.io

5. Remove the workshop Docker images

This removes the two images the agent built (research-app:v1 with the standard base and research-app:v2 with the DHI base) and the three MCP-server images that were pulled at setup or pre-pull time. The -f flag forces the removal even if the image is still referenced by a stopped container.

docker rmi -f research-app:v1 research-app:v2 mcp/wikipedia-mcp mcp/duckduckgo mcp/paper-search

6. Remove the local Docker Model Runner model

ai/smollm2 is the small local model Docker Model Runner pulled for the Step 7 team (the writer role). This deletes the model file from local storage and reclaims the disk space.

docker model rm ai/smollm2

7. Delete the workshop project folders

These are the three subdirectories the workshop created inside ~/workshop: the research-app from Step 5 (with the agent's Dockerfile and app.py), the kits directory from Step 6 (the docker-review sbx kit), and the docker-agent directory from Step 7 (the team yaml and any reports the team wrote). The umbrella ~/workshop folder itself is left in place in case you want to keep it around.

rm -rf ~/workshop/sbx/research-app ~/workshop/kits ~/workshop/docker-agent

Remove-Item -Recurse -Force $HOME/workshop/sbx/research-app, $HOME/workshop/kits, $HOME/workshop/docker-agent

Heads up This soft reset intentionally leaves sbx, Docker Desktop, and Docker Agent installed, and does not touch your stored API-key secrets or your other sandboxes. For a full uninstall you'd need to also brew uninstall docker/tap/sbx, uninstall Docker Desktop, and clear the OS keychain entries yourself; the workshop deliberately doesn't script that side since it varies by how your machine was set up.