How would you set a trust policy for locally launched MCP servers, given the protocol enforces nothing?

## The first move: name the real boundary The question sounds like an MCP question and is really a software-supply-chain question. When a host launches a stdio server it starts a subprocess, on the user's machine, under the user's account, with the user's file access and network access. Everything MCP has to say — tools, resources, prompts, `_meta`, error codes, annotations, consent prompts — describes the *protocol channel* between host and that process. It says nothing about what the process does with the privileges it already has. So the strongest opening in an interview is to separate two threats. There is in-channel risk: what the server asks the host to do through the protocol, which the host's consent model governs. And there is out-of-channel risk: what the process does on its own, which the host's consent model cannot touch at all. A policy that only addresses the first is a policy about the smaller half. ## What the specification actually gives you On the client side, the guidance for locally launched servers is short and worth quoting accurately rather than inflating: obtain user consent before configuring and launching a server, and run it with restricted privileges — sandboxing where the platform supports it. That is real guidance and it belongs to the client/host. What the specification does **not** give you is any of the granularity people assume. Allow-once versus always-allow, how long an approval lasts, whether a mutating tool needs a separate confirmation, whether an approval should be re-confirmed after an update — none of these are protocol requirements. They are host UX decisions. A candidate who says "the spec requires re-confirmation for destructive tools" has invented a MUST. Note too that in 2026-07-28 the security best-practices document moved out of the specification into the documentation tutorials, so the normative surface is smaller than the written-material surface. One structural guarantee is useful when designing re-prompt rules: a server's tool, prompt and resource set MUST NOT vary per connection, though it MAY vary with the authorization presented. That means a surface change under the same authorization is a genuine change to what was approved, not connection noise — a sound trigger for re-confirmation, chosen by you rather than mandated. ## The axes a real policy sets **Who may add a server.** The single highest-leverage control. A curated catalogue of vetted servers moves the trust decision from every individual user to a team that can actually evaluate it; unrestricted user-added servers push a supply-chain decision onto people doing something else at the time. The cost of curation is friction and a queue, and the honest tradeoff is that friction pushes determined users toward unmanaged tooling — so the catalogue has to be fast enough to be the easy path. **Provenance and change.** Which artefact, from which registry, pinned how, updated by whom. A server that silently updates itself has an approval that means less every day. This is ordinary dependency governance, and it applies here because an MCP server is a dependency that executes. **Blast radius.** What the subprocess can reach: filesystem scope, network egress, credentials present in its environment. Containerisation or an OS sandbox turns "trust the author" into "bound the damage", which is a far better position because it degrades gracefully when trust turns out to be misplaced. **Data classes to server identities.** The privacy half: which categories of user data may be placed in arguments to which servers. This is the policy the host's consent surface has to be able to express; if it can only ask "run this tool?" then the data question is never asked at all. **Prompt design and fatigue.** The uncomfortable truth is that a consent prompt on every call produces reflexive approval, which is worse than a smaller number of meaningful prompts. Design for a small set of decisions the user can actually reason about, and reserve interruption for changes: new server, changed surface, escalation from read-only to mutating, a data class not previously approved. ## Local versus remote is a different posture For a remote server there is enforceable machinery: OAuth 2.1 with mandatory PKCE, audience-bound tokens so a token cannot be replayed at another resource, no token passthrough, and step-up via `403` with `insufficient_scope`. Access can be scoped and revoked centrally. For a local subprocess there is no token and no revocation — you either did not launch it or you did. That asymmetry should show up in the policy: local servers deserve stricter admission control precisely because there is nothing to fall back on afterwards. ## How to close the answer Say what you would measure and how you would know the policy is working: the number of distinct servers in use, how many were added outside the catalogue, whether approvals are ever re-examined, and whether any incident review has ever traced a data exposure to a server nobody remembered configuring. And be honest about the residual: MCP cannot enforce its principles at the protocol level, so what remains is admission control, sandboxing, and the trust you place in an operator — the same materials every other dependency decision is made from.