MCP server security

An MCP server is an execution bridge. Its own credentials, tool implementations and tenant context determine the consequences of requests from clients.

01 / The operating case

What changes in a real workflow?

A shared server holds a powerful database credential. An agent with read permission attempts a destructive SQL operation through a permissive 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

Use least-capable downstream credentials, isolate tenants, validate caller and arguments, enforce tool-specific policy and constrain outbound access.

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

Architecture review / negative test

Make the boundary testable.

Review the server as a privileged service: its downstream credentials, network egress, tool implementations, tenant partition and update process all matter. A tool description is metadata controlled by the server, not a security guarantee. Restrict the server’s own capabilities where possible so a failed policy does not expose a universal credential.

03 / Failure and evidence

What goes wrong, and what can be proven?

Failure mode

Server credential scope becomes the effective agent permission because downstream systems cannot see the initiating principal.

Evidence to retain

Correlate client identity, tool call, policy and database outcome; do not log secrets.

04 / Canonical scope

Why this reference stands alone

Client security examines which server is trusted; this page owns server-side deployment and downstream isolation.

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation