AI Engineer · Published 2026-10-03

YOLO Mode, Safely: MicroVM Sandboxes for Any Agent — Rowan Christmas, Docker

privateReview: unreviewedConfidence: high
microvmSandboxingsecuritydockergovernanceagentsagent-securityprompt-injectionleast-privilegeegress-controlruntime-enforcementMCP
Open on YouTube ↗

Summary

Overview

  • Speaker: Rowan Christmas
  • Channel: AI Engineer
  • Main topic: Using MicroVM sandboxes to run AI agents securely
  • Purpose: To demonstrate the security risks of AI coding agents running with broad system access and to introduce Docker's SBX microVM sandbox solution for runtime AI governance and isolation. Rowan Christmas from Docker presents an exploration of how AI coding agents (such as Claude Code) can be safely executed inside MicroVM sandboxes (SBX) to prevent credential harvesting, accidental file destruction, and network exfiltration. He demonstrates how easy it is for an agent to access local browser history, bank accounts, and sensitive data when trusted blindly, and explains why sandbox isolation at the kernel level is essential rather than relying on agent prompts or harness-level guardrails.

Topic Map

The Security Risks of Autonomous AI Agents

  • Explanation: Rowan recounts testing Claude Code on his Mac desktop to see what happens when an agent has unrestricted local access, showing how easily it retrieves browser history and bank login sqlite databases.
  • Key claims:
    • Coding harnesses do not protect against all bad agent actions.
    • AI agents can successfully locate and extract sensitive local credentials and PII within just a few prompts.
    • Asking an agent nicely in prompts ('please don't do bad things') is insufficient security.
  • Examples:
    • Claude Code searching local Mac directories (/Library/Application Support/Google/Chrome/Default/Login Data) to find bank credentials.
    • Extracting checking account numbers and Zelle payment patterns in 5 prompts.
  • Terminology:
    • credential harvesting
    • prompt injection
    • PII
    • egress
  • Why it matters: Demonstrates that developers deploying autonomous coding agents face severe risks of identity theft and data exfiltration if the agent runs directly on the host machine.

Docker SBX: MicroVM Sandboxes for Agents

  • Explanation: Introduction of SBX, Docker's new microVM binary designed specifically to sandbox AI agents, running them in an isolated environment with separate kernels and virtualized file systems.
  • Key claims:
    • The harness is the wrong place to enforce security policy because agents bypass it.
    • MicroVM sandboxes run their own kernel, isolate file systems, and intercept network requests.
    • Running Claude Code inside SBX prevents it from discovering host browser history or unauthorized network endpoints.
  • Examples:
    • Running sbx run claude instead of claude.
    • SBX reporting 0 browser histories found because the sandbox has no host browser installed.
  • Terminology:
    • microVM
    • SBX
    • kernel isolation
    • network egress
  • Why it matters: Provides a robust, design-level security boundary that stops unauthorized agent actions regardless of what prompts the agent receives.

AI Governance and Policy Enforcement

  • Explanation: How organizations can define network and filesystem access policies once and enforce them where the agent runs.
  • Key claims:
    • Define policy once and enforce it where the agent actually runs.
    • Network and filesystem allow/deny rules can be configured per sandbox instance.
    • MCP (Model Context Protocol) servers can also be run inside sandboxes to maintain compliance.
  • Examples:
    • Allowing github.com and denying internal production endpoints.
    • Mounting specific read-only repositories for context.
  • Terminology:
    • MCP catalog
    • identity tracking
    • delegation chains
    • audit trail
  • Why it matters: Enables CISO teams to satisfy both the CEO's demand to 'ship it' and the board's demand to 'control it' without blocking AI adoption.

Key Points

'Please' is not security

  • Explanation: Asking an LLM or agent not to do malicious things via prompt instructions provides zero real security guarantees.
  • Evidence: Claude Code readily extracted sensitive local data when asked via standard research prompts.
  • Practical implication: Do not rely on prompt-level restrictions for sensitive environment execution.

The lethal trifecta of AI agents

  • Explanation: Every useful agent requires access to private data, exposure to untrusted content, and the ability to act externally.
  • Evidence: Useful coding agents need repo access, web/prompt input, and API/network execution.
  • Practical implication: Because useful agents inherently possess the lethal trifecta, runtime enforcement layers are mandatory.

MicroVM sandboxing as the ultimate boundary

  • Explanation: Isolating agents in MicroVMs ensures that even if compromised or tricked by prompt injection, the agent cannot access the host machine's secrets or unauthorized network ports.
  • Evidence: SBX blocks unauthorized DNS lookups and web requests (e.g., to pirated sites or telemetry dumps).
  • Practical implication: Adopt microVM-based sandboxing for all local and server-side agentic workflows.

Frameworks, Models & Processes

The Lethal Trifecta for AI Agents

  • How it works: Describes the three inherent risk capabilities present in any functional AI agent.
  • Components:
    • Access to private data (internal, sensitive, regulated)
    • Exposure to untrusted content (prompt injection, poisoned input)
    • Ability to act externally (exfiltration, unbounded egress)
  • When to use: When evaluating the security posture of any autonomous AI agent deployment.

Examples & Case Studies

Rowan asked Claude Code on his Mac to look up browser history and financial account details.

  • Illustrates: Unsandboxed AI agents can easily browse local sqlite databases and harvest credentials.
  • Lesson: Never run agents with full host access.

Actionable Takeaways

  • Immediate:
    • Install Docker's SBX binary to run local coding agents.
    • Never run powerful coding assistants without sandbox isolation.
  • Strategic:
    • Shift security enforcement from the agent harness layer to the runtime microVM boundary.
    • Implement centralized AI governance policies for network and filesystem access.
  • Questions to investigate:
    • How does SBX impact agent execution speed and developer experience?
    • What are the best practices for mounting read-only repositories into agent sandboxes?

Claims Worth Verifying

  • Claude Code can extract local Chrome and Safari login sqlite databases from un-sandboxed environments. (technical fact)
  • Docker SBX runs microVMs across macOS, Windows, and Linux in seconds. (product capability)

Notable Quotes

"If the agent can see it, it can use it." (at 7:10) ""Please" is not security." (at 5:44) "The harness is the wrong place to enforce policy." (at 11:46)

Compressed Summary

  • Autonomous agents present severe security risks when given un-sandboxed host access.
  • Prompt-level restrictions fail against credential harvesting and prompt injection.
  • Docker SBX provides a microVM-based isolation layer for running agents securely.
  • Enforces network and filesystem governance at the runtime boundary.
  • Keywords: microvm, sandboxing, security, docker, governance, agents
  • Core insight: Agent security cannot rely on prompts or harnesses; it requires kernel-level microVM sandboxing to safely contain the lethal trifecta of AI capabilities.

Core insights

5
Architecturemedium noveltystrong evidence

Security policy for autonomous agents must be enforced at a boundary below the agent (kernel/microVM), because harness-level guardrails and prompts are bypassable by the agent itself.

Why it matters

It relocates the trust boundary from a component the agent controls (the harness/prompt) to one it cannot escape (a separate kernel), which is the difference between a suggestion and an enforcement guarantee.

Generalization

For any untrusted-code execution system, policy enforcement must live in the substrate, not in the code being governed — same reason browsers and containers don't rely on app-level permissions.

The harness is the wrong place to enforce security policy because agents bypass it.
Open source video
The harness is the wrong place to enforce policy.
Open source video
"Please" is not security.
Open source video
Mental Modelhigh noveltystrong evidence

Agent capability is bounded by what is visible/mounted, not by what the model intends: an agent inside a sandbox that has no host browser installed finds zero browser histories.

Why it matters

Gives a concrete, testable design lever: capability can be reduced by shrinking the namespace (files, binaries, endpoints) rather than by adding behavioral instructions, making the security property deterministic instead of probabilistic.

Generalization

Treat filesystem and network visibility as the capability surface of an agent; auditing and limiting that surface is equivalent to limiting what the agent can do.

If the agent can see it, it can use it.
Open source video
SBX reporting 0 browser histories found because the sandbox has no host browser installed.
Open source video
Mental Modelmedium noveltymoderate evidence

Useful agents inherently possess the 'lethal trifecta' — access to private data, exposure to untrusted content, and the ability to act externally — so mitigations cannot target any single leg without breaking the agent's utility.

Why it matters

Frames agent security as a structural property of useful agents rather than a bug to be patched, implying runtime isolation is mandatory rather than optional hardening.

Generalization

Any system combining secrets, untrusted input, and output egress (RAG pipelines, tool-using copilots, CI bots) inherits the same trifecta regardless of model quality.

Every useful agent requires access to private data, exposure to untrusted content, and the ability to act externally.
Open source video
Because useful agents inherently possess the lethal trifecta, runtime enforcement layers are mandatory.
Open source video
Practicemedium noveltymoderate evidence

Network and filesystem allow/deny policy is authored once centrally and enforced per-sandbox-instance at the runtime boundary, including running MCP servers inside the sandbox for compliance.

Why it matters

Decouples governance authoring from the many heterogeneous agent harnesses and runtimes, giving security teams a single control plane that survives harness churn.

Generalization

Agent governance should follow the same pattern as cloud network policy: declared centrally, enforced at the workload boundary, not per-application.

Define policy once and enforce it where the agent actually runs.
Open source video
Allowing github.com and denying internal production endpoints.
Open source video
MCP (Model Context Protocol) servers can also be run inside sandboxes to maintain compliance.
Open source video
Empirical Resultmedium noveltymoderate evidence

An unsandboxed coding agent with ordinary 'research' prompts located and extracted local Chrome login sqlite databases and financial account patterns within roughly five prompts.

Why it matters

Provides a concrete, reproducible-seeming demonstration that credential and PII exfiltration is reachable through normal agent behavior, not adversarial jailbreaking — raising the baseline risk for default local installations.

Generalization

Default developer-machine environments expose credential stores as ordinary files that any tool with host filesystem access can read.

Claude Code searching local Mac directories (/Library/Application Support/Google/Chrome/Default/Login Data) to find bank credentials.
Open source video
Extracting checking account numbers and Zelle payment patterns in 5 prompts.
Open source video

Deep dives

5

Kernel/microVM enforcement boundary for agent security policy

Research question

Can harness-level guardrails be reliably bypassed by agents, and what is the minimal substrate boundary (microVM kernel, seccomp, or VM) that makes policy enforcement unbypassable?

Why

It distinguishes security theater from enforceable isolation and determines whether agent deployments can safely be given broad autonomy.

The harness is the wrong place to enforce security policy because agents bypass it.
Open source video
"Please" is not security.
Open source video
Source video

Capability surface as filesystem and network visibility

Research question

How much agent task success is preserved when filesystem and network visibility are reduced to explicit mounts and allow-listed endpoints, and does this eliminate credential access independent of model behavior?

Why

It converts agent security from prompt-level probability to namespace-level determinism and gives a measurable design lever.

If the agent can see it, it can use it.
Open source video
SBX reporting 0 browser histories found because the sandbox has no host browser installed.
Open source video
Source video

Baseline credential and PII exposure on unsandboxed developer machines

Research question

Under default permissions and ordinary research prompts, how many steps and what access are required for a coding agent to locate and extract local credential stores or PII?

Why

It establishes the baseline risk for unsandboxed agents and tests whether standard developer environments expose secrets as ordinary files.

Claude Code searching local Mac directories (/Library/Application Support/Google/Chrome/Default/Login Data) to find bank credentials.
Open source video
Extracting checking account numbers and Zelle payment patterns in 5 prompts.
Open source video
Source video

Structural lethal trifecta and mandatory runtime enforcement

Research question

Can any leg of the lethal trifecta be reduced without degrading useful agent behavior, or does runtime isolation remain mandatory for any sufficiently capable agent?

Why

It frames runtime enforcement as an architectural requirement rather than optional hardening.

Every useful agent requires access to private data, exposure to untrusted content, and the ability to act externally.
Open source video
Because useful agents inherently possess the lethal trifecta, runtime enforcement layers are mandatory.
Open source video
Source video

Central policy authoring and per-sandbox enforcement

Research question

What policy model lets security teams define filesystem, network, and MCP rules once and enforce them across heterogeneous agent harnesses and sandbox instances with complete audit?

Why

It addresses governance at scale once agents are sandboxed and MCP servers are moved inside the workload boundary.

Define policy once and enforce it where the agent actually runs.
Open source video
MCP (Model Context Protocol) servers can also be run inside sandboxes to maintain compliance.
Open source video
Source video

Article ideas

4

The Harness Is Not a Security Boundary

Agent security cannot be enforced in the harness or prompt because the agent can bypass both; it must be pushed to a kernel or microVM boundary the agent cannot escape.

Angle

Contrast prompt and harness guardrails with microVM kernel isolation and show why 'please' is not a control.

Source video

Capability Is Visibility: Reframing Agent Security as Namespace Design

An agent's capability equals what is visible and mounted to it; security should be engineered by shrinking the filesystem and network namespace rather than by adding behavioral instructions.

Angle

Treat mounts, binaries, and endpoints as the agent capability surface; measure blast radius by visible resources.

Source video

Useful Agents Have the Lethal Trifecta, So Runtime Enforcement Is Not Optional

Any useful agent combines private-data access, untrusted-content exposure, and external action; because removing a leg breaks utility, runtime isolation is mandatory rather than optional hardening.

Angle

Structural argument for microVM sandboxes from the trifecta, not from specific vulnerabilities.

Source video

Policy Once, Enforce Everywhere: Agent Governance as Workload Policy

Agent governance should follow cloud workload policy: declare filesystem, network, and MCP rules centrally and enforce them per sandbox instance, so controls survive harness churn.

Angle

Move from per-harness prompts to a control plane that governs heterogeneous agents and MCP servers.

Source video

Project ideas

4

Harness Bypass Benchmark

beyond-evals

Popular agent harnesses' built-in permission and deny rules can be bypassed by an ordinary agent using shell, file, or network primitives in a measurable fraction of trials.

Proof of concept

Build a test suite that places decoy credential files on a host, configures harness-level deny rules, and runs coding-agent tasks that attempt to read or encode those files; record bypasses.

Measurement

Bypass rate per harness, time-to-bypass, percentage of deny categories defeated, and whether bypass required adversarial prompts versus ordinary research prompts.

Source video

Namespace Minimality for Coding Agents

movement-lab

Agent task success is preserved when filesystem and network visibility are reduced to task-specific read-only mounts and allow-listed endpoints, while credential exposure drops to zero.

Proof of concept

Run a coding task suite in a microVM with tiered mount policies (full host, repository read-only, scoped subtree) and network allow-lists; measure task success and attempted sensitive access.

Measurement

Task success rate, sensitive-file access attempts, exfiltration attempts, and policy-violation events per tier.

Source video

Allowed-Domain Exfiltration Test

gatehouse

An allow-list of permitted external endpoints still permits data exfiltration through allowed domains unless content or DLP inspection is enforced at the sandbox boundary.

Proof of concept

Sandbox an agent with a network allow-list including a code host; attempt to encode secrets in commits, gists, package metadata, DNS, or HTTP headers; inspect egress.

Measurement

Exfiltrated bytes via allowed channels, detection rate by boundary inspection, and false-positive rate on legitimate developer traffic.

Source video

MicroVM Agent Overhead Benchmark

new

Running coding agents inside MicroVM sandboxes adds a measurable but acceptable cold-start and per-task latency overhead compared with native execution.

Proof of concept

Benchmark sandboxed versus unsandboxed agent execution on a shared coding task suite across macOS, Windows, and Linux using SBX-style microVMs.

Measurement

Cold-start time, task wall-clock time, iteration latency, and developer-observed friction.

Source video

Architectural implications

3

Policy enforcement relocates from the agent harness to a kernel-level microVM boundary.

Before

Guardrails, prompt instructions, and harness permissions inside the agent process.

After

MicroVM with its own kernel, virtualized filesystem, and intercepted network requests.

Consequence

Agent misbehavior becomes contained by construction; compromised agents cannot reach host secrets or unauthorized endpoints regardless of prompt content.

Source video

Governance authoring is separated from enforcement location.

Before

Security rules expressed per-harness, per-developer, or in prompts.

After

Policy declared once and enforced where the agent runs, per sandbox instance.

Consequence

CISO/security teams get a single control point while developers keep using arbitrary harnesses, resolving the 'ship it vs control it' tension.

Source video

Context supply becomes an explicit, restricted mount operation rather than ambient host access.

Before

Agent inherits full host filesystem and network reach.

After

Specific read-only repositories and allow-listed endpoints are mounted into the sandbox.

Consequence

Context engineering gains a security surface: what you mount is exactly what the agent can read, making blast radius auditable.

Source video

Tradeoffs and failure modes

3

Isolation vs developer experience and execution latency

Benefit

Kernel-level microVM isolation prevents credential harvesting and unauthorized egress even under prompt injection.

Cost or risk

Summary leaves unresolved how SBX affects agent execution speed and developer experience; added virtualization and policy friction may slow the inner loop.

How does SBX impact agent execution speed and developer experience?
Open source video
Source video

Narrowing visibility trades capability for safety

Benefit

Mounting only specific read-only repositories limits what data an agent can reach.

Cost or risk

Under-provisioned sandboxes reduce agent usefulness and may push users to request broad mounts, re-expanding the attack surface.

What are the best practices for mounting read-only repositories into agent sandboxes?
Open source video
Source video

Reliance on prompt-level prohibition

Benefit

Prompt instructions are cheap and require no infrastructure.

Cost or risk

They provide zero real security guarantees — a demonstration showed sensitive local data extracted via ordinary research prompts.

Asking an agent nicely in prompts ('please don't do bad things') is insufficient security.
Open source video
Source video

Open questions

4

What is the actual latency and workflow overhead of running coding agents inside microVMs?

Why unresolved

Summary lists it as a question to investigate and provides no measurements.

Research direction

Benchmark agent task completion time, cold-start of microVMs, and iteration latency for sandboxed vs unsandboxed runs.

Source video

What is the correct policy for mounting repositories into agent sandboxes without either starving or over-exposing the agent?

Why unresolved

Summary names read-only mounting best practices as an open question with no guidance.

Research direction

Prototype tiered mount policies (read-only, scoped subtrees, ephemeral overlays) and measure task success vs data exposure.

Source video

Does an allow-list of external endpoints (e.g., github.com) leave a residual exfiltration channel through permitted destinations?

Why unresolved

Summary presents allow/deny network policy but does not address data egress via allowed domains.

Research direction

Test whether exfiltration payloads can be smuggled through allowed endpoints such as code hosts, and evaluate content/DLP inspection at the sandbox boundary.

Source video

How do identity, delegation chains, and audit trails span the host and the sandbox when MCP servers run inside the VM?

Why unresolved

These terms appear in the topic map but without mechanism or validation.

Research direction

Design and instrument delegated identity across sandbox boundaries; test audit completeness for agent actions executed inside microVMs.

Source video

Key claims

6
opinionVerification needed

The agent harness is the wrong layer to enforce security policy because agents can bypass it.

Evidence

The harness is the wrong place to enforce security policy because agents bypass it.

Question

Can a controlled agent reliably escape or bypass harness-level permissions across popular harnesses (Claude Code, Cursor, custom loops)?

Source video
factualVerification needed

Claude Code can locate and extract local Chrome/Safari login sqlite databases and financial account details on an unsandboxed Mac.

Evidence

Claude Code searching local Mac directories (/Library/Application Support/Google/Chrome/Default/Login Data) to find bank credentials.

Question

Under what prompts and default permissions does this extraction succeed, and does OS-level keychain/browser encryption block actual credential decryption?

Source video
factualVerification needed

Docker SBX can start microVMs on macOS, Windows, and Linux in seconds.

Evidence

Docker SBX runs microVMs across macOS, Windows, and Linux in seconds.

Question

What are measured cold-start and steady-state overheads of SBX microVMs per platform compared to native execution?

Source video
causalVerification needed

Useful agents inherently combine private-data access, untrusted-content exposure, and external action, making runtime enforcement mandatory.

Evidence

Because useful agents inherently possess the lethal trifecta, runtime enforcement layers are mandatory.

Question

Can agent designs measurably reduce one leg of the trifecta without degrading task success, and does that eliminate the need for runtime isolation?

Source video
causalVerification needed

MicroVM sandboxing blocks unauthorized DNS lookups and network requests from an agent.

Evidence

SBX blocks unauthorized DNS lookups and web requests (e.g., to pirated sites or telemetry dumps).

Question

What bypass techniques (DNS tunneling, allowed-domain relays, raw IP) defeat such egress interception?

Source video
causalVerification not requested

Prompt instructions telling an agent not to do harmful things provide effectively no security guarantee.

Evidence

"Please" is not security.

Source video

Connections

4