A user installs a third-party MCP server that the client launches locally over stdio without any sandbox. What can that server process reach by default?
Select an answer to reveal the explanation.
Short Explanation
A stdio server isn't a guest in a sealed room; it's a program running as you. Whatever your account can touch, it can touch. The trap is thinking the transport or roots draw a fence, when only a sandbox you add does.
Full Explanation
With stdio, the client launches the server as a subprocess and they exchange newline-delimited JSON-RPC over stdin and stdout. MCP's local server guidance stresses that the client and a stdio server share one trust domain: they run side by side with the same privileges, neither the protocol nor the SDKs defend one against the other, and the stdio transport is not a sandbox. The security best practices likewise warn that MCP servers run with the same privileges as the client and recommend sandboxed execution with minimal default privileges, restricted file system and network access, and explicit grants when more is needed. Without a sandbox the server can read the user's files, open network connections and read environment variables, including any secrets placed there. Saying roots confine the server fails because roots are informational, not enforced, and deprecated in this revision. Saying stdio sandboxes the process fails by concept: stdio only describes how messages travel; the process keeps full operating-system access. Saying annotations limit it fails because annotations are server-supplied hints, untrusted unless the server is trusted, and the host cannot enforce them on a process it does not contain. Exam caveat: decisions about provenance and isolation happen before launch. Operational check: run the server in a container with only the needed directory mounted and confirm reads elsewhere fail.