Systems labAdvanced115 min estimateOriginal publication

MCP Host, Client, and Server Boundaries

MCP standardizes context exchange; the host still owns which server connects, what context leaves, which capability is enabled, and whether one exact action may execute.

Authorship: InterviewsVector
Published / updated: 2026-09-21 / 2026-09-21
Review status: Artifact tests passing · primary sources recorded

Original InterviewsVector teaching. Executable artifacts are deterministic illustrative boundary checks covered by focused tests; they do not claim production authorization, protocol conformance, durability, memory quality, or safety certification.

The decision in one pass

Keep MCP protocol capability separate from application authority. The host owns server selection, connection lifecycle, user consent, authorization decisions, context aggregation, budgets, and the final policy gate. A client maintains the protocol relationship to one server and validates messages. A server advertises resources, prompts, and tools; its advertisement and descriptions are untrusted metadata, not permission. Pin a supported protocol version, server identity and origin, transport, capability allowlist, method, audience, exact delegated scopes, payload and timeout limits, and per-call consent binding. Validate both directions and expose only the minimum context. Passing a local host policy audit does not prove OAuth, transport, server, or MCP conformance.

Why this matters

A protocol can make integrations composable while also making remote descriptions and actions easy to route into a powerful model. If discovery becomes authorization, a compromised server can rename capabilities, request broad tokens, inject instructions through resources, or induce a host to act as a confused deputy across tenants and services.

You will be able to

Assign security and lifecycle responsibilities to the MCP host, client, and server without conflating them.
Separate capability negotiation and discovery from user consent and authenticated authorization.
Bind remote calls to protocol version, server origin, resource audience, attenuated scopes, payload, and per-call approval.
Validate server content and tool results as untrusted data before adding them to model context or state.
Operate version, transport, credential, timeout, cancellation, and audit boundaries explicitly.

Prerequisite contract

Your Vector Loop for this lab

01
Model
Draw host, per-server client, server, authorization service, model, user, data, and external side-effect boundaries.
02
Derive
Derive version, identity, origin, method, capability, audience, scope, consent, payload, timeout, and call-budget invariants.
03
Build
Build a content-addressed host policy and bind one exact proposal to attenuated authority.
04
Stress
Probe protocol downgrade, origin swap, token audience confusion, extra scopes, stale consent, malicious descriptions, oversized payloads, and constructor bypass.
05
Operate
Trace negotiation, policy, consent, request, cancellation, result validation, and credential rotation without logging bearer secrets.
06
Defend
Distinguish local policy checks from live MCP interoperability, OAuth correctness, server trust, and application safety.

Separate host, client, and server responsibilities

Component	Owns	Must not assume
host	connections, consent, authorization decisions, context aggregation, policy and UX	server discovery is safe to enable
client	one server relationship, negotiation, message routing, cancellation and protocol validation	the model grants credentials or consent
server	declared resources, prompts, tools, and their implementation	access to the full conversation or other servers
model	a probabilistic proposal among offered capabilities	authority to expand scopes, choose credentials, or approve itself

A host can run multiple clients, each isolated to a server relationship. The host decides what server content enters the conversation and what model proposal becomes a protocol request. That application policy remains necessary even when negotiation, JSON-RPC framing, and OAuth are standards-compliant.

Negotiate compatibility; authorize every effect

Protocol initialization establishes a mutually supported version and advertised capabilities. It does not establish that this user may invoke every tool or read every resource. Persist the negotiated protocol identity with the connection, reject unsupported downgrades, and intersect server capabilities with the host's reviewed policy before the model sees them.

01IdentifyResolve the configured server identity, transport, origin, and trust configuration outside model text.
02NegotiateAgree on one supported protocol version and capability set for the client-server relationship.
03FilterApply host allowlists, tenant policy, data classification, and product configuration.
04AuthorizeBind authenticated user, resource audience, minimum scopes, exact action, and current policy.
05ValidateCheck requests and responses before execution, persistence, rendering, or model-context insertion.

Bind credentials to the intended audience

For remote HTTP transports, authorization must follow the applicable MCP authorization specification and its OAuth security requirements. The host must not forward a token issued for another audience, accept arbitrary authorization-server metadata without validation, or pass its own broad service credential merely because a server requested it. Local-process transports have different credential and process-isolation risks; neither transport makes tool content trusted.

Threat	Boundary check	Evidence to retain
token passthrough	audience and issuer binding; no unrelated token forwarding	authorization metadata identity without bearer secret
server substitution	pinned configured server ID and origin	connection and certificate outcome
scope expansion	delegated scopes equal the reviewed minimum set	requested, granted, and consumed scope names
prompt injection	label server text as untrusted data and restrict downstream effects	content source and policy decision
cross-server leakage	one client relationship and minimum context per server	which context fields were disclosed

Find the first host invariant that fails

The interactive holds one illustrative host policy fixed while changing a proposal's server identity, method, audience, delegated scopes, consent binding, payload, timeout, or call index. Predict the first denial. Passing the exercise says nothing about a live server or OAuth implementation.

Keep MCP authority in the host

Trace an illustrative host, client, and server exchange, then predict which proposals the host must deny for identity, audience, scope, consent, payload, or budget mismatch. No live server or OAuth flow runs.

Keep MCP capability separate from host authority

Trace one synthetic MCP exchange across server, client, host, and model. Protocol capability says what can be requested; the host still owns user consent, scope, validation, and disclosure.

Protocol trace

Server advertises a new write toolCapability discovery changed after the user's prior read-only grant.Filesystem request escapes the granted rootThe method is valid but its path exceeds the user's scope.Tool result contains an instructionA remote resource tells the model to upload local credentials.Granted calendar readCapability, arguments, tenant, and consent all match.

Illustrative protocol records only. Accounts, roots, grants, and method revisions are invented and trigger no external action.

MCP role and authority evidence
Boundary	Contract	Observed
Server	Advertise protocol capabilities and schemas	tools/list now includes calendar.delete
Client	Transport typed protocol messages	Schema parsed successfully
Host	Expose only user-granted capabilities	Existing grant covers calendar.read only
Model	May propose only; cannot create authority	Planner requests calendar.delete

What should the host do next?

Require a new explicit host grantDeny at the host authority boundaryTreat the result as untrusted data onlyDispatch the already granted read

Select a prediction, then check it against the current evidence.

Run the host authority contract

The artifact freezes one remote-server host policy, content-addresses it, copies caller-owned collections, reconstructs nested records, rejects string subclasses, bool-as-number values, non-finite timeouts, malformed origins, duplicate scopes, and constructor bypass, then checks protocol, host/client/server identity, method, capability, audience, exact delegated scopes, canonical payload bytes and digest, per-call consent, timeout, and call budget. It opens no connection and validates no OAuth token.

mcp_boundary_audit.py

1def main() -> None:
2    print(format_example())

Expected output

example=illustrative_only
contract_id=mcp-host-contract@sha256:da4f24595c1474925e5079d45ccbc0cea5d51a7498e2f78ffac352f910042c3d
protocol=2026-07-28
host=academy_host
client=academy_calendar_client
server=calendar_mcp_server
capability=create_draft_event
transport=streamable_http
delegated_scopes=calendar:drafts:write
consent=HOST_BOUND_TO_CALL
decision=ALLOW
claim=LOCAL_HOST_POLICY_CHECK_ONLY
certification=NOT_MCP_OR_OAUTH_CONFORMANCE

Verify: python3 -m unittest discover courses/ai-engineering/reference-impl/mcp_boundaries

Observe each connection and authority decision

Trace configured server identity, resolved origin, transport, negotiated protocol, advertised and host-enabled capabilities, authorization audience and scopes, consent identity, request ID, payload digest, timeout, cancellation, response validation, and final effect outcome. Rotate credentials without putting bearer values in logs. Alert on version downgrade, origin drift, capability churn, repeated denials, cross-server context attempts, oversized messages, stuck requests, and unknown outcomes.

Operate at three altitudes

Production lens

— Keep a reviewed server registry with origin, transport, protocol versions, owner, data classes, capability allowlist, and credential audience.
— Create one isolated client relationship per server and disclose only the context and scopes required for the exact enabled capability.
— Validate server messages and results before model-context insertion, persistence, rendering, or downstream execution.

Staff lens

— Treat adding an MCP server as a supply-chain and data-flow change, not merely a developer configuration edit.
— Standardize consent receipts and authority traces across protocol clients while allowing product-specific risk thresholds.
— Require separate evidence for MCP interoperability, OAuth security, server trust, tool correctness, and application safety.

Interview defense

Your product connects to third-party MCP servers. Where do consent and authorization live, and how do you prevent a server or model from expanding authority?

The host owns configured server trust, client lifecycle, consent, authorization decisions, context aggregation, and the final policy gate. Each client has one server relationship and validates the negotiated version and messages. The server advertises capabilities, but I intersect them with a reviewed host allowlist before model exposure. For each call I bind server ID and origin, method, capability, resource audience, exact minimum scopes, payload limits, timeout, budget, and per-call consent to the request. Server content stays untrusted with provenance. Tokens are audience-bound and never passed through from another service. I trace cancellations and unknown outcomes separately; a local policy pass is not MCP, OAuth, or server-safety certification.

Expect the interviewer to press on

— Why does capability negotiation not authorize a tool?
— How does token audience prevent confused-deputy behavior?
— What must change when a server's origin or capability schema changes?

Misconceptions to remove

“An MCP server's advertised tool is safe because the protocol discovered it.”

Discovery reports availability. The host must independently allowlist, authorize, obtain consent, validate, budget, and observe the exact action.

“The model can decide whether a user consented.”

Consent is a host-controlled authenticated interaction bound to the displayed effect and exact request, not a generated assertion.

“Successful MCP conformance proves the integration is secure.”

Conformance does not prove trustworthy server behavior, correct OAuth deployment, least privilege, safe content, or product-specific authorization.

Check your model

1. Who decides which server-provided capabilities the model may see?

The host, by intersecting negotiated server capabilities with configured product, tenant, user, data, and risk policy.

2. Why require an exact token audience?

So a credential issued for one resource server cannot be forwarded to or redeemed by a different server as ambient authority.

3. Does cancelling an MCP request prove no external write occurred?

No. Cancellation is a request to stop work; the host still needs typed outcomes, idempotency, reconciliation, and possibly compensation.

Prove the mechanism

Write a host policy for an MCP calendar server that can read availability and create drafts but never send invitations. Bind server origin, protocol, methods, audience, scopes, consent, context disclosure, payload, timeout, cancellation, and audit evidence.

Add a production constraint

Design a safe migration between two MCP protocol versions and a rotated authorization issuer. Include capability diffs, dual compatibility, origin and audience binding, staged clients, consent continuity, downgrade rejection, rollback, and evidence for final contraction.

Artifact: MCP host authority contract

courses/ai-engineering/reference-impl/mcp_boundaries/mcp_boundary_audit.py

Download reference implementation

Primary references and next links

References

1. MCP architecture
Model Context Protocol. Normative host, client, server, isolation, consent, and security-boundary responsibilities.
2. MCP authorization
Model Context Protocol. Normative authorization requirements for HTTP-based MCP transports; the artifact does not implement OAuth.
3. MCP authorization security considerations
Model Context Protocol. Normative security guidance for audience, trust, and confused-deputy boundaries.
4. MCP tools
Model Context Protocol. Normative tool discovery and invocation contract; availability is distinct from host authority.

Continue through the graph

Tools Are Typed Authority Boundaries →
Apply typed effect, scope, approval, idempotency, and result contracts to MCP tools.
Agent Red-Team: Untrusted Instructions Meet Real Tools →
Stress server content, tool descriptions, and results as injection and confused-deputy inputs.

Glossary: Model Context Protocol · host · client · server · capability negotiation · resource audience · confused deputy · consent binding