Review the server before the model can use it.

Quick readiness check

Use this first pass before installation, connection or approval. A “yes” answer means the control has evidence behind it; it does not prove the server is safe.

• Source: Do you know who publishes the server and what code/package will run?
• Dependencies: Have install scripts, manifests and important dependencies been reviewed before execution?
• Authorization: Are tokens validated for the MCP server rather than blindly passed downstream?
• Scopes: Are API, OAuth, filesystem and network permissions limited to what the server actually needs?
• Tools: Are tool descriptions, schemas, arguments and return values treated as untrusted input?
• Network: Are URL-fetching tools and OAuth discovery paths protected against SSRF?
• Runtime: Is a local server isolated from unnecessary filesystem, process and network access?
• State: Are server-issued state handles bound to the authenticated caller and difficult to guess?
• Secrets: Are credentials kept out of source, client-visible output and logs?
• Human control: Do destructive, financial or data-sharing actions require meaningful confirmation?
• Audit: Can you explain who called which tool, when, with privacy-safe evidence?
• Drift: Will material changes to tools, permissions, package identity or configuration trigger re-review?

1. Verify source, package and dependency provenance

An MCP server is software that may execute with access to valuable systems. Before running it, identify the repository or package source, publisher, expected executable or startup command, release history and the dependency/install surface you are accepting.

2. Keep authorization and token boundaries explicit

The MCP security guidance warns against confused-deputy behavior and token passthrough. A server should validate that a presented token was actually issued for that server/resource and should not accept an unrelated token simply because a downstream API might understand it.

• Validate token issuer, audience/resource and relevant claims before authorizing a request.
• Do not use possession of a downstream token as a substitute for MCP-layer authorization.
• Keep per-client consent and redirect handling explicit when the server proxies third-party authorization.
• Use PKCE and secure OAuth flows where the MCP authorization specification applies.
• Treat authorization as one control layer; it does not validate the safety of tool behavior.

3. Minimize permissions and blast radius

Grant only the permissions needed for the intended tools. The same server is materially different when it can read a project directory versus an entire home directory, or when it has a narrow read-only API scope versus broad write access.

• Use per-server or per-integration credentials rather than shared credentials.
• Prefer narrow OAuth/API scopes and step up only when a tool genuinely needs more authority.
• Restrict filesystem access to specific required directories.
• Disable outbound network access unless the server needs it.
• Separate highly sensitive capabilities from general-purpose servers where practical.

4. Treat tool schemas and arguments as a security boundary

Tool names, descriptions, parameter schemas and return values influence model-driven behavior. OWASP recommends treating the whole tool schema as an injection surface, not only the prose description.

• Use strict schemas: reject undeclared fields and validate type, range, format and length.
• Never pass model-produced text directly into a shell command, SQL statement or filesystem path.
• Normalize and validate paths before access; enforce an allowed root rather than filtering suspicious strings.
• Define server-side allowlists for dangerous or high-impact operations where possible.
• Review material tool-definition changes as a new security decision rather than silently inheriting approval.

5. Treat tool output as untrusted data

Tool output can return to the model and influence later actions. A compromised upstream service, retrieved web page or malicious document can therefore become an instruction-like payload even when the tool itself is legitimate.

• Prefer structured output over raw HTML or command-like text where the use case allows it.
• Validate and sanitize returned data before it becomes input to another privileged operation.
• Do not let a tool response silently redefine system policy or approval requirements.
• Log and investigate unexpected instruction-like patterns in high-trust workflows.

6. Defend URL fetches and OAuth discovery against SSRF

The official MCP security guidance explicitly covers SSRF in authorization metadata flows. Any server or supporting component that fetches URLs derived from clients, tools or metadata should assume those URLs may target localhost, private networks or cloud metadata endpoints.

• Require HTTPS in production except narrowly defined loopback development cases.
• Block private, link-local and other reserved destinations where they are not explicitly required.
• Apply the same validation after redirects instead of trusting the first URL only.
• Prefer a controlled egress proxy or network policy for server-side URL fetching.
• Use allowlists when the business function only needs known destinations.

7. Sandbox local servers before they inherit host privileges

Local MCP servers may execute with the same user privileges as the client that launches them. The official guidance therefore treats local server compromise as a distinct risk and requires clear consent before one-click flows execute commands.

• Show the exact startup command and arguments before first execution.
• Require explicit user approval; do not let untrusted web content trigger installation.
• Use containers, OS sandboxes or application restrictions where practical.
• Restrict filesystem access and network egress to the minimum needed by the server.
• Do not grant administrator/root privileges merely for convenience.

8. Harden remote transport and gateway controls

The 2026-07-28 MCP revision makes remote servers more HTTP-native and easier to place behind ordinary gateways, rate limiters and observability infrastructure. That simplifies operations, but the server still needs normal production HTTP protections.

• Use HTTPS for remote endpoints and authorization flows.
• Authenticate restricted endpoints and apply authorization on every request that needs it.
• Enforce request-size, timeout and concurrency limits appropriate to the tools being exposed.
• Use gateway or application controls to rate-limit abusive or unexpectedly expensive calls.
• Monitor method/tool patterns without logging secrets or sensitive returned data unnecessarily.

9. Bind state handles to the authenticated caller

MCP 2026-07-28 is stateless at the protocol layer. Servers that maintain workflow or application state may return a handle that the client presents again later. The official security guidance is explicit that possession of such a handle is not authentication.

• Generate non-predictable handles rather than sequential identifiers.
• Bind server-side state to the verified user or principal.
• Reject a handle when the authenticated caller does not own it.
• Expire state handles when the workflow no longer needs them.

10. Protect secrets and keep an explainable audit trail

Security logging is useful only when it helps investigate behavior without becoming a second secrets database. Record enough information to reconstruct important tool activity, but minimize and redact sensitive values.

• Keep long-lived credentials out of source code and client-visible tool output.
• Use a dedicated secret-management mechanism appropriate to the deployment environment.
• Redact tokens, passwords, private keys and unnecessary PII from logs.
• Record caller identity, tool name, timestamp, outcome and policy-relevant metadata for sensitive operations.
• Protect logs from unauthorized modification and define retention deliberately.

11. Require meaningful human confirmation for sensitive actions

OWASP recommends explicit confirmation for destructive, financial and data-sharing operations. Confirmation should show what will actually happen, not just the friendly name of the tool.

• Show material parameters such as destination, resource, amount, target account or destructive operation.
• Keep approval UI outside model-controlled text so a tool response cannot imitate or bypass it.
• Do not auto-approve sensitive calls simply because the server was previously installed or trusted.

12. Re-review after material change

A server approved yesterday may expose different tools, permissions, dependencies or startup behavior today. Approval should therefore describe the reviewed state and define what changes invalidate that approval.

• Baseline the structural identity that was reviewed: command/package, source, tools and important permissions.
• Trigger review for new or materially changed tool schemas.
• Trigger review for broader filesystem, network, API or OAuth access.
• Trigger review when package/source identity, installation behavior or critical dependencies change.
• Do not interpret “matches baseline” as “safe forever.”

Deployment sign-off questions

Before production use, a reviewer should be able to answer these questions with evidence rather than assumptions:

1. What exact server/package/command are we allowing to run?
2. Which user, service or system identity does it act as?
3. Which data, files, APIs and networks can it reach?
4. Which operations can create, modify, send, delete or disclose data?
5. What input validation protects those operations?
6. What happens when returned content contains malicious instructions?
7. How are authorization tokens, state handles and secrets protected?
8. Which actions require a human to see and confirm the real parameters?
9. What logs exist, and are secrets/PII excluded?
10. What future change forces this approval to be revisited?

Sources and further reading

This page is an independent ShadowMCP synthesis of current protocol and community security guidance. It is not an official MCP specification or an OWASP certification.

• Model Context Protocol — Security Best Practices (2026-07-28)
• Model Context Protocol — The 2026-07-28 Specification
• OWASP — MCP Security Cheat Sheet
• OWASP GenAI Security Project — A Practical Guide for Secure MCP Server Development