Transport, auth, and trust

A transport carries MCP messages between a client and server. Local process communication and remote network communication have different setup, failure, and security properties. Use transport mechanisms supported by the current MCP specification and maintained SDKs rather than relying on old examples whose transport guidance may have changed.

For a local process, the host may launch a configured command and communicate through standard input and output. Process arguments, environment variables, working directory, executable path, and operating-system permissions become part of the security boundary. Protocol output and diagnostic logs must use their intended channels so that logging does not corrupt communication.

For a remote service, network confidentiality, server identity, origin checks, session handling, and authentication become central. A reachable URL is not proof that the endpoint is the intended server. Deployment should use the security guidance for the current remote transport and the organization's network controls.

Transport answers how messages move. It does not answer whether a requested operation is allowed.

Authentication establishes who or what is making a request. Authorization determines what that identity may do. A valid login can still lack permission to read a payroll document or create an issue in a protected project.

MCP standardization does not grant authority over the underlying service. A server wrapping a calendar API still needs approved credentials and must respect calendar permissions. Depending on the architecture, the server may act as the end user through delegated authorization, use a narrowly scoped service identity, or combine identity and policy in another approved design.

Never treat model-provided text as identity evidence. An argument such as "user": "chief-executive" is data, not authentication. Identity should come from the trusted connection and application context, then be checked server-side.

Credentials should be scoped, stored outside prompts, rotated, and withheld from tool output. A model usually needs the ability to propose an operation, not possession of the bearer token that authorizes it.

Authentication answers who the user is, but it does not prove the user intended this particular action. The host owns the consent experience because it can show the person what will happen in context.

Consent should be meaningful. For a destructive or externally visible action, display the target, important arguments, expected side effect, and which connected server will execute it. Avoid vague dialogs such as “Allow tool?” that train users to click through.

Consent can be scoped. A user might allow read-only search for the current session but require confirmation for every send, publish, or delete. The host should not let a server prompt or tool description decide its own approval policy.

Some operations may be forbidden regardless of consent because organizational policy or law disallows them. A confirmation button is not a substitute for authorization, data governance, or professional review.

For each connection, draw boundaries around:

• the person and host interface;
• the model provider or model runtime;
• the MCP client and transport;
• the MCP server process or service;
• the downstream API, database, or filesystem;
• logs, caches, and monitoring systems.

At every boundary, ask what data crosses, which identity applies, who can modify the component, and how failure is contained. Conversation text sent to a remote server may leave the model provider's boundary and enter another processor's boundary. Tool output returned to the model travels in the opposite direction.

Trust is not transitive. Trusting the host vendor does not automatically establish trust in every configured server. Trusting a server operator does not make every document it retrieves safe to interpret as an instruction.

The host should expose only the capabilities needed for the current product and task. If a server offers fifty tools but the feature needs two read operations, filter to those two. Narrow model choice reduces accidental and adversarial paths.

The server should use credentials and runtime permissions limited to its job. A repository-reading server does not need home-directory access. A documentation search server does not need document deletion. Server-side allowlists should restrict provider projects, folders, or operations where feasible.

Argument validation and output limits further reduce reach. Validate identifiers against authorized scopes rather than concatenating model text into paths or queries. Limit response size and content types before returning data.

Least privilege should survive compromise of one layer. If a malicious document convinces the model to call an available tool, host policy should block irrelevant actions. If host policy has a bug, the server and downstream service should still reject unauthorized access.

Installing a local server means running software. Review its source or publisher, pin and verify dependencies according to organizational practice, inspect requested permissions, and define how updates are approved. Configuration examples copied from the internet may include broad filesystem mounts or environment access.

Remote servers also change over time. Track the endpoint owner, terms, data handling, version behavior, and incident contact. Detect unexpected capability changes; a server that suddenly advertises a new write tool should not gain model exposure automatically.

Content is another supply chain. Results can contain malicious or misleading instructions. Preserve provenance, separate data from trusted instructions, and avoid giving retrieved text authority merely because it arrived through a standardized protocol.

Security review should be proportional to reach. A local weather server with no secrets and read-only public data differs from a production operations server that can deploy code. Both use MCP; their threat models should not be identical.