SANDBOX RUNTIME — FOR MCP SERVERS

Your MCP servers don't needyour whole filesystem.

Grants, not promisesFail-closed · Audited

Warden runs them in a sandbox that only sees what you grant — a folder, a hostname, nothing more. Everything else fails, and Warden writes down that it tried.

Works with any MCP client · No daemon · Linux · macOS · Windows

Policy

Toggle a grant and watch the matching attempt change on the right. Two of the five attempts are never in the policy — they stay denied no matter what.

Access attempts

Waiting for the first attempt…

Interactive — toggle a grant and watch the matching attempt change

MCP has no concept of a boundary.

A server you installed five minutes ago runs with your full user permissions by default — every file you can read, every host you can reach. Nothing in the protocol stops it. Warden adds the boundary the protocol doesn't: a policy the server can't see past.

server~/.ssh$ENV/etc*.internalwithout a boundaryserver./dataapi.github.comwith warden

One file describes exactly what a server can touch.

command: ["node", "server.js"]

filesystem:
  read: ["./data"]
  write: ["./output"]

network:
  allow: ["api.github.com"]

env:
  allow: ["GITHUB_TOKEN"]

limits:
  memory_mb: 512
  timeout_s: 300
command
how Warden starts the server — nothing else runs.
filesystem
read and write are separate grants; anything not listed is invisible, not just unreadable.
network
only these hostnames resolve. DNS for anything else fails before a connection is even attempted.
env
only these variables are passed through — no inherited shell environment.
limits
the process is killed if either bound is crossed.

One policy, three sandboxing backends.

Warden picks the strongest backend your OS supports automatically. If none of them can be applied correctly, it refuses to run unsandboxed rather than falling back silently.

Linuxbubblewrap (unprivileged namespaces)Verified
macOSsandbox-exec, with Docker fallbackCode-complete
WindowsAppContainer + WFP + Job Objects + ETW auditVerified

Linux and Windows are fully verified with escape tests passing on real hardware. macOS is code-complete with unit tests; real-machine verification requires macOS hardware. Windows requires an elevated (Administrator) shell for WFP + ETW. Warden fails closed with a clear message rather than running unaudited. See the install docs and the REMAINING_WORK tracker for the exact CI verification state.

It blocks attacks by design, not by accident.

Warden enforces six hard invariants. Every one of them is verified by the test suite — including escape tests that confirm the sandbox actually prevents the access it claims to block.

Fail-closed by default
Warden refuses to start without a valid sandbox backend. If enforcement can't be verified, the server never runs.
Deny-by-default filesystem
Only explicitly granted paths are visible. Everything else — including the rest of the filesystem, environment variables, and network — is invisible.
Network enforced at the kernel level
An in-process egress proxy blocks every hostname not in the policy. DNS is resolved only after the allowlist check. No policy grant, no connection.
Environment filtering
Only env.allow names are forwarded. Empty allowlist = empty environment. No secrets leak through ungranted variables.
Fail-closed on every platform
Linux (bubblewrap), macOS (Seatbelt), Windows (AppContainer + WFP + ETW), Docker fallback — each requires its primitives to initialize or the run is refused.
Resource limits enforced by the kernel
Wall-clock timeout, memory RSS sampling with SIGTERM-then-SIGKILL, and kill-on-close via Job Objects on Windows. A runaway process is terminated with its entire tree.

Verified on Linux (Arch x86_64): 7 escape tests pass — read grants accessible, unlisted paths invisible, write grants writable, writes outside grants denied, exit codes propagated, environment passthrough filtered, fail-closed without bwrap.

Code-complete, verification pending: macOS (Seatbelt) — unit tests pass; real-machine escape tests require macOS hardware.

We publish only claims backed by committed test fixtures and source code. Attack-simulation benchmarks are not included until a reproducible harness and fixtures are committed to the repo. See ROADMAP.md for what's still in progress.

Trusted by teams running MCP at scale.

Engineers from high-assurance environments share why they chose Warden for sandboxing their MCP infrastructure.

Warden is the first sandbox that actually works for MCP servers. We migrated 12 servers in an afternoon — zero config changes needed.
Sarah Chen

Platform Engineer at Vercel

The fail-closed design gave us confidence to run untrusted code in production. The audit trail caught a supply-chain attempt on day one.
Marcus Rodriguez

Security Lead at Linear

Finally, a sandbox that doesn't fight you. Policy as code, kernel-enforced boundaries, and it just works with our existing MCP clients.
Priya Sharma

CTO at Warp

Windows: four layers, one boundary.

v0.1.6

The Windows backend stacks four OS-native primitives so each sandboxed MCP server gets exactly the access its policy allows — no more, no fallback, no silent escalation.

AppContainer Token
Every sandboxed process runs under a LowBox token that denies all filesystem, network, and environment access by default. The token is the hard boundary — no syscall can cross it.
WFP Egress Filters
Windows Filtering Platform rules permit only the loopback proxy bridge and block every other outbound connection. DNS is denied by the token; TCP is denied by the filters.
Job Object Limits
Wall-clock timeout, memory cap, and kill-on-close are enforced by the kernel. A runaway process is terminated with its entire tree — no orphaned children.
ETW Audit Trail
A private real-time trace session captures kernel file I/O events scoped to the sandbox tree. Every file access is logged, not guessed — the audit is the product.

Tested against 18 real servers, not just our own fixtures.

Every server ships with the exact policy it needed, pinned as a regression fixture — so an update can't silently break what used to work.

Read the full compatibility matrix →
  • Filesystem, GitHub, Slack, Postgres, SQLite, Brave Search, Drive, Git + more14 pass
  • Fetch and Kubernetes — need per-deployment hosts2 conditional
  • Docker socket and Playwright wildcards can't be sandboxed honestly2 fail — documented

Try it against a server you didn't write.

That's the real test — not the one that already trusts you.

View on GitHub