Say what isolation actually applies to local MCP servers: container or application sandbox, restricted file system and network access, and a consent step before a new server runs. If servers run directly on laptops with full user privileges, say that and describe the compensating controls.
What the specification says about local servers
The MCP security guidance describes local servers as binaries downloaded and executed on the same machine as the client, which may have direct access to the user's system. It lists three attacks: a malicious startup command in a client configuration, a malicious payload inside the server itself, and an insecure local server reachable through DNS rebinding. Its mitigations include warning users that servers run with the client's privileges, running server commands in a sandbox with minimal default privileges, restricting file system and network access, and letting users grant extra privileges explicitly.
A reviewer who has read this will ask which mitigations you applied.
Describe your position honestly
| Position | How to say it |
|---|---|
| Servers run in containers with limited mounts | "Approved servers run in containers with read only mounts for named directories and an egress allowlist." |
| Application level sandbox | "The client runs servers under an operating system sandbox profile that limits file and network access." |
| No sandbox yet | "Servers run with user privileges. We limit risk through an allowlist, consent prompts and credential scoping, and sandboxing is planned." |
All three are acceptable if true. The first two score higher, but a clear third answer beats a vague claim of isolation.
Compensating controls when there is no sandbox
- Allowlist. Only approved servers, from known sources, in a managed config.
- Consent. The client shows the exact command and requires approval. The specification says clients with one-click setup must do this without truncating the command.
- Scoped credentials. The token a local server holds is narrow and short lived, so a compromise reaches less.
- Endpoint hygiene. Laptops are managed, patched and have disk encryption.
- Localhost binding. Servers listen only on the loopback interface.
For more, see how to sandbox local MCP servers before you run them and the Origin header and DNS rebinding.
Questions that follow
- What can the server read? Name directories.
- Can it reach the internet? To which hosts?
- Who built it, and how do you know the package is what it claims to be?
- How do you update it?
The last two are supply chain questions. Package provenance helps but does not prove a server is safe, so say what else you check.
Sample wording
"Approved local MCP servers run in containers with read only access to named project directories and an outbound allowlist. New servers need security approval and the client shows the full launch command before first run. Tokens used by local servers are per user and scoped to the minimum needed."
Evidence
The container or sandbox profile, the egress rules and the approval record for one server. Safeguard helps with SBOM and dependency scanning of server packages and with asset discovery to find which servers exist.
Quick check
Is a container a sandbox?
It is a form of isolation, but only as strong as its mounts, capabilities and network rules. Say what you restrict, not just that you use a container.
Do remote servers need sandboxing?
Not on your side, but you should ask the provider how it isolates tenants. See the separate checklist for remote servers.
Sources
Last reviewed: 19 October 2026.
