A developer wants to try a community MCP server from an unknown publisher on a laptop that holds SSH keys and cloud credentials. The server only needs to read one project folder. Which approach best limits the damage if the server turns out to be malicious?
Select an answer to reveal the explanation.
Short Explanation
You don't let a stranger crash in your house and just hope they stay in the guest room — you give them a locked room with one box in it. A container with one mounted folder and no outbound network is that room. The stdio pipe is a conversation channel, not a wall.
Full Explanation
MCP's local server security guidance calls process isolation the single highest-leverage mitigation: run third-party servers in a container, sandbox or virtual machine with no mounts beyond what the server needs, and deny network egress where none is required or filter it to expected destinations. That turns a server that could read SSH keys and cloud credentials into one that can see only an empty filesystem plus the chosen folder, and it protects the user even when provenance checks fail. The stdio transport is not a sandbox; the guidance states that a client and a stdio server share one trust domain, and a launched server already runs as an ordinary child process with the user's privileges. Tool approval prompts govern what the model asks a server to do, but a malicious server can read files and exfiltrate data on its own initiative at startup without any tool being called. A configuration-level allowlist is a cooperative boundary that a well-behaved server respects; nothing in the protocol stops a malicious server from ignoring it. Exam caveat: a container is not impenetrable, but it removes default access to the environment, files and keychain that common attacks rely on. Operational check: inside the container, confirm the home directory is absent and an outbound request to an unexpected host fails.