Warden backends: bubblewrap, Seatbelt, AppContainer

Every operating system already ships a kernel-level sandbox mechanism. Warden doesn't invent oneit compiles the same policy file into whichever mechanism the host provides. This article explains the three backends and what each one actually enforces.

Linux: bubblewrap

On Linux, Warden uses bubblewrap (bwrap) to build the server's view of the filesystem from scratch:

• Only paths granted in the policy are bind-mounted into the new mount namespace; everything else simply does not exist to the process
• Network egress is mediated by a proxy so allowlisted hosts are enforced outside the server's own process, where it can't be bypassed from inside
• CPU and memory limits are applied through kernel resource controls

Because the grants are enforced by the kernel through namespaces, a compromised server process cannot escape them by misbehaving in userspace.

macOS: Seatbelt

On macOS, Warden compiles the policy into a Seatbelt (sandbox-exec) profile. Seatbelt operates on the same principleoperations not explicitly allowed by the profile are denied by the kernelso the deny-by-default model maps directly. Where the Seatbelt backend cannot yet guarantee parity with Linux for a given grant, Warden falls back to a Docker-based sandbox and says so, rather than pretending the native backend is stricter than it is.

Windows: AppContainer + WFP + Job Objects

Windows support uses three cooperating layers:

• AppContainerthe server runs with a LowBox token that constrains filesystem and object access to explicitly granted capabilities
• WFP egress filtersWindows Filtering Platform rules enforce the network allowlist at the kernel level
• Job ObjectsCPU and memory limits, with the whole job terminated on breach
• ETW auditingenforcement events are captured through Event Tracing for Windows into the JSONL audit stream

One policy, equivalent guarantees

The point of the backend architecture is that a policy file means the same thing everywhere: the same filesystem grants, the same host allowlist, the same env filtering, the same fail-closed behavior on startup failure. The full feature reference documents each backend's current verification status, and the testing page shows the cross-platform test matrix.

Conclusion

You don't need to learn three sandbox APIs to run MCP servers safely on three platforms. Write the policy once; Warden translates it into the primitives your OS already provides. For the enforcement path in detail, see how Warden enforces policies.