A local MCP server runs on your machine with the same privileges as the client that started it. Before you run one, read the exact startup command, then launch it in a sandbox with limited file and network access. Prefer the stdio transport so only the client can talk to it.
Why local servers are risky
The MCP security best practices describe local servers as binaries you download and execute, author yourself, or install through a client's configuration flow. They can reach your files, and other processes on the machine may be able to reach them.
The specification names three attacks: a malicious startup command placed in a client configuration, a malicious payload inside the server itself, and an insecure server left running on localhost that a website reaches through DNS rebinding.
The example it gives of a bad startup command is an npx call chained to a curl that posts your SSH key somewhere else. Nothing about it looks unusual in a config file unless you read the whole line.
Step 1: read the full command
Clients that offer one click setup must show the exact command, without truncation, and ask for approval. If yours truncates, open the config file and read it yourself. Look for chained commands, sudo, rm -rf, network calls and paths in your home directory or .ssh.
Step 2: reduce what the process can touch
The specification recommends running the server with minimal default privileges and restricted access to the file system, network and other resources. In practice that can mean:
- A container with only the project directory mounted, read only where possible.
- A separate operating system user with no access to your home directory.
- No outbound network unless the server needs a specific host.
- No environment variables beyond the ones the server needs. Passing your whole shell environment hands over every token in it.
Pick the platform appropriate tool, such as containers or application sandboxes, and keep it updated.
Step 3: choose the transport on purpose
The specification says servers meant to run locally should use stdio, which limits access to the client that launched the process. If you need HTTP, require an authorization token or use a Unix domain socket with restricted access. Streamable HTTP servers must validate the Origin header and should bind to 127.0.0.1, not 0.0.0.0.
Step 4: log what happens
Clients should log tool usage for audit. Keep those logs somewhere the server cannot edit.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard includes an MCP Guardrail and dependency scanning. Scanning the packages a server pulls in is a sensible first filter before you sandbox it, though a clean scan does not replace the sandbox.
Quick check
Is stdio safe by itself?
The specification says stdio is not inherently vulnerable, but the server still runs with your privileges. It limits who can connect, not what the server can do once it runs.
What is the single most useful habit?
Read the full startup command before approving it. Most of the described attacks hide in that line.
Sources
Last reviewed: 19 October 2026.
