Sandboxing the Filesystem Model Context Protocol Server for Coding Agents

What you are confining

A Filesystem MCP server gives a coding agent tool calls to read, write, move and delete files. The risk is not the protocol itself. It is the gap between the files the agent needs and the files the server process can actually reach. OWASP lists sandbox escapes as a key MCP risk: a local server running with full host access can enable file system traversal, credential theft or arbitrary code execution.

Three filesystem-specific failure modes recur. Path traversal uses sequences such as ../ to step out of an intended directory. Symlink escape places a link inside the workspace that resolves to a location outside it. Overly broad mounts, such as a home directory or a repository parent, put credentials and unrelated projects within reach without any exploit at all.

The design principle that follows is to treat the server's own path checks as one layer, not the boundary. The operating system should refuse access to anything outside the workspace, so that a validation gap in the server does not become a host exposure. Also verify the package name before installing. OWASP cites mcp-server-filesystem versus mcp-server-filesytem as a typosquatting example, and it advises treating each MCP server as an untrusted, independent security domain.

Layer 1: scope the server before isolating it

Start with the smallest possible footprint. Configure the server's allowed-directory setting, using whatever mechanism your server version provides, with a single project path rather than a parent directory. Then make sure the same narrow scope is enforced outside the server process, in the mount.

Separate read from write. Per-tool permission scoping, with read-only versus write access and specific resources, is standard OWASP agent guidance. In practice, mount reference material and source trees read-only, and give the agent a distinct writable path for output. Remove move and delete capability where the task does not need it.

Then deal with secrets by construction rather than by filtering. Build the workspace from a checkout or copy of the required project files, not from a live developer home directory. SSH keys, cloud credentials, shell history and Kubernetes configuration should never be present. Those are exactly the items targeted in the Deadbugz campaign. Scan the workspace for .env files and for symlinks that point outside it before each run.

• Allow one project directory, not a parent or home directory.
• Mount source and reference files read-only.
• Provide a separate writable path for agent output only.
• Disable move and delete if the task does not require them.
• Build the workspace from a clean checkout with no credential files.
• Reject or remove symlinks that resolve outside the workspace.

Layer 2: choose a process isolation mechanism

OWASP DSOMM recommends running AI coding agents in a dedicated, least-privilege sandbox that holds only the required project files and is destroyed after use. It names containers, lightweight virtual machines and OS-level sandboxing as options. A bare chroot is not a process sandbox and should not be your only control.

For containers, use a non-root user, a read-only root filesystem, dropped capabilities, no-new-privileges and a restrictive seccomp or AppArmor profile. Bind-mount only the workspace. Set network egress to deny by default and allow named endpoints explicitly, since DSOMM treats egress restriction as a separate control. Keep the container definition, such as a dev container file, under version control.

• Container with read-only mounts: Fast to start and easy to version. Shares the host kernel, so its strength depends on profile hardening and a non-root user.
• Lightweight VM or microVM: Stronger separation, with its own filesystem and network. Docker Sandboxes, for example, use disposable microVMs. Costs more to operate and start.
• OS-level sandboxing: Low overhead on a developer machine. Policy is tied to the platform and tends to be harder to standardise across a fleet.
• Ephemeral workspace: Destroyed after each run, which limits persistence and drift. It complements the above and does not replace them.

What static sandboxing does not address

A well-built sandbox limits blast radius. It does not decide whether a particular call inside that radius is appropriate. Three residual risks remain.

First, the agent may hold broader access than the server. OWASP's Q3 2026 exploit roundup describes Deadbugz, where an approved server behaved normally for three tool calls, then changed its tool metadata to direct the agent toward SSH keys, AWS credentials, shell history and Kubernetes configuration. OWASP characterises it as a runtime trust failure, not a command-injection flaw. The server used the trusted agent to collect the secrets. That incident involved a different server, but the lesson applies: an allowlist on the filesystem server does not help if the agent can reach those files by another route.

Second, one-time approval is not enough. OWASP recommends requiring re-approval when MCP definitions change and treating new servers like any other software dependency.

Third, legitimate scope can still be misused. A prompt-injected agent can read a permitted file that contains a secret, or overwrite a permitted build or CI configuration. Mounts cannot distinguish a reasonable read from a harmful one, and they leave no record of what was decided.

Layer 3: enforce policy on each tool call

Runtime policy closes that gap by evaluating each tool call before it executes. For a filesystem server, the decision set is straightforward: allow the call, redact sensitive content in the result, block the call, or escalate it for human approval. Examples include blocking any path outside the approved workspace, redacting credential patterns from file contents returned to the agent, and escalating deletes or writes to build configuration.

Trussed provides this layer. It enforces policy in the execution path across agents, tools, MCP servers and coding assistants, at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact. Each enforcement decision generates audit-ready evidence, mapped to frameworks including NIST, so a security team can show what an agent was permitted to do and what it did. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

This layer sits on top of isolation and does not replace it. The sandbox bounds what is reachable. Policy governs what is done within that boundary. Evidence per call lets you demonstrate both, alongside the sandbox configuration and a live session inside it, which is what DSOMM suggests retaining.