25 MCP Servers Scanned: What They Can Do to Your Machine Before You Sandbox Them

An MCP server is not a remote API. For the stdio transport — the default for most popular Model Context Protocol servers — npx some-mcp-server resolves and downloads a Node package, then executes it as a local child process. That process inherits your shell's environment variables, runs with your user's filesystem permissions, and has access to your machine's network stack. The agent does not call it over HTTPS; it writes JSON-RPC messages to the process's standard input and reads responses from standard output. The server's code decides how to interpret those instructions.

This is a normal and useful design. It gives the agent access to local tools, credentials, and services that a remote API could not reach. But it also creates a capability surface that is rarely itemized before install. In a static source scan of 25 published MCP server packages, the reachable capabilities included:

• A network-call site in 17 of 25 packages.
• Reads from process.env (e.g., process.env.API_KEY) in 16 of 25.
• A hardcoded outbound host reference in 12 of 25.
• Subprocess spawning or shell-outs in 8 of 25.
• Bundled prebuilt binaries in 4 of 25.

These are reachable capabilities, not evidence of malicious intent — most secret reads are a server loading its own credential. The issue is aggregate. A multi-server agent setup runs a dozen or more local processes, most reading environment variables and making network calls, several able to spawn subprocesses, all with the same privileges as the launching shell. A server that reads process.env.AWS_ACCESS_KEY_ID to authenticate may expose that variable to any code path that makes an outbound request; a compromised dependency in one package puts the credential one network call away from leaving the machine.

The blast radius compounds in agentic loops: every server's capability, multiplied by the agent's autonomy, multiplied by the number of turns. Run servers and the agent in a sandbox that denies filesystem access, egress, and secret reads by default, and that blocks processes from rewriting the sandbox's own guardrails. That converts a silently inherited capability surface into one you explicitly grant.

To measure the capability surface of Model Context Protocol servers, I performed a static source scan of 25 published MCP server packages. The scan examined the published package code — not runtime behavior — for four categories of capability:

• Net-call sites: code paths that can make outbound network requests.
• Secret-env reads: references to credentials via process.env, e.g. process.env.API_KEY.
• Subprocess spawns: code that shells out or spawns child processes.
• Bundled binaries: prebuilt executables shipped inside the package.

This method has a crucial limitation. Static scanning shows what a package can reach for, not what it does on a given run. A process.env.API_KEY read is almost always a server loading its own credential — a legitimate pattern. A subprocess spawn may be a deliberate feature, such as invoking a local CLI. The counts are therefore reproducible lower bounds on capability, not accusations about any specific server's behavior.

Across the 25 servers, the scan found:

• A network-call site: 17 servers (68%)
• Reads a secret from process.env: 16 servers (64%)
• A hardcoded outbound host reference: 12 servers (48%)
• Spawns a subprocess or shells out: 8 servers (32%)
• Ships a bundled binary: 4 servers (16%)

For an agent host, the aggregate picture matters. If an agent connects multiple MCP servers and operates in a loop, the blast radius is every server's capability multiplied by the agent's autonomy and the number of turns. One over-scoped server, or one compromised dependency, means a credential in process.env is one network call away from leaving the machine. Static scanning cannot tell you whether that will happen; it tells you the boundary you need to design against. Running such servers in a sandbox that constrains filesystem, egress, and secrets by default is the practical response.

Model Context Protocol servers using the stdio transport are typically installed with a package runner such as npx some-mcp-server, which downloads package code and executes it as a local process. That process inherits the launching shell’s environment, filesystem access, and network access, and the agent then sends it instructions. This is a normal design for local tooling, but it creates a capability surface that is rarely itemized before installation.

A static source scan of 25 published MCP server packages measured the following code-level capabilities:

• Network-call site: 17 of 25 servers (68%) contain code that can make outbound network calls.
• Secret read from process.env: 16 of 25 (64%) read credentials such as process.env.API_KEY.
• Hardcoded outbound host: 12 of 25 (48%) reference a hardcoded outbound host.
• Subprocess or shell execution: 8 of 25 (32%) spawn child processes or shell out.
• Bundled binary: 4 of 25 (16%) ship a prebuilt binary.

These counts are static lower bounds: they describe what the package can reach for, not what it does on every run. Reading process.env.API_KEY is commonly the server loading its own legitimate credential, and a network-call site may be inactive unless invoked. The operational concern is the aggregate surface. A typical multi-server agent setup is therefore running a dozen-plus local processes, most of which read the environment and make network calls, several of which can spawn subprocesses, all with the same privileges as the launching shell. No install step or directory listing reports this combination.

Agents amplify the risk: each server’s capability is multiplied by the agent’s autonomy and by the number of loop turns. If a package or one of its transitive dependencies is compromised, a credential from process.env may be one network call from leaving the machine. An egress allowlist entry such as *.amazonaws.com would permit traffic to an attacker-controlled S3 bucket, for example.

Auditing every package by hand before each addition does not scale. Apply default-deny constraints instead: run MCP servers in a sandbox that restricts filesystem writes, blocks undeclared egress, and redacts secrets passed from the environment. That converts an inherited capability surface into an explicit grant controlled by policy.

When you run a CLI tool, you roughly know what it does: it takes local inputs, performs a bounded set of operations, and exits. An agent is not bounded. It connects a fleet of MCP servers, passes them instructions, and acts in a loop across turns. For stdio-based MCP servers, each is commonly launched with a package runner such as npx, which downloads code and runs it as a local process with your shell's environment, filesystem, and network permissions.

This changes the risk calculus. The blast radius is not the sum of server capabilities; it is the product of every server's capability, the agent's autonomy, and the number of loop turns. A static scan of 25 popular MCP packages shows the aggregate surface a multi-server agent setup silently inherits:

• Network-call sites: 17 of 25 packages (68%)
• Reads a secret from process.env: 16 of 25 (64%)
• Hardcoded outbound host reference: 12 of 25 (48%)
• Spawns a subprocess or shells out: 8 of 25 (32%)
• Ships a bundled binary: 4 of 25 (16%)

Consider the risk scenario. One over-scoped server—or one compromised dependency inside any package—starts with access to your environment. If that server reads a credential from process.env, the credential is one network call away from leaving the machine. Egress filtering is the usual defense, but a permissive allowlist such as *.amazonaws.com does not stop exfiltration; it waves the traffic through to an attacker-nameable S3 bucket. The agent's loop compounds this: each turn hands the server another instruction, and each instruction is another chance to exercise an exposed capability.

The practical fix is not to audit every package by hand each time you add one. Run the agent and its MCP servers in a sandbox that constrains filesystem, network egress, and secrets by default: a default-deny egress allowlist, secret redaction so server processes cannot read credentials, and a guard that blocks a sandboxed process from rewriting its own guardrails. With those constraints, a server's capability stops being an authority and becomes a permission you grant explicitly.

Current architecture for Model Context Protocol (MCP) servers often relies on stdio communication, where servers execute as local processes inheriting the host shell’s full identity. This design grants the process broad access to the filesystem, network, and environment variables (process.env). Static analysis of 25 popular MCP packages reveals an expansive and often invisible capability surface: 68% of these packages contain network call sites, 64% read sensitive environment variables, and 32% spawn child processes. Manually auditing these dependencies for every server addition is an unsustainable operational burden that does not scale with the growth of agentic workflows.

The solution is to shift from manual audit-based security to a sandbox-by-default model. Rather than attempting to catalog every potential action an agent might take, security should be enforced at the runtime level. This approach transforms the capability surface from an implicit inheritance into an explicit, restricted grant.

Enclave, an Apache-2.0 licensed runtime, implements this by wrapping agents and MCP servers in a controlled execution environment. It enforces security through the following mechanisms:

• Default-Deny Egress: Network access is blocked unless explicitly permitted via a configured allowlist, preventing unauthorized exfiltration of credentials.
• Secret Redaction: Environment variables are sanitized or masked to prevent exposure to untrusted process memory.
• Immutable Guardrails: The runtime includes a supervisor guard that prevents the sandboxed process from modifying its own security constraints or escaping the containerized filesystem.

By shifting to a sandboxed runtime, engineers decouple the agent’s functional requirements from the underlying host privileges. This architecture ensures that a single compromised dependency or over-scoped server does not grant the process the authority to escalate privileges beyond the defined sandbox boundaries. Implementing these controls allows for the secure integration of third-party servers without necessitating a manual review of every network call site or binary contained within the package.

Beyond the architectural risks associated with process privileges, engineers must account for the “token context-tax” imposed by Model Context Protocol (MCP) servers. Every MCP server integrated into an agent workflow consumes a portion of the available context window for every request. This consumption is not uniform; tracking via tokenscope reveals a 544× variance in overhead, ranging from 35 to 19,054 tokens per request. In high-frequency agent loops, this overhead can silently inflate inference costs and degrade model performance by crowding out critical task data.

The total cost to your bottom line and context budget is a function of the aggregate capability surface and the volume of tokens required to maintain that connection. When evaluating MCP integrations, consider the following technical implications:

• Variable Footprint: Server-to-server overhead varies significantly; high-token requirements are often tied to verbose schema definitions or extensive tool metadata.
• Cumulative Cost: As agents trigger multiple servers in a single turn, these token counts aggregate, potentially exceeding the model’s optimal context range.
• Monitoring: Use tools like tokenscope to gain visibility into the per-request token tax, allowing for more accurate forecasting of latency and API spend.

It is essential to clarify that data derived from static source scans represents a lower bound on potential capability, not an indictment of malicious intent. The presence of network-call sites or environment variable access in a package does not confirm unauthorized behavior; rather, it quantifies the inherent capability surface you inherit upon deployment. Because these servers operate with the privileges of the host process, the operational standard should be to sandbox by default. By enforcing strict constraints on filesystem access, network egress, and secret exposure before connecting an MCP server to an agent, you transition from silent capability inheritance to an explicit, manageable security posture.