Compositions, not silver bullets

Build the boundary to fit the risk.

All four stacks assume an untrusted agent can make mistakes, follow malicious instructions, and try whatever its granted tools permit. The goal is bounded authority and a recovery path.

01 · everyday local work

Rootless container + controlled workspace

For a supervised coding agent working on a project you know.

Host / WSL2 VMrootless Podmanproject worktreecoding agent

Why: fast iteration, familiar images, reasonably contained accidental writes, and a natural audit point at the worktree/diff. Rootless mappings reduce host privilege compared with a rootful path.

  • Mount only the one project directory; prefer a fresh worktree or exported copy.
  • Do not mount Docker/Podman sockets, your home directory, SSH agent, cloud config or browser profile.
  • Default egress off or allowlist what the task needs; do not use host networking for convenience.
  • Use a non-secret build identity. Export patches or review diffs before applying changes.

02 · autonomous or strange work

Disposable VM + inner workload boundary

For unknown repos, web-downloaded code, or agents that need broad shell freedom.

Hostdisposable VM / microVMrootless container or bwrapagent

Why: the guest kernel creates a more distinct boundary than an ordinary host container. The inner layer narrows the agent’s workspace and makes resetting/replaying more manageable. The operational cost is guest images, virtual networking, storage, updates and snapshots.

  • Start from a known base and reset or discard it after the task. Do not rely on “cleanup later.”
  • Keep host folders unshared by default; pass in a deliberate project copy or an artifact channel.
  • Expose only needed devices. GPU, USB, clipboard, audio and shared folders expand authority.
  • Give the VM its own network policy; snapshots can duplicate identity and connection state.

03 · useful, credentialed agents

Sandbox + brokered capability

For letting an agent use an API without letting it read the credential.

agent sees placeholderegress policycredential brokerallowlisted API

Why: a request proxy or command broker can resolve the secret out of process and inject it only into an approved action. It lowers the risk of the agent printing, logging or uploading the raw key. It does not replace sandboxing: an agent that can bypass the proxy, read the vault, or call a broad broker action has a path around the design.

  • Give the agent fake/placeholder values, never a raw long-lived credential.
  • Force outbound traffic through the broker or firewall; block direct internet routes.
  • Allowlist host, method, path, destination account and ideally action semantics—not only a domain.
  • Use short-lived / scoped credentials, audit the broker, and ensure its errors cannot echo secrets.

04 · browser and GUI agents

Dedicated desktop guest + visible controls

For an agent that has to click, type and observe a graphical operating system.

HostVM / remote desktop guestbrowser + appscomputer-use agent

Why: computer-use needs a real graphical environment, and browser sessions are powerful identity containers. A separate guest can keep its browser profile, downloads, clipboard and app logins distinct. CUA-like automation is the driver; the guest and its policies are the boundary.

  • Use a new browser profile and test accounts; never inherit your primary logged-in profile.
  • Turn off shared clipboard, folders, drives and device passthrough unless explicitly required.
  • Record or review high-impact steps, and define a hard reset/reimage flow.
  • Keep the agent’s UI control separate from any host administration surface.

The durable principle

Each layer needs a job. If two layers have the same vague job, one is probably security theatre.

Write down the authority each layer grants: filesystem paths, processes, devices, network destinations, identities, credentials and ways back to the host.

Explore the components →