From ee04e3d17f53db248eecfeb3306f0ebf6e2e3f8f Mon Sep 17 00:00:00 2001 From: rkoster Date: Sat, 19 Sep 2026 18:31:49 +0200 Subject: [PATCH 1/2] docs: add Docker Sandboxes research note --- research/docker-sandboxes.md | 94 ++++++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 research/docker-sandboxes.md diff --git a/research/docker-sandboxes.md b/research/docker-sandboxes.md new file mode 100644 index 0000000..223f82e --- /dev/null +++ b/research/docker-sandboxes.md @@ -0,0 +1,94 @@ +--- +title: "Docker Sandboxes: Local MicroVMs for Coding Agents" +author: Ruben Koster (@rkoster) +date: 2026-09-19 +tags: [sandboxing-isolation, runtime-lifecycle, identity, ecosystem-survey] +cf_areas: [diego, capi, uaa, loggregator] +status: draft +ratings: + platform-impact: + value: 68 + note: "Docker Sandboxes demonstrates strong isolation and policy boundaries for coding agents, but its documented execution model is developer-local rather than a shared Cloud Foundry service." + maturity: + value: 72 + note: "Docker documents a dedicated CLI, microVM architecture, workspace modes, network policy, credential handling, and optional organization governance." + novelty: + value: 55 + note: "MicroVM isolation and nested Docker are established patterns; the product packages them around coding-agent workflows, local workspaces, and policy enforcement." + actionability: + value: 48 + note: "The documented local-first CLI is useful prior art, but it does not establish a remotely consumable lifecycle-and-execution API for multi-tenant CF workloads." +sources: + - https://www.docker.com/products/docker-sandboxes/ + - https://docs.docker.com/ai/sandboxes/ + - https://docs.docker.com/ai/sandboxes/architecture/ + - https://github.com/opensandbox-group/OpenSandbox +--- + +## Summary + +Docker Sandboxes is local-first developer tooling: the `sbx` CLI runs a supported coding-agent +harness inside a dedicated microVM on the developer's machine. It is more than putting a harness +in a container because each sandbox owns a Docker daemon, filesystem, and network, but Docker's +sandbox and execute all actions in it. OpenSandbox is the closer prior-art match for that latter +model because it publishes lifecycle, command-execution, and file-operation APIs through SDKs and +MCP, with Docker and Kubernetes runtimes. + +## Key findings + +- **`sbx` starts the agent locally.** `sbx run ` creates a sandbox and launches a + supported coding agent in it. The documented workflow begins in a local project directory and + is designed to give that local agent unattended execution without modifying the host directly. +- **The isolation boundary is a microVM, not just a container.** Each sandbox has its own + filesystem, network, and Docker daemon, so an agent can install packages and build or run + containers without receiving the host Docker daemon or host filesystem by default. Docker + explicitly contrasts this with a container that mounts the host socket or privileged + Docker-in-Docker. +- **Workspace choice controls where changes land.** A directly mounted workspace exposes the + developer's project through a filesystem passthrough; mountless sandboxes retain files inside + the sandbox; and clone mode mounts the host source read-only while the agent works in a private + clone. These are local development and review choices, not a remote artifact API. +- **Network and credentials are mediated by host-side components.** All outbound TCP traffic is + routed through a proxy on the host. The HTTP/HTTPS path can enforce network policy and inject + credentials, avoiding a need to expose real credentials directly to the agent process. +- **MCP policy also stays on the host side.** The MCP gateway brokers access to registered MCP + servers and applies MCP policy before tool, resource, prompt, or gateway meta-tool operations. + A registered server may itself be remote, but that does not make the sandbox lifecycle or shell + execution remote. +- **Central governance distributes policy, not a shared sandbox service.** Docker documents + optional paid organization governance for centrally managed network, filesystem, and MCP + policies across developer machines. The published model remains a local `sbx` environment; + it does not document a platform endpoint that another agent harness can use for sandbox create, + exec, inspect, file, and destroy operations. +- **OpenSandbox represents a different boundary.** OpenSandbox publishes sandbox lifecycle and + execution APIs, language SDKs, a CLI, and an MCP server for sandbox creation, command execution, + and file operations. Its Docker and Kubernetes runtimes, ingress and egress controls, and + credential vault make it closer to a remotely programmable sandbox substrate than Docker + Sandboxes' local agent environment. + +## CF relevance + +Docker Sandboxes offers useful prior art for a Cloud Foundry agent-sandbox design: a hard +execution boundary, a separate Docker daemon, workspace isolation modes, mediated egress, proxy +credential injection, and policy enforcement at MCP boundaries. Those capabilities could inform a +CF service that protects the platform host and makes sandbox activity observable through platform +logging and audit facilities. + +It does not, based on its published documentation, provide the remote execution control plane a +Cloud Foundry platform integration needs. An `execd`-style substrate must let a separate agent +harness create a sandbox, execute commands, transfer or inspect files, observe lifecycle state, +and destroy the sandbox through an authenticated API. It also needs platform tenancy, lifecycle, +quota, route, identity, and audit integration. OpenSandbox's published lifecycle and execution +APIs are closer prior art for this remote boundary, while Docker Sandboxes is stronger evidence +for the local developer experience and isolation model. + +## Open questions + +- Will Docker expose a remotely consumable lifecycle and execution API, or remain focused on + developer-local `sbx` workflows? +- Can the microVM, egress proxy, credential injection, and MCP gateway operate independently of + Docker Desktop and a developer workstation? +- Does organization governance emit auditable policy and execution events that an external + platform control plane could consume? +- Which workspace model would be appropriate for a CF-hosted agent that must retain work without + exposing application source or artifacts across tenant boundaries? From 8634ac2f43475d297d7ba25998c5d07ba20b9647 Mon Sep 17 00:00:00 2001 From: rkoster Date: Sat, 19 Sep 2026 19:06:29 +0200 Subject: [PATCH 2/2] docs: update generated research map --- generated/research-map.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generated/research-map.html b/generated/research-map.html index bbe5f21..fb59567 100644 --- a/generated/research-map.html +++ b/generated/research-map.html @@ -23,9 +23,9 @@

Focus use cases

Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.
Gap, experiments, and evidence
Current CF gap
CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.
Candidate POC
Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.
Candidate RFC scope
Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.

Core

Supporting

-
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
+
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
 -