MCP Server Security Checklist for Remote and Local Deployments

MCP security is the discipline of limiting what an AI client can discover, read, change, and cause a server to do. A secure deployment combines transport security, authorization, least privilege, input validation, outbound request controls, prompt-injection defenses, telemetry privacy, and an auditable trail of tool use.

Start with the threat model

• Who can connect to the server?
• Which users, agents, or tenants can access each tool?
• Which tools read sensitive data or change state?
• Can tool arguments cause server-side requests to arbitrary destinations?
• Can untrusted content influence a later tool call?
• What evidence will you need to investigate misuse or a mistaken action?

Remote authorization

For HTTP-based remote servers, follow the MCP authorization flow and the OAuth security model applicable to your deployment. Validate protected-resource metadata, authorization-server discovery, issuer and audience, scopes, redirect URIs, state, and PKCE. Return the correct distinction between unauthenticated and unauthorized requests.

Never use token passthrough

Token passthrough means accepting a token from the client without validating that it was issued for the MCP server and forwarding it to a downstream API. It breaks trust boundaries, weakens accountability, and can let a server act as a confused deputy. Validate the inbound token for the MCP resource, then use a separately issued downstream credential when the architecture requires one.

Local and stdio deployments

Local servers still need a threat model. Treat the process environment, package dependencies, filesystem, subprocesses, and network access as part of the security boundary. Do not assume that a server is safe because it runs on a developer laptop. Review installation commands, package provenance, requested permissions, and any ability to execute shell commands or access files.

Least privilege at the tool level

• Separate read from write and destructive operations.
• Use narrow scopes and tenant boundaries.
• Require confirmation for irreversible or high-impact actions.
• Make dangerous behavior explicit in the tool name and description.
• Use idempotency keys and audit identifiers for state-changing operations.
• Do not expose an entire backend API when an agent needs only a small safe subset.

Prompt injection and untrusted content

A resource, document, web page, issue, or tool result may contain instructions that are not authorized by the user. Treat retrieved content as data, not policy. Keep authorization decisions outside model-generated text, validate tool arguments independently, and require explicit approval for actions with material side effects.

SSRF and outbound requests

Any tool that fetches a URL, calls an integration, or follows user-provided destinations can become a server-side request forgery path. Prefer allowlists, block private-network ranges where appropriate, validate redirects, limit protocols and ports, and enforce network-level egress controls.

Privacy-preserving telemetry

Auditability does not require collecting everything. Record who or what called a tool, which tool and version was used, the outcome class, timing, authorization context, and a correlation identifier. Redact credentials, personal data, and sensitive content before transmission. Document retention and access for operators.

Security review questions

• Can an untrusted client enumerate tools it should not know about?
• Can a read-only identity invoke a write or destructive tool?
• Can a token issued for another service be accepted here?
• Can a tool reach internal metadata services or private network hosts?
• Can the agent cause the server to forward raw credentials downstream?
• Can operators reconstruct a high-impact action without exposing raw secrets?

Frequently asked questions