Decide production agent sandbox framework: AppContainer, OpenClaw Docker, or MXC

[yikkuro]

Problem

MicroClaw needs a production security boundary for agent tool execution. We currently have three plausible approaches with materially different threat models, deployment requirements, user experiences, and maintenance costs:

1. Windows AppContainer — MicroClaw's existing Windows-native implementation with custom RO/RW directory permissions, NTFS ACL management, and interactive permission prompts.
2. OpenClaw Docker sandbox — OpenClaw's built-in Linux-container sandbox running through Docker Desktop/WSL2; an experimental MicroClaw integration exists in Experimental: replace AppContainer with mandatory Docker sandbox #198.
3. Microsoft MXC — policy-driven cross-platform containment using native platform backends, including Windows ProcessContainer/AppContainer/BaseContainer mechanisms; currently public preview and explicitly not yet presented as a production security boundary.

A production choice must be made before further investment or release. Running multiple partially overlapping sandbox systems without a clear ownership model increases complexity and can create unsafe fallback paths.

Goal

Select and document the production sandbox architecture for MicroClaw agent/tool execution, supported by an explicit threat model, reproducible security tests, product UX requirements, deployment constraints, and an implementation/migration plan.

Options to evaluate

A. MicroClaw Windows AppContainer

• Windows-native tools and paths
• Existing dynamic RO/RW folder prompt UX
• Custom ACL/provisioning/runtime interception code owned by MicroClaw
• Known synchronization, timeout, and desired-vs-effective-state complexity
• Strong Windows coupling and maintenance burden

B. OpenClaw Docker sandbox

• Built-in OpenClaw lifecycle/tool routing
• Linux container isolation through Docker Desktop/WSL2
• Secure container defaults available: non-root, read-only root, no network, dropped capabilities, resource limits
• Requires Docker Desktop/WSL2 and Linux-compatible tools
• Host access uses fixed Docker bind mounts; no built-in dynamic folder permission prompt
• Experimental integration: Experimental: replace AppContainer with mandatory Docker sandbox #198

C. Microsoft MXC

• Declarative policy model with Windows-native ProcessContainer and other backends
• Direct RO/RW host-path policies without requiring Docker for the default Windows backend
• Potentially replaces custom launcher/policy implementation while retaining Windows compatibility
• Public preview/pre-1.0; repository currently warns policies must not yet be treated as security boundaries
• No built-in runtime permission broker; Electron/MicroClaw must own consent UX
• Native sidecar, host preparation, ACL restoration, Windows-version, and MSIX questions require proof

Required threat model

Define what the sandbox must protect against, including:

• Malicious or prompt-injected model-generated commands
• Untrusted skills/plugins and child processes
• Reads/writes outside approved folders
• Credential, browser-profile, SSH/cloud-token, and application-data access
• Network exfiltration and localhost/service access
• Process spawning, persistence, UI automation, named pipes, registry, devices, and host escape
• Symlink/junction/reparse-point, UNC, mount, and path-canonicalization attacks
• Cross-agent/session data leakage
• Sandbox unavailability, startup failure, stale configuration, and downgrade/fallback behavior
• Compromised Gateway versus compromised tool subprocess assumptions

Evaluation criteria

Create a measured comparison covering:

Area	Questions
Security boundary	What OS/runtime primitive enforces isolation? What is inside the trusted computing base? Is it fail-closed?
Filesystem	RO/RW host folders, path canonicalization, dynamic permission UX, mount/ACL lifecycle, concurrent agents
Network	Default egress, allowlisting, DNS/localhost, proxy bypass, auditability
Process/tool compatibility	Windows/PowerShell/native apps versus Linux tools; child-process containment
Scope	Per turn/session/agent isolation and cleanup semantics
User experience	Installation, prompts, status transparency, recovery, offline behavior
Distribution	EXE and MSIX compatibility, elevation, Store policy, signing, Docker/WSL/VM prerequisites
Reliability	Startup latency, resource use, updates, crash recovery, stale state, rollback
Maintainability	Upstream ownership, custom code size, platform support, release cadence
Maturity	Security claims, version stability, independent review, known limitations

Required proof-of-concept tests

Run the same adversarial test suite against each viable option:

• Approved RO path can be read but not written; approved RW path can be modified
• Unapproved Desktop/home/AppData/system/credential paths are blocked
• Junction/symlink/reparse and parent-path escapes fail closed
• Child processes inherit restrictions
• Network-off blocks DNS, direct IP, localhost, IPv4/IPv6, and proxy-based escape
• Secrets are absent from environment, filesystem, logs, and crash output
• Cross-agent/session isolation works
• Configuration changes produce honest desired/effective status
• Sandbox startup/configuration failure never falls back to unrestricted host execution
• Cancellation, crash, app restart, update, and uninstall leave no unsafe permissions/runtime state
• EXE and MSIX clean-machine install and lifecycle validation
• Performance measurements: cold/warm startup, memory, CPU, and typical tool latency

Decision deliverables

• Architecture Decision Record naming the selected framework and rejected alternatives
• Approved threat model and security assumptions
• POC results with reproducible commands/tests and target Windows versions
• UX specification for folder access and command approvals
• Deployment/prerequisite and Microsoft Store impact assessment
• Fail-closed and rollback design
• Migration plan from existing AppContainer settings/ACLs and experimental Docker state
• Security review before production enablement

Acceptance criteria

• All three approaches are evaluated against the same threat model and test matrix, or a documented blocker explains why an option was eliminated early
• The selected framework passes the agreed fail-closed/adversarial tests on supported Windows versions
• Product and Security approve the user-consent and host-folder-access model
• EXE/MSIX deployment and upgrade implications are validated
• An ADR and staged implementation/migration plan are approved
• Experimental implementations are either promoted with safeguards or removed; no ambiguous dual-sandbox fallback remains

References

• OpenClaw Docker experiment: Experimental: replace AppContainer with mandatory Docker sandbox #198
• MXC: https://github.com/microsoft/mxc
• OpenClaw sandboxing: https://docs.openclaw.ai/gateway/sandboxing

[yikkuro]

Investigation update — OpenClaw Docker and MXC

OpenClaw Docker sandbox: implemented and live-tested

Experimental integration: #198

We replaced AppContainer on the experimental branch and configured OpenClaw's built-in Docker sandbox as the sole tool-execution boundary:

• mode: all
• backend: docker
• scope: agent
• workspaceAccess: none
• non-root 1000:1000
• read-only container root
• network: none
• capDrop: [ALL]
• no-new-privileges
• 1 GiB memory, 1 CPU, and 256 PID limits
• elevated/host escape disabled
• fail-closed readiness and configuration checks

Live verification on Windows with Docker Desktop/WSL2 confirmed:

• a benign tool command ran inside Linux as uid=1000(sandbox) under /workspace
• no unrestricted host fallback occurred
• RO host binding allowed reads and denied writes
• changing the same binding to RW allowed writes
• removing the binding removed container access
• per-agent binding isolation worked: a binding assigned to main was absent from another agent
• containers retained no network, non-root identity, read-only root, dropped capabilities, and no-new-privileges

The Security page now has per-agent RO/RW bind management with native folder selection, deterministic Linux targets, canonical/reparse-aware path validation, dangerous-root blocking, desired/effective state, retry, atomic config persistence, and targeted agent sandbox recreation.

Docker findings and limitations

• On Windows, Docker Desktop runs Linux containers through WSL2, adding installation, licensing, virtualization, resource, startup, and Microsoft Store considerations.
• Windows-native executables and paths do not run directly inside the Linux sandbox.
• Host folders must be exposed as Docker bind mounts when a container is created. OpenClaw does not provide a dynamic "ask the user to mount this folder" mechanism.
• Changing binds requires recreating the affected agent sandbox. There is no per-read permission prompt.
• OpenClaw native exec approvals guard host/node execution, but MicroClaw does not currently integrate their UI. The experiment disables host/elevated execution, so these approvals are not part of the current Docker path.
• First-run OpenClaw migrations/plugin installation took about 96 seconds and exceeded the original UI health window; startup/readiness UX must account for long but legitimate provisioning.
• Docker is a strong candidate when Linux tool compatibility and its prerequisites are acceptable, but it materially changes the Windows product experience.

MXC: repository investigation complete; POC not yet run

Reviewed Microsoft MXC main at commit 331fbeec42154dc4b584d34369c3f415ca2a01a6 (v0.7.0-rc1 / package version 0.7.0).

MXC is a policy/launcher framework for sandboxing a selected process and its children. It is not primarily a new universal isolation primitive. A host constructs a declarative policy and MXC translates it to a platform backend.

On Windows, its default ProcessContainer path uses:

• newer BaseContainer APIs where available
• AppContainer plus NTFS ACL fallback on other supported Windows tiers
• Job Object UI restrictions and Win32k mitigation

The policy can define:

• read-only paths
• read-write paths
• denied paths
• network policy
• UI restrictions
• process configuration

MXC does not provide runtime folder or command permission prompts. MicroClaw would still own consent UX, then launch an agent-controlled tool worker under an MXC policy containing only approved access.

Recommended trust split:

MicroClaw UI / OpenClaw Gateway (trusted control plane, outside MXC)
                    |
                    v
MXC-sandboxed tool worker and child processes (untrusted execution plane)

Running all of Electron/MicroClaw inside MXC would require broad UI, credential, settings, update, and network permissions and would weaken the useful boundary.

MXC benefits versus our custom AppContainer

• standardized/versioned policy model instead of MicroClaw-specific environment and allowlist formats
• maintained native executors and Node SDK
• potentially removes custom launcher/preload/interception code
• Windows-native commands and direct host-path policies without Docker/WSL for the default Windows backend
• cross-platform backend abstraction

MXC risks and limitations

• MXC currently explicitly warns that its policies may be overly permissive and must not yet be treated as security boundaries
• public preview/pre-1.0, with several experimental backends
• on fallback Windows tiers, the underlying boundary is still AppContainer + ACLs, so it may standardize our implementation without materially strengthening it
• no built-in permission broker or command allowlist
• Windows host preparation may require elevation and persistent ACL changes, which needs EXE/MSIX validation
• Windows network hostname allow/block behavior is limited; it must be tested rather than assumed
• documentation has some inconsistency around denied-path support across Windows tiers

Current assessment

Option	Current assessment
Custom AppContainer	Best existing Windows-native permission-prompt UX, but high custom security/reliability maintenance and known desired/effective state complexity
OpenClaw Docker	Working POC with strong container posture and upstream tool routing; operational/product cost is Docker Desktop + WSL2 and Linux-only execution semantics
MXC	Promising Windows-native policy/launcher replacement for custom AppContainer machinery, but maturity/security warning currently blocks treating it as a production upgrade

No production framework decision should be made yet. Docker has passed an initial functional/isolation POC; MXC still needs an equivalent Windows POC and adversarial test run.

Next investigation steps

1. Build an MXC POC that runs only an agent-controlled tool worker, not Electron/Gateway.
2. Identify the effective MXC Windows tier on every supported Windows version and whether elevated host preparation is required.
3. Run the same RO/RW/deny, junction/reparse, child-process, credential, network, concurrency, failure, and cleanup tests used for Docker/AppContainer.
4. Measure cold/warm startup, memory, CPU, and command latency for all candidates.
5. Validate signed EXE/MSIX installation, update, repair, and uninstall behavior—including ACL cleanup and Docker prerequisites.
6. Define the required user-consent UX. Neither OpenClaw Docker nor MXC supplies dynamic host-folder permission prompts natively.
7. Perform a dedicated security review before promoting any experiment.

References

• Docker experiment: Experimental: replace AppContainer with mandatory Docker sandbox #198
• MXC repository: https://github.com/microsoft/mxc
• MXC preview warning: https://github.com/microsoft/mxc/blob/331fbeec42154dc4b584d34369c3f415ca2a01a6/README.md#L3-L8
• MXC policy design/non-goals: https://github.com/microsoft/mxc/blob/331fbeec42154dc4b584d34369c3f415ca2a01a6/docs/sandbox-policy/v1/policy.md
• MXC Windows support tiers: https://github.com/microsoft/mxc/blob/331fbeec42154dc4b584d34369c3f415ca2a01a6/docs/process-container/os-version-support.md
• OpenClaw sandboxing: https://docs.openclaw.ai/gateway/sandboxing