A local MCP server needs a single API token, but the user's shell profile exports cloud credentials and several other tokens, all of which the launched process can inherit. What is the best way to reduce this exposure?
Select an answer to reveal the explanation.
Short Explanation
Exporting every secret in your shell profile is like taping all your keys to the front door. You hand this server its one narrowly scoped key through its own config and nothing else. Trusting the README isn't a control, and stdio servers don't do OAuth.
Full Explanation
The local server security guidance notes that a locally launched server may inherit the environment of whatever launched it, so globally exported cloud credentials and tokens are readable by every server. Its credential isolation advice is to pass secrets per server through the client's per-server environment configuration, to scope each token narrowly so a leak is contained and revocable, and to keep long-lived secrets in an operating system secret store where the client supports it. Trusting documentation that a server reads only one variable is no control at all; a malicious or compromised server reads whatever its process can reach. Form-mode elicitation is forbidden for secrets such as API keys, and it would route the token through the client rather than isolating it. The authorization specification applies to HTTP transports; stdio implementations SHOULD NOT follow it and instead retrieve credentials from the environment, which is exactly why that environment must be kept minimal. Exam caveat: credential files such as ~/.ssh and ~/.aws are credentials too, and only process isolation keeps them out of reach. Operational check: print the environment the host passes to the server process and confirm it contains only the one scoped token plus required system variables.