Trust Boundaries

The boundary map

Every arrow below crosses a trust boundary:

flowchart LR
U[User] <--> H[Host]
H <--> L[LLM]
H <--> C[Client] <--> S[Server] <--> E[External system<br/>API / DB / filesystem]

MCP trust boundaries

• User ↔ Host: the user trusts the host to act on their behalf and honor consent
• Host ↔ LLM: model output is untrusted — it may be manipulated via prompt injection
• Client ↔ Server: servers are third-party code; their tool descriptions and annotations are untrusted unless they come from a trusted server
• Server ↔ External systems: servers hold credentials and act with real-world side effects

Core principles

• Servers are untrusted by default — treat tool descriptions, annotations, and results as potentially adversarial content unless the server is trusted
• Servers receive only necessary context — a server cannot read the whole conversation or “see into” other servers
• The host is the policy enforcement point — the host enforces security policies and user consent, controls permissions, and maintains isolation between servers (clients also maintain security boundaries between servers)
• Model output is data, not commands — a tool call proposed by the LLM is a request; the host must obtain explicit user consent before invoking any tool

Caution

The protocol itself cannot enforce these principles — the spec says implementors SHOULD build robust consent and authorization flows. Trust boundaries are enforced by hosts and clients, not by MCP messages.

Local vs remote servers

Aspect	Local (stdio)	Remote (Streamable HTTP)
Runs as	Subprocess with your OS user’s privileges	Third-party service
Main risks	Supply chain (malicious package), broad filesystem access	Credential theft, data exfiltration, weak auth
Auth	Credentials from the environment (OAuth is not used over stdio)	OAuth 2.1-based authorization

Tip

The spec’s guidance: HTTP-based transports SHOULD conform to the OAuth 2.1 authorization spec; stdio transports SHOULD NOT use it and should retrieve credentials from the environment instead. For local servers, sandboxing is recommended and one-click install flows must show the exact command and require explicit approval.

Key exam points

• Anything a server sends (including tool descriptions) can carry injected instructions
• Isolation between servers is a host responsibility
• Remote servers require authentication; MCP specifies OAuth 2.1-based authorization for HTTP transports (authorization is optional in the protocol, but HTTP servers SHOULD support it)
• An MCP server must never forward tokens it receives to downstream APIs — token passthrough is explicitly forbidden

Check your knowledge

📝 Check your knowledge

1. Why are tool descriptions considered untrusted input?

AThey are compressed and may decode incorrectlyBThey come from third-party server code and can carry injected instructionsCThe spec requires them to be emptyDThey are generated by the LLM

2. Which component is responsible for isolating one server's data from another?

AThe server itselfBThe LLMCThe hostDThe external API

3. How should a tool call proposed by the LLM be treated?

AAs a command to execute immediatelyBAs a request subject to host policy and explicit user consentCAs trusted because it came from the modelDAs a server-side error

4. What does the MCP spec say about authorization on stdio transports?

AThey MUST implement OAuth 2.1BThey SHOULD NOT use the OAuth authorization spec and should retrieve credentials from the environmentCThey must use session cookiesDThey require Dynamic Client Registration

5. An MCP server receives a bearer token from its client and forwards it to a downstream API. What is this?

AA recommended pattern for single sign-onBToken passthrough — an explicitly forbidden anti-patternCRequired by RFC 8707DOnly allowed for local servers