MCP Servers in Isolated Sandboxes: Filesystem, Secrets, and Network Tradeoffs

MCP servers should run with scoped filesystem mounts, least-privilege secrets, explicit network policy, per-agent workspace boundaries, and logs so tool access does not silently expand the agent’s trust boundary. A sandbox is useful when an MCP server can read files, spawn subprocesses, install packages, call internal APIs, or hold state for a long-running agent session. The hard part is not deciding that MCP needs isolation; it is deciding which boundary belongs around each tool, which data crosses that boundary, and which actions still need human review.

Why MCP changes the agent trust boundary

The Model Context Protocol gives AI applications a common way to connect models to tools, prompts, and resources. That makes integration cleaner, but it also turns each MCP server into a policy boundary. If a server exposes read_file, run_command, query_database, or deploy_preview, the agent can now ask for actions that reach beyond the model context window.

The MCP specification describes several security expectations that matter for sandbox design: users should understand and consent to exposed tools, hosts should require consent before tool invocation, tool descriptions are untrusted unless verified, and sensitive data should be protected by appropriate access controls. Those rules are application-level controls. A sandbox adds runtime controls below them, limiting what the MCP server process can touch even if the agent, tool description, or prompt chain makes a bad request.

Think about the trust boundary in three layers:

Layer	What it controls	Common failure mode
Host or MCP client	Which servers are connected and which tool calls are approved	A broad tool is approved once and reused in a more sensitive context
MCP server	Tool implementation, authentication, input validation, resource access	A tool reads more files, sends more data, or runs more commands than expected
Sandbox runtime	Filesystem, process, network, secrets, lifecycle, and logs	The server process inherits host access because it is running too close to production resources

The goal is not to make every MCP server untrusted in the same way. A calendar lookup tool, a local code execution tool, and a deployment tool have different risk profiles. The goal is to keep each server’s runtime access no broader than the job it performs.

What to isolate first

Start with the MCP servers that can change external state, touch sensitive data, or execute code. These are the servers most likely to turn a normal prompt mistake into a broader incident.

High-priority candidates for sandboxing include:

• Code execution tools that run shell commands, Python, Node.js, compilers, tests, or notebooks.
• Filesystem tools that read or write a repository, user upload, mounted dataset, credential file, or generated artifact.
• Browser and computer-use tools that hold cookies, session state, downloaded files, or screenshots.
• Data connectors that can query customer records, analytics exports, tickets, or private documents.
• Deployment and CI tools that can create branches, publish previews, rotate config, or modify infrastructure.
• Package and dependency tools that can fetch code from registries, Git remotes, or arbitrary URLs.

Lower-risk MCP servers can still deserve controls. A read-only public documentation search server may not need a microVM per request, but it should still have an allowlisted network path, logs, and rate limits. Isolation should follow the practical blast radius of the tool, not the label “MCP server.”

Where the MCP server should run

There are three common placement patterns. None is universally right.

Placement	Use when	Watch out for
Same sandbox as the agent workspace	The server is tightly coupled to the agent’s current files, shell commands, browser session, or generated artifacts	The server and agent share state, so a compromised tool can see the same workspace unless mounts and secrets are scoped
Separate sandbox per MCP server or tool group	The tool needs stronger isolation from the agent workspace, handles different credentials, or performs higher-risk execution	Cross-sandbox file transfer and latency become part of the product design
Outside the sandbox behind a scoped API	The tool is a stable production service with its own authentication, authorization, logging, and rate limits	The API must be narrow; do not expose a broad internal admin surface just because it sits outside the sandbox

Running a server in the same sandbox is convenient for coding agents. The MCP server can see the repository, run tests, inspect artifacts, and return results without moving files across environments. This works best when the workspace itself is already disposable and contains only the files the agent should use.

A separate sandbox is better when the tool deserves a different policy. For example, a package-analysis MCP server might need internet access to public registries, while the main coding agent should not. A browser MCP server may need cookies for a test account, while a code execution server should never see those cookies.

An outside service fits tools that are not really “runtime tools” at all. A billing lookup, feature-flag read, or issue tracker search may be safer as a normal backend API with server-side authorization than as a free-form server inside the agent’s compute environment.

Filesystem mounts and per-agent workspaces

Filesystem access is where MCP convenience often turns into accidental privilege. A server that needs to read ./src should not inherit a developer’s home directory. A tool that writes generated charts should not be able to overwrite deployment config.

Use explicit workspace boundaries:

• Give each agent run its own workspace directory.
• Mount only the repository, upload folder, dataset, or artifact directory needed for the task.
• Prefer read-only mounts for source material and read-write mounts only for outputs.
• Separate generated outputs from trusted source files.
• Avoid mounting credential folders such as .ssh, cloud config directories, browser profiles, or local package manager auth files.
• Reset or snapshot the workspace between unrelated users, tenants, or jobs.

MCP roots can help clients communicate the filesystem locations a server should operate on, but roots are not a complete security boundary by themselves. Treat them as a coordination mechanism between client and server. The runtime still needs filesystem-level limits, and the server should validate paths so requests cannot escape the intended workspace with symlinks, relative paths, or archive extraction tricks.

A practical pattern is to split workspace access by role:

Directory	Access	Purpose
/workspace/input	Read-only	User uploads, seed repo, benchmark fixture, or test data
/workspace/output	Read-write	Generated files, reports, patches, charts, or screenshots
/workspace/tmp	Read-write, disposable	Build cache, package install cache, scratch files
/workspace/secrets	Avoid file mounts where possible	If unavoidable, mount one scoped secret file with strict lifetime and redaction

The exact paths do not matter. The principle does.

Secrets and environment variables

Secrets are usually easier to leak than files because they travel through environment variables, logs, stack traces, package scripts, shell history, browser sessions, and tool responses. When an MCP server needs a credential, give it the narrowest credential that can complete the tool action.

Use separate credentials for separate MCP servers. A GitHub issue-search server may need read-only issue access. A PR-authoring server may need branch write access. A deployment server should not share either token unless the permission model truly requires it.

Good secret handling for MCP servers looks like this:

• Inject secrets at sandbox or process start, not through prompts.
• Use short-lived or revocable tokens when the provider supports them.
• Scope credentials by tool, tenant, environment, and action.
• Redact secrets from stdout, stderr, structured tool responses, and trace logs.
• Do not return raw environment variables to the model.
• Do not let the agent decide which secret to load.
• Rotate credentials used by high-risk servers and after suspected prompt-injection exposure.

Avoid a common anti-pattern: one all-purpose environment file mounted into every agent session. It makes local development easier and production review harder. If a tool does not need a secret, it should not be able to read it.

Network egress and transport choices

MCP supports local and remote transport patterns. The specification describes stdio for local process communication and Streamable HTTP for server-to-client communication over HTTP. Older SSE-based designs still appear in the ecosystem, but new integrations should check the current MCP documentation and the chosen SDK before depending on a specific transport.

Transport choice and sandbox network policy solve different problems:

Question	Transport answers	Network policy answers
How does the MCP client talk to the server?	stdio, HTTP-based transport, or another supported pattern	Not applicable
Which external hosts can the server call?	Not enough by itself	Allowlist, denylist, proxy, DNS policy, or no egress
Can the server fetch packages or web pages?	Not enough by itself	Registry allowlists, URL allowlists, caching, and logging
Can another process reach the server?	Binding and authentication details	Inbound firewall and sandbox network boundary

For local stdio servers, the risk is often inherited host access. The server may run as a child process of the host application and see local files, environment variables, and network routes. If that server executes code or reads sensitive files, move it into a sandboxed process or run the whole host-worker pair inside a disposable workspace.

For HTTP-based MCP servers, the risk shifts toward authentication, network exposure, and cross-tenant separation. Use server-side authorization, TLS, origin checks where relevant, and per-client credentials. Do not expose a remote MCP server on a broad internal network without a clear policy for who can invoke which tools.

For network egress, default-deny is easier to reason about than default-open. If a tool needs package installs, allow the package registry or a pull-through cache. If it needs web research, route through a proxy that logs requested domains and blocks internal metadata endpoints. If it needs internal APIs, expose a narrow API instead of the entire private network.

Package installs, subprocesses, and long-running state

Many useful MCP tools need subprocesses. Coding agents run tests. Data agents install libraries. Browser agents launch browsers. Build agents call compilers. Subprocess support is not the problem; invisible subprocess support is.

Before allowing package installs or shell execution, define:

• Which commands are allowed, denied, or approval-gated.
• Whether package managers can reach the public internet.
• Whether dependency versions must be pinned or lockfile-based.
• Where build caches and installed packages live.
• How long background processes can run.
• Which output files are retained after cleanup.
• Whether the agent can start network listeners.

Long-running MCP servers introduce a second issue: state drift. A server that lives for hours may accumulate files, credentials, browser cookies, shell history, dependency changes, and background jobs. That state can be useful for multi-step workflows, but it must belong to the right agent, user, and task.

Use lifecycle controls:

Control	Why it matters
Per-agent sandbox IDs	Prevents one agent’s tool state from becoming another agent’s context
Idle timeout	Cleans up abandoned tool sessions
Pause and resume policy	Supports long jobs without keeping unnecessary compute active
Snapshot or template policy	Starts repeatable environments from a known baseline
Explicit teardown	Removes files, kills processes, and releases credentials after the job

If a tool produces durable artifacts, copy only those artifacts out of the sandbox. Do not preserve the whole workspace unless the product explicitly needs full session replay.

Logging, cleanup, and human review

MCP tool logs should answer security and debugging questions without turning into a new secret store. Useful logs include tool name, caller identity, sandbox ID, workspace ID, command category, files read or written, external domains contacted, package names installed, exit status, and artifact paths.

Do not log raw prompts, raw customer data, tokens, full file contents, or complete command output by default. Keep sensitive traces behind stricter access controls and retention policies.

Some MCP actions should remain human-reviewed even inside a sandbox:

• Publishing or deploying to production.
• Sending email, chat, tickets, invoices, or customer-facing messages.
• Modifying access control, billing, user data, or infrastructure config.
• Exfiltrating large files, private repositories, database exports, or credential-like strings.
• Running commands outside the workspace policy.
• Calling internal APIs with write permissions.

The sandbox should reduce blast radius. It should not become a reason to remove review from sensitive business actions.

How Novita Agent Sandbox fits

Novita Agent Sandbox is designed for agent workloads that need an isolated runtime for code execution, files, processes, browser-style workflows, and long-running sessions. It can fit MCP architectures where a tool server needs a disposable workspace instead of direct access to a developer laptop, production host, or shared CI machine.

Use it as the runtime boundary for servers that need to:

• Execute generated code or commands.
• Work with temporary files and generated artifacts.
• Keep per-agent workspace state across multi-step tasks.
• Run background work that the agent can check later.
• Separate agent experimentation from the application host.

Keep the product boundary clear: an MCP server is still your application code. You still design the tool permissions, credential scopes, network policy, approval flow, logging schema, and cleanup behavior. The sandbox provides the isolated environment where those decisions are enforced.

For product-specific setup, use current Novita documentation rather than copying stale snippets from older tutorials. Conceptually, the shape is:

for each agent task:
  create sandbox from approved template
  mount only the task workspace
  inject only tool-specific secrets
  start the MCP server inside the sandbox or connect to a sandbox-backed tool API
  route tool calls through approval and policy checks
  collect logs and approved artifacts
  stop, reset, or pause the sandbox according to the task lifecycle

This keeps the article-level guidance stable while leaving exact SDK calls to the latest documentation and your platform code.

Implementation checklist

Use this checklist before connecting an MCP server to an autonomous or semi-autonomous agent:

Area	Questions to answer
Tool scope	What tools does the server expose, and which ones change external state?
Placement	Should the server run in the agent sandbox, a separate sandbox, or outside the sandbox behind a narrow API?
Filesystem	Which directories are mounted, are they read-only or read-write, and how are path escapes blocked?
Secrets	Which credentials are injected, how are they scoped, and where can they appear in logs or outputs?
Network	Is egress default-deny, proxy-routed, or allowlisted by domain, registry, and internal API?
Subprocesses	Which commands, package managers, background jobs, and listeners are allowed?
State	How are per-agent workspaces, snapshots, idle timeouts, pause/resume behavior, and cleanup handled?
Logs	Can you reconstruct tool calls, file changes, external domains, and artifacts without storing secrets?
Human review	Which tool calls require approval before execution, export, deploy, or customer-facing action?
Testing	Have you tested prompt injection, symlink/path traversal, large output, failed cleanup, and denied egress paths?

MCP makes tool integration easier. Sandboxing keeps that integration from becoming a silent expansion of the model’s privileges. The right design is usually a mix: some servers in the same agent workspace, some in separate sandboxes, and some outside the sandbox behind APIs with strict authorization. Choose the placement that matches the tool’s data, secrets, subprocesses, and network needs.

FAQ

Should every MCP server run in a sandbox?

No. Prioritize servers that execute code, read or write files, use secrets, call private services, launch browsers, install packages, or change external state. Lower-risk read-only servers may still need authentication, logging, and network controls, but they may not need a dedicated sandbox per request.

Is stdio safer than HTTP for MCP servers?

Not automatically. Stdio can be simple for local servers, but the server may inherit local filesystem, environment, and network access. HTTP-based servers need stronger authentication and exposure controls. The safer choice depends on where the process runs and which runtime permissions it receives.

Can MCP roots replace filesystem sandboxing?

No. Roots help communicate intended workspace locations between client and server, but they are not a complete runtime boundary. Use path validation and sandbox-level filesystem controls to keep the server inside the intended workspace.

Where should secrets be stored for sandboxed MCP tools?

Inject only the credentials the tool needs, ideally as short-lived environment variables or scoped runtime secrets. Do not mount broad developer credential folders or pass secrets through prompts. Redact them from logs and tool responses.

When should an MCP tool require human approval?

Require approval for production deploys, customer-facing messages, billing or access-control changes, large data exports, infrastructure writes, and any command or network action outside the normal workspace policy.

Recommended articles

• Build a Remote Code Execution MCP Server with Novita Sandbox and mcp-use Library
• Building a Coding Agent with Novita’s Agent Sandbox
• How Agent Sandboxes Power Secure, Scalable AI Innovation