Knowledge & actions · Explore this field ↗ · Security · 3 min read
MCP tool trust boundaries: protocol connection is not permission
Use Model Context Protocol tools without mistaking discovery metadata, tool descriptions, or a connected server for a blanket grant of trust.
See the source / a related case
Name the actors before designing the UI
MCP distinguishes host applications, clients inside those hosts, and servers that expose resources, prompts or tools. That topology is helpful because it prevents an easy mistake: the model does not own the authorization relationship. The host is responsible for deciding which server is connected, what context leaves the host, which tools are exposed, and what a user must review. Keep an inventory for every connection: server identity and transport, owner, version, requested capabilities, data classes, credential source, allowed environments and revocation method. A tool list is an interface discovery result, not a security approval.
Tool descriptions are not policy
The MCP tools specification says tools are model-controlled, but also advises that a human should be able to deny invocations and that applications should make tool use clear. It further says clients must consider annotations untrusted unless they come from trusted servers. Apply that caution to names, titles, prose descriptions, schemas and results from any server outside your trust boundary. A friendly label such as ‘summarize invoice’ must not give the tool access to all mail, uploads or account records. Write host-side policy in stable terms: allowed server, action class, authenticated subject, approved fields, recipient constraints, rate limit and confirmation rule.
Ask for consent at the useful moment
Consent should be specific enough for a user to understand the data and action, not buried in connection setup. Before a sensitive read, show the server and the data category to be shared. Before a write, show the exact structured inputs, destination and expected consequence. Keep a deny path that does not punish the user with a broken conversation. For repeated low-risk actions, a scoped preference can reduce friction, but it should be visible, revocable and narrower than a permanent ‘trust this server’ switch. Separately record administrator approval for servers that are permitted in an organization at all.
Bind credentials to the intended server
The MCP authorization specification describes protected MCP servers as OAuth resource servers and requires resource-aware authorization behavior. It calls for clients to include the resource parameter in authorization and token requests, and for servers to validate that a presented token was issued for them. Preserve that boundary in implementation: do not pass a token obtained for one server through another server, do not put secrets in model context, use secure storage, and make reauthorization and revocation observable. A correct protocol flow does not substitute for deciding whether the user should be allowed to perform the underlying business action.
Constrain capability changes
A server can advertise changes to available tools. Treat a newly listed or materially changed tool as a new capability review, not as an automatic extension of a prior consent grant. Pin or review server versions where the environment supports it, show changed permissions to operators, and fail safely if a known schema becomes incompatible. For production actions, put a typed host-side adapter between the model and the MCP call so policy validation and audit logging do not depend on a prose tool description. Test disconnect, token expiry, server error, unexpected content type and cancellation before release.
MCP does not settle governance
The protocol provides interoperability mechanisms and security guidance; it cannot know an organization’s data classification, contract terms, legal duties or approval thresholds. A server marked trusted is a local governance decision that should have an owner and review interval. Keep the public claim limited to what the host actually mediates and logs, and revisit it as MCP versions and connected services evolve.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.