MCP Server Security: A Practical Deployment Review Guide

Evidence Status

This refresh is evidence-locked. It uses only the sources listed in the review brief: the Model Context Protocol architecture documentation, the MCP 2025-11-25 specification, MCP authorization guidance, MCP security best practices, OWASP LLM01:2025, RFC 9700, and NIST AI 600-1. Adoption forecasts, conference claims, unsupported incident claims, untested SDK snippets, fixed risk scores, and product-style promises have been removed.

Where this article turns those sources into a practitioner checklist, the text labels the result as a review decision or operating inference. The article does not claim that a classifier, regex, summary, signed manifest, certificate pin, or human reviewer makes MCP usage safe by itself.

Sources: MCP architecture, MCP specification, MCP authorization guidance, MCP security best practices, OWASP LLM01:2025, RFC 9700, NIST AI 600-1

The Practical Question: What Can This MCP Connection Actually Do?

Do not review an MCP server as a logo, marketplace entry, or GitHub repository name. Review the connection as a capability grant.

MCP defines a client/server protocol. A client can connect to a server, and servers may expose tools, resources, and prompts. That means the useful security question is not "is MCP safe?" The useful question is:

If the model is influenced by bad input, what can this connection read, change, send, spend, delete, or export?

That framing avoids two common mistakes. The first is treating every MCP server as equally dangerous. A server that reads one internal resource is not the same as a server that can change permissions or send data externally. The second is treating model behavior as the main control. OWASP LLM01 describes indirect prompt injection as a risk when an LLM processes external content such as websites or files, but its impact depends on the system's privileges and business context. The more authority the agent has, the more consequential a manipulated decision becomes.

Start every review with two inventories:

The core execution rule is simple: untrusted input may inform a read-only result, but it must not independently authorize a consequential action.

Consequential actions include sending messages, changing permissions, deleting data, spending money, or exporting data. For those actions, require deterministic policy checks and a human approval boundary instead of relying on the model's judgment.

Source: MCP architecture, OWASP LLM01:2025

A Four-Part Deployment Decision

Review a proposed MCP server through four decisions: server location, identity, tool effect, and input trust.

1. Server location

The transport and credential model matter. The current MCP specification describes HTTP authorization and states that stdio implementations use environment-acquired credentials. Do not describe SSE as the default security model. Do not treat stdio as inherently vulnerable either. MCP security guidance gives a narrower concern: proxy architectures that spawn child processes can create an escalation path if client-side compromise reaches the proxy.

Decision:

Source: MCP specification, MCP security best practices

2. Identity

For HTTP-based MCP implementations, use the protocol authorization framework when the server exposes user-specific data, consented APIs, enterprise controls, auditability, or per-user rate limits. MCP guidance recommends tested authorization libraries, short-lived tokens, token validation, HTTPS in production, least-privilege scopes, credential redaction, and audience or resource validation.

The most important boundary is token ownership. MCP security best practices state that servers must not accept a token unless it was explicitly issued for that MCP server. Token passthrough is forbidden by the authorization specification. In practice, that means an MCP server should not receive a token meant for some downstream API and treat it as proof that the caller is authorized to use the MCP server.

This is also a non-human identity problem. Every server credential, automation token, and tool-facing identity needs ownership, scope, rotation, and auditability. The identity governance angle is covered in more depth in Non-Human Identities: The Hidden Security Crisis Powering AI Agent Attacks in 2026.

Decision:

allow(tool, subject, request) only if:
  token is valid for this MCP server
  token issuer/audience/expiry are accepted
  requested scope permits this specific operation
  tool arguments pass deterministic validation
  consequence level does not require a pending human approval

This is protocol-neutral pseudocode, not a deployable SDK example.

Sources: MCP authorization guidance, MCP security best practices

3. Tool effect

Classify each tool by consequence, not by name.

Do not use a fixed Low/Medium/Critical matrix unless you have local evidence for the environment. A read-only tool can still expose sensitive content. A write-capable tool may be acceptable if it operates on narrow, validated inputs and requires approval for consequential actions. The review should produce an execution rule, not a generic label.

4. Input trust

OWASP LLM01 describes indirect prompt injection as a risk when the model processes external content such as websites or files. For MCP deployments, the practical danger is the combination of attacker-influenceable content and tools that can act.

Use this rule:

A structured summary can reduce exposure to hostile raw content, but it is still model-produced content. It must not become an authorization boundary.

Source: OWASP LLM01:2025

Remote MCP Server Verification

For a remote MCP server, the review should prove that the client is not being tricked into trusting the wrong server, token, redirect, metadata, or session.

Validate authorization and token audience

For HTTP MCP, use the protocol authorization framework where the server handles user-specific data, consented APIs, enterprise controls, auditability, or per-user rate limits. Validate tokens rather than assuming a received token is legitimate or intended for this server.

Minimum review evidence:

• HTTPS is used in production.
• The authorization implementation uses tested libraries.
• Tokens are short-lived where applicable.
• Token issuer, audience, expiry, and scopes are validated.
• The server rejects tokens not explicitly issued for that MCP server.
• Credentials are redacted from logs and error paths.
• Scopes are least-privilege for the operation.

RFC 9700 supports reducing token-theft impact through restricted token privileges and sender-constrained access tokens where feasible. That does not mean every deployment will use the same token mechanism. It means bearer-token convenience should not erase audience, scope, expiry, and sender-boundary decisions.

Sources: MCP authorization guidance, MCP security best practices, RFC 9700

Treat OAuth metadata and redirects as network inputs

The documented MCP-specific risk is not a broad claim that every deployment faces generic server impersonation. The concrete risk is that malicious OAuth metadata can make a client request internal addresses, cloud metadata endpoints, localhost services, or redirect targets unless the client validates destinations and controls egress. MCP security guidance also notes that unvalidated authorization URLs can create XSS or command-injection paths in vulnerable clients.

Minimum review evidence:

• OAuth metadata destinations are validated before use.
• Redirect destinations are validated before use.
• Private, link-local, localhost, and cloud metadata targets are rejected unless explicitly expected.
• Client egress is restricted so metadata handling cannot freely reach internal services.
• Authorization URLs are handled as untrusted input.

Source: MCP security best practices

Verify stateful HTTP session handling

Stateful HTTP implementations need request-level verification. MCP security best practices say not to use session IDs as authentication, to generate secure non-deterministic session IDs, and to bind session data to the authorized identity.

Minimum review evidence:

• Every inbound request is verified.
• Session IDs are not treated as authentication.
• Session identifiers are secure and non-deterministic.
• Session state is bound to the authorized identity.
• Session lifecycle events are auditable.

Source: MCP security best practices

Local MCP Server Verification

A local MCP server can run with the same privileges as its client. That is the key review fact. The user experience may look like a small connector install, but the security review should treat it as local code execution with access to whatever the client process can reach.

Before enabling a local server, inspect the exact command, require explicit consent, and minimize filesystem, network, and system access through sandboxing or equivalent containment. For a user-facing walkthrough of install-time risk, see The Hidden Risk of AI Skills and MCP Servers: What to Check Before You Install.

Minimum review evidence:

• The exact startup command is visible to the reviewer and user.
• The reviewed package, repository commit, or artifact is pinned.
• The server runs with only the filesystem access it needs.
• The server has no broad network access unless required and approved.
• Secrets are supplied through the narrowest feasible mechanism.
• The user gives explicit consent before the server is enabled.
• stdio or restricted IPC is used where appropriate.
• Proxy or launcher code cannot turn client-side compromise into arbitrary child-process execution.

Source: MCP security best practices

Prompt Injection: Reduce Blast Radius, Do Not Promise Detection

Indirect prompt injection happens when an LLM processes external content and that content changes the model's behavior. In an MCP workflow, this might be a document, webpage, ticket, email, issue comment, or tool result. The impact depends on what the agent can do.

Keep the security hierarchy clear:

OWASP recommends least privilege, human approval for high-risk actions, separation and identification of external content, and adversarial testing. It does not establish a foolproof prompt-injection prevention method.

The practical pattern:

1. Keep attacker-influenceable content away from tools that can send, delete, export, spend, or change permissions.
2. If raw external content must be read, use the narrowest read-only path that can complete the task.
3. Convert model output into structured proposals, not automatic actions.
4. Validate tool arguments deterministically against business rules.
5. Require human approval for consequential actions.
6. Log enough context to review what content influenced the decision and what tool call followed.

Source: OWASP LLM01:2025

Minimum Viable Operational Controls

The operating baseline should make MCP connections observable, reviewable, and reversible where possible.

Tool inventory

Maintain a current inventory with:

• Server name and owner.
• Server location: remote HTTP, local, proxy, or launcher.
• Tools, resources, and prompts exposed.
• Effect class for each tool.
• Input trust level for data returned to the model.
• Authentication and token model.
• Approval rule for consequential actions.
• Logging location and retention owner.

Secrets and credentials

For remote MCP, validate token audience, issuer, expiry, and scopes where applicable. For local servers, review how credentials are acquired from the environment and whether that environment grants broader access than the tool needs. Do not make the blanket claim that API keys cannot be scoped; provider capabilities vary. Make the narrower decision: the credential used by this MCP server must be scoped, owned, rotated, and auditable for the operation it performs.

Audit fields

Log enough to reconstruct the decision without storing unnecessary sensitive content:

• User or subject identity.
• MCP server identity.
• Tool name.
• Tool effect class.
• Request identifier.
• Token audience or resource validation result.
• Scope validation result.
• Argument validation result.
• Consequence level.
• Human approval identifier when required.
• Output size or type.
• Error and denial reason.
• Timestamp.

This is a decision framework, not a promise that a specific detection pattern will catch abuse.

Adversarial tests

Run tests before approval and after meaningful changes:

For enterprise deployment architecture, keep detailed platform patterns in the MCP server hardening case study. This guide stays at the review and control-decision level.

Sources: MCP security best practices, OWASP LLM01:2025

Go/No-Go Worksheet

Use this worksheet for a single proposed MCP server.

References

• Model Context Protocol architecture
• Model Context Protocol specification, 2025-11-25
• MCP authorization guidance
• MCP security best practices
• OWASP LLM01:2025 Prompt Injection
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• NIST AI 600-1: Generative AI Profile

Frequently Asked Questions

Is MCP itself unsafe?

The evidence brief does not support a blanket claim that MCP is safe or unsafe. MCP defines a client/server protocol where servers may expose tools, resources, and prompts. The security decision depends on the specific server, credential model, tool effects, input trust, and approval boundaries.

Is stdio the insecure transport?

No. The MCP specification describes HTTP authorization and says stdio implementations use environment-acquired credentials. MCP security guidance gives a narrower concern: proxy architectures that spawn child processes can create an escalation path if client-side compromise reaches the proxy.

Should every MCP server use authorization?

The MCP authorization guidance says authorization is strongly recommended where a server exposes user-specific data, consented APIs, enterprise controls, auditability, or per-user rate limits. The review question is whether this server needs those properties and, if so, whether token validation, audience validation, scopes, HTTPS, credential redaction, and lifecycle controls are implemented.

Can filters detect prompt injection reliably?

Filters can help, but they cannot be the authorization control. OWASP recommends least privilege, approval for high-risk actions, separation and identification of external content, and adversarial testing. It does not describe a foolproof prevention method.

What is the most important token mistake to avoid?

Do not accept a token unless it was explicitly issued for the MCP server. MCP security best practices call token passthrough forbidden by the authorization specification. Validate issuer, audience, expiry, scopes, and resource where applicable.