MCP Server Security Review Checklist + Filled Remote Server Example

This page gives you a copyable MCP server security review checklist, a filled example, and a simple go or no-go method. Use it before you connect any remote MCP server to an AI agent, chatbot, coding assistant, or internal workflow that can read sensitive data or take action.

The point of this review is not to prove a server is perfect. It is to decide whether the server is safe enough for the exact workflow, data, and approval model you want to use in production. That means reviewing the server as both a software dependency and an operational control surface.

The current MCP authorization specification for HTTP-based transports is built around OAuth 2.1 patterns, but auth alone is not a full production review. The MCP security guidance also calls out issues like per-client consent, SSRF, risky local execution paths, and over-broad trust assumptions, which is why a structured checklist is more useful than a quick demo pass.

When to use this review

Use this checklist before any of the following:

• Connecting a third-party remote MCP server to a model that can read internal data.
• Allowing an MCP tool to create, update, submit, approve, or delete records.
• Rolling out a new MCP-powered workflow to employees, customers, or contractors.
• Moving from a read-only pilot to write actions.
• Approving a server that will be reused across multiple agents or teams.

If the server only powers low-risk read-only lookups with public data, you can move faster. If it touches contracts, customer records, finance systems, production infrastructure, or admin actions, do the full review and require explicit signoff.

Copyable MCP server security review template

Copy this template into your launch doc, vendor review, or internal security ticket. The goal is to force concrete answers before anyone says yes to production access.

# MCP Server Security Review Checklist

## 1) Workflow and business owner
- Server name:
- Provider or internal owner:
- Business workflow:
- Primary user group:
- Technical owner:
- Security reviewer:
- Launch decision date:

## 2) What the server can access
- Connected systems:
- Data types exposed:
- Sensitive data involved: [ ] none [ ] internal [ ] customer data [ ] financial [ ] regulated
- Highest-risk downstream action:
- Read-only tools listed separately from write or action tools: [ ] yes [ ] no

## 3) Trust and provenance
- Official server from the service provider: [ ] yes [ ] no
- If third-party or aggregator, why is it acceptable?
- Documentation reviewed: [ ] yes [ ] no
- Terms, privacy, and retention reviewed: [ ] yes [ ] no
- Known security contacts or incident path documented: [ ] yes [ ] no

## 4) Authentication and authorization
- Transport type:
- Auth method:
- User identity preserved end to end: [ ] yes [ ] no
- Token scopes minimized for pilot: [ ] yes [ ] no
- Redirect URIs reviewed: [ ] yes [ ] no
- Short-lived tokens or rotation in place: [ ] yes [ ] no
- Service-account access used instead of user-delegated access: [ ] yes [ ] no
- Reason for auth choice:

## 5) Tool surface and approvals
- Allowed tools in pilot:
- Blocked tools in pilot:
- Any tool can mutate data or trigger actions: [ ] yes [ ] no
- Human approval required for risky tools: [ ] yes [ ] no
- Tool arguments validated outside the model: [ ] yes [ ] no
- Maximum blast radius if the model misuses one tool:

## 6) Prompt injection and output safety
- Untrusted content can reach the model before a tool call: [ ] yes [ ] no
- Tool outputs are treated as untrusted input: [ ] yes [ ] no
- URLs returned by tools are allowlisted or reviewed before fetch or embed: [ ] yes [ ] no
- High-risk instructions from tool output are blocked or stripped: [ ] yes [ ] no
- Model is prevented from directly executing arbitrary follow-on actions: [ ] yes [ ] no

## 7) Network and runtime controls
- Outbound destinations restricted: [ ] yes [ ] no
- Private IP and metadata endpoints blocked where relevant: [ ] yes [ ] no
- Local execution or shell access involved: [ ] yes [ ] no
- If yes, sandbox and consent controls documented: [ ] yes [ ] no
- Rate limits and timeout behavior defined: [ ] yes [ ] no

## 8) Logging and auditability
- Logs capture user, agent, server, tool, arguments, result, and approval event: [ ] yes [ ] no
- Sensitive values redacted where required: [ ] yes [ ] no
- Reviewable audit trail retained for incidents: [ ] yes [ ] no
- Kill switch or server disable path documented: [ ] yes [ ] no
- Version changes to tools are monitored: [ ] yes [ ] no

## 9) Launch decision
- Pilot verdict: [ ] go [ ] go with restrictions [ ] no-go
- Required restrictions before launch:
- Owner for each remediation item:
- Re-review trigger:
- Next review date:

Filled example: remote deal desk MCP server

Below is a realistic filled example for a sales workflow. The server lets an internal deal desk agent look up contract terms, check discount policy, and draft an approval packet for human review.

Workflow scope

• Business workflow: enterprise quote review for nonstandard discounts.
• Users: sales operations managers and deal desk analysts.
• Connected systems: CRM, pricing policy database, contract repository.
• Highest-risk action: submitting a discount exception request into the approval queue.

Pilot decisions

• Allowed in phase one: contract lookup, pricing policy lookup, draft approval summary.
• Blocked in phase one: submit exception, update CRM fields, send external email.
• Approval rule: every action that changes records stays human-approved until the first review cycle is complete.
• Auth choice: user-delegated access for read tools, no shared admin credential, short-lived session tokens only.
• Logging rule: every tool call records user, account, tool name, arguments, result class, and approval state.

What made this a partial go instead of a full go

The server passed the trust and scope review for read operations, but not for write actions. The team could not yet prove that tool arguments were normalized outside the model, and the audit trail for approval overrides was incomplete. That means the correct launch decision is go with restrictions, not full production approval.

Example launch decision

What strong answers look like in practice

A good MCP review is specific. It does not say a server is secure because it supports OAuth, has docs, or worked in a demo. It answers the operational questions that decide whether the workflow can fail safely.

Strong answer 1: the pilot tool set is smaller than the full server tool set

Most teams should not expose every tool on day one. Separate read-only tools from action tools, then approve the smallest set that still proves the workflow. If the model only needs three tools for the pilot, do not expose twelve.

Strong answer 2: risky actions have human approval and non-model validation

If a tool can send email, change records, approve spend, or trigger infrastructure actions, approval should happen outside the model. The safest pattern is to validate arguments with deterministic rules, show the user what will happen, and only then allow execution.

Strong answer 3: logs are usable during an incident

You need enough detail to answer five questions fast: who triggered the action, which agent called which tool, what arguments were sent, what the downstream system returned, and whether approval was granted or bypassed. If your logs cannot answer those questions, your review is incomplete.

Strong answer 4: the team knows the rollback path

Every approved server should have a disable switch. That can be a feature flag, an allowlist removal, a credential revocation path, or all three. If the only rollback plan is to debug live, you are not ready.

Common mistakes that make MCP reviews too weak

• Treating OAuth as the whole review. Good auth does not fix over-broad tools, dangerous outputs, bad approval rules, or weak logging.
• Approving the server instead of approving the workflow. The same server may be acceptable for read-only research and unacceptable for financial writes.
• Ignoring tool-output risk. Tool results, returned URLs, and retrieved content should be treated as untrusted input, not as automatically safe instructions.
• Leaving write tools enabled for convenience. If a pilot does not need a tool, block it.
• Skipping re-review triggers. A server that changes tools, scopes, auth behavior, or provider ownership should be reviewed again.

Next steps

Start by running this checklist against one real server that your team already wants to connect. Do not begin with a hypothetical perfect design. A real review will surface the missing approvals, logging gaps, and scope mistakes much faster.

1. Pick one production-intent workflow, not a general platform discussion.
2. List the exact tools needed for the pilot and block everything else.
3. Write the initial verdict as go, go with restrictions, or no-go.
4. Assign owners and dates to every open gap before launch.

If you do this well, you get more than a safer MCP rollout. You also get a cleaner operating model for every future agent, connector, and tool integration you approve after it.