Secure MCP Trust Boundaries

Treat every server as a separate supply-chain and data decision

Before connecting, identify the server operator, code or service provenance, transport, data destinations, retention terms, update path, and incident contact. An official-looking tool name is not evidence of ownership or safe behavior.

Inventory what context the model can send, what data the server can return, and what external actions it can perform. Reapprove when ownership, URL, tool inventory, scopes, or behavior changes.

Prompt injection can arrive through tools and resources

A server can return text that tells the model to reveal secrets, call another tool, ignore policy, or hide activity. Keep server content in a data channel, label provenance, minimize what reaches the model, and prevent returned text from changing permissions.

Review inputs and outputs at consequential boundaries. Redact secrets before model or server exposure, validate structured results, and require new authorization when output proposes a different target or action.

Bind tokens to the intended server and user decision

For protected HTTP servers, use the MCP authorization flow and established OAuth libraries. Validate issuer, signature, expiration, audience, scopes, and the resource being accessed. Never accept an upstream token and pass it through without validating that it was issued for this MCP server.

A proxy that acts for many clients can become a confused deputy. Preserve per-client consent, validate redirect URIs and state, and show the user the requesting client, target service, and requested scopes before authorization.

Authorization decision

text

verify TLS + server identity
verify token signature, issuer, expiry, audience
resolve subject + tenant + requested resource
require minimal scopes for this operation
bind consent to client, server, scopes, and redirect
reject passthrough, wildcard scope, or mismatched audience

Expose less and approve at the point of impact

Start with read-only discovery or the smallest baseline scope. Elevate only for a concrete operation, accept down-scoped tokens, separate administrative tools, and expire temporary access. Allowlists reduce accidental exposure but still require per-call authorization.

The confirmation surface should display the server, tool, resolved target, arguments or data being sent, side effect, and requested scope. Default to approval for sensitive data, external writes, money, permission changes, and destructive actions.

Detect change and preserve recovery evidence

Record server identity, negotiated protocol, tool-list digest, scope, approval decision, sanitized request, result class, postcondition, and correlation ID. Alert on new or changed tools, authorization failures, repeated denials, unusual data volume, or changed destination.

On suspected compromise, stop the connection, revoke or rotate credentials, invalidate sessions, preserve secret-safe evidence, assess downstream effects, and require explicit review before reconnecting. Do not let a model decide that an incident is harmless.

Practice activity

Threat-model and harden an MCP connection

Create a data-flow diagram for one MCP server showing host, client, server, authorization service, downstream API, model context, and user approval.
Inspect the requested tools and scopes, then remove every capability not required for the selected workflow.
Run scenarios for prompt-injected output, mismatched token audience, confused-deputy consent, wildcard scope, an unannounced tool change, and timeout after a write.
Define prevent, detect, contain, recover, and evidence requirements for each scenario.

What to produce

A trust-boundary diagram and least-privilege permission manifest with explicit approval rules.
Six security scenario records containing expected rejection or containment, audit fields, postcondition checks, and recovery.

Reflect before continuing

Which permission was convenient for setup but unjustified for the actual learner workflow?

You will be able to

Treat every server as a separate supply-chain and data decision

Prompt injection can arrive through tools and resources

Bind tokens to the intended server and user decision

Expose less and approve at the point of impact

Detect change and preserve recovery evidence

Threat-model and harden an MCP connection

What to produce

Reflect before continuing

Sources and verification

Make it stick.