MCP client security

A client decides which servers to contact and which server-provided content enters the agent context.

01 / The operating case

What changes in a real workflow?

A desktop agent is asked to connect to a lookalike accounting server that offers a plausible invoice-search tool.

Trace the authority boundary
  1. 01Client / task
  2. 02MCP server
  3. 03Tool call + arguments
  4. 04Downstream effect

02 / Decision contract

What the executor must check

Pin the expected server identity and transport, review the operator and requested scopes, and keep tool descriptions and results in a lower-trust data channel.

InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

A valid connection to the wrong server makes malicious instructions and data collection look like normal tool use.

Evidence to retain

Record server identity, approved configuration, tool-definition version, scope grant and blocked outbound action.

04 / Canonical scope

Why this reference stands alone

Server security owns the provider side; this page owns client-side trust admission.

Protocol or attack trace

Server-admission test

Sequence

Approved client configuration names server origin S and expected operator O. A lookalike server S2 advertises the same search tool and requests a broader scope.

Negative test

Connect to S2 with an otherwise valid OAuth flow; client must refuse or require fresh trusted admission before sending data.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation