Stephan Schmidt - February 9, 2026

Isolating AI Agents

Section 1: Opening – The Problem

• Personal hook: I use Claude Code daily. It runs as me. I run it in WSL, but it might break out and access to much data, secrets, and more.
• Most CTOs I coach haven’t thought about this
• We hand agents the same access as a senior developer
• Bold statement: The agent has more access than most new hires get on day one
• Connection to /trusting-ai/ – I ship code AI writes without reviewing it. Now think about what else it could do with my permissions.

Section 2: The Spectrum – Light to Heavy

• Frame: not one solution, a spectrum from low friction to maximum isolation
• Quick overview sentence, then walk through each

Section 3: Docker / DevContainers

• Most accessible option
• Claude Code’s own docs recommend DevContainers
• Familiar, works with existing tooling
• But: shared kernel, container escapes exist
• But: most devs mount home directory into container – defeats the point
• You need to create and maintain your own Docker Container with tools etc. for Claude (ripgrep, jq)
• Starting point, not destination
• Good for: teams that want some isolation without changing workflow
• Downside: no easy way to manage/allow urls / network

Section 4: WSL + Bubblewrap – What I Actually Use

• Personal experience section
• WSL on Windows: better integrated than Docker on Windows, Linux filesystem separate from Windows credentials
• WSL alone not enough – designed for convenience, not containment
• Bubblewrap on top: unprivileged Linux sandboxing, same namespaces containers use, no Docker needed
• No root required
• Selectively expose only project directory read-write, everything else invisible
• Two layers: WSL separates from Windows host, Bubblewrap constrains within Linux
• Downside: requires Linux knowledge, most devs won’t set this up without guidance
• Downside: difficult to get read/write directories right
• Downside: no easy way to manage/allow urls / network

Section 5: Firecracker – The Heavy End

• AWS built for Lambda and Fargate
• MicroVMs, 125ms boot, under 5MB memory overhead
• Genuine hardware-level isolation – own kernel, no shared kernel to escape from
• 125ms changes the “VMs are too slow” argument
• Trade-off: operational complexity, KVM, VM images, networking
• For platforms running agents on behalf of others (Devin, E2B): right answer
• For most CTOs running agents locally: overkill, hard to setup, only a building block
• Difficult to manage network access etc.

Section 6: Matchlock – The Clever Bit

• Most interesting approach in this space
• The problem with all other approaches: you still pass API tokens into the sandbox
• Compromised agent or prompt injection can exfiltrate credentials
• Matchlock’s approach: MITM proxy intercepts agent’s API calls, injects auth headers at network layer
• Agent makes request, proxy adds token. Agent never sees the actual secret.
• Plus: network allowlisting (deny-by-default), copy-on-write filesystem that vanishes after execution
• Same principle as hardware security modules – key never leaves the HSM
• The best secret is one the agent never has.

Section 7: Secrets

• Inject secrets e.g. with 1Password
• Fly.io tokenization

Section 8: What This Means for CTOs

• Short, practical
• Key question: which agents touch production, customer data, or credentials? Those need isolation. Agent writing unit tests in a side project does not.
• Quick spectrum recap (2-3 lines, not a big list)
• Agent isolation is where container orchestration was in 2014. Tooling will get better. Right now it requires effort.

Cross-links to weave in

• /trusting-ai/ – trusting AI with code, now think about trusting it with credentials
• /where-ai-struggle-doom-loops/ – CLAUDE.md and agent management
• /audience-of-one-apps/ – building your own tools, which means more agents running locally