Security check

Treat every MCP server as executable integration code—not a harmless prompt extension.

Source-checked security guide · July 27, 2026

MCP Server Security Checklist

Verify source, permissions, credentials, client boundaries, and rollback before enabling writes

MCP servers can reach local files, browsers, APIs, databases, repositories, and memory. Use this five-gate review before installation, then prove read-only behavior in the exact client before allowing mutations.

5 pre-install gatesLeast privilegeRead-only first
MCP security guidance ↗OWASP MCP Top 10 ↗NIST least privilege ↗

Direct answer

What is the safest way to install an MCP server?

Verify the source, package, and publisher; inventory every file path, scope, domain, command, and credential; sandbox the exact client; prove one read-only task and one intentionally blocked write; then record rollback, review, and credential-rotation dates.

Safe default

Verify, isolate, prove

Start with no production credential and the narrowest workspace, role, transport, and network target that can complete one low-risk task. Expand only from saved evidence.

Lower risk

Read-only docs/search or one narrow project folder with no production credential.

Review first

Filesystem, browser, database, GitHub/DevOps, memory, and remote OAuth servers.

Block

Unknown publisher, hidden command, broad home-directory access, production write token, or missing rollback.

Source

Publisher matched

Scope

Least privilege

First run

Read only

Review

Scheduled

Five pre-install gates

The MCP security checklist

Pass every gate before enabling writes. A failed source, scope, client, proof, or review gate is a stop condition—not a warning to ignore.

Source

Verify

Package, repository, publisher, and official documentation

Pass

All identify the same maintained project

Scope

Verify

Files, tools, APIs, domains, commands, scopes, and credentials

Pass

Only the minimum access needed for the task

Client

Verify

Exact host, transport, working directory, and browser or editor profile

Pass

The observed boundary matches the intended configuration

Proof

Verify

One read-only task plus one intentionally blocked write

Pass

The expected task succeeds and the mutation stays blocked

Review

Verify

Logs, rollback, owner, credential expiry, and review date

Pass

Evidence is saved and rotation or removal is scheduled

Stop condition

Unknown publisher, hidden command, broad home-directory access, production write token, missing logs, or no rollback means do not install.

Risk matrix

Choose the guardrail by server type

Risk follows capability and credential reach. Classify the server by what it can touch—not by how friendly its marketplace listing looks.

Lower risk

Documentation or search

Public or read-only data with no production credential. Still verify the publisher, package, outbound domains, and update path.

read-only
no production secret

Use a disposable client profile and save the first-run evidence.

Review first

Filesystem, browser, or database

Restrict file paths, browser profiles, database roles, network targets, command execution, and every write-capable tool.

narrow scope
blocked write

Test the exact client and credential combination before expanding access.

Block by default

Payments, messaging, production DevOps

These servers can create irreversible external effects and should never inherit a broad personal or production identity.

explicit action
audit + rollback

Require least-privilege credentials, per-action confirmation, logs, expiry, and a tested rollback.

Rollout + policy

Prove the boundary before expanding access

A successful connection proves transport—not safety. Roll out one capability, one client, one credential, and one reversible task at a time.

Five-stage review

One surface, five security decisions

01

Verify source

Match package, repository, publisher, docs, and maintenance history.

02

Map permissions

List every path, tool, API, domain, command, scope, and credential.

03

Sandbox the client

Use the exact host and transport in an isolated workspace or profile.

04

Prove read-only

Complete one low-risk task and confirm an attempted mutation stays blocked.

05

Schedule review

Record logs, rollback, owner, expiry, and credential rotation or removal.

Safe rollout

Connect narrowly, verify, then expand

1

Create a dedicated workspace

Keep the first run away from personal files and production systems.

2

Issue one narrow credential

Use the smallest role, scope, and lifetime that can complete the test.

3

Run a read-only task

Inspect the request, tool call, response, files touched, and outbound domains.

4

Trigger a blocked write

Prove the current boundary rejects a mutation you did not authorize.

5

Save evidence and rollback

Record logs, config diff, removal steps, owner, and next review date.

Ongoing policy

Re-review after publisher, package, version, scope, credential, client, transport, working directory, or network changes. Remove unused servers and rotate exposed or stale credentials.

MCP security FAQ

MCP server security questions, answered directly

Are MCP servers safe to install?

MCP servers can be used safely only when their source, requested permissions, credentials, transport, and client behavior are verified. A marketplace listing or successful connection is not proof that a server is safe for personal files or production systems.

What is the safest first MCP server to test?

Start with a read-only documentation or search server, or one server limited to a disposable project folder. Avoid production credentials, personal browser sessions, broad home-directory access, and write-capable tools during the first test.

Should an MCP server use production API keys?

Production credentials should not be the default. Begin with a sandbox credential, read-only role, limited OAuth scope, short expiry, or branch environment. Expand access only after the exact client has passed a read-only task and an intentionally blocked write.

How do I verify an MCP install command?

Confirm that the package name, repository, publisher, official documentation, and install command all describe the same maintained project. Review the exact command before running it, including environment variables, working directory, transport, and any one-click configuration changes.

How often should MCP permissions be reviewed?

Review after any publisher, package, version, client, transport, credential, scope, working-directory, or network change. Also schedule a recurring review for servers that can touch files, browsers, databases, repositories, messages, payments, or customer data.

What should an MCP security policy block by default?

Block unknown publishers, hidden commands, broad home-directory access, production database writes, authenticated browser submissions, payment changes, message sending, secret printing, and any server without logs or a tested rollback path.

MCP install examples

Review source-aware command examples before copying a package into a trusted client.

Best MCP servers

Compare source trust, install surface, assistant fit, and operational risk.

MCP browser automation

Separate evidence workflows from authenticated actions and irreversible submissions.

Primary-source ledger

Checked against official MCP guidance, OWASP, and NIST

Last checked July 27, 2026. OWASP MCP Top 10 is currently labeled beta/pilot, so this guide uses it as a structured review aid—not a final standard.

Official MCP

Security best practices

Authorization, confused deputy, token passthrough, SSRF, sessions, local servers, scopes

OWASP

MCP Top 10

Beta/pilot catalog covering secrets, scope, poisoning, injection, audit, and shadow servers

NIST

Least Privilege

Minimum resources and authorizations required to perform the function

Agent Skills Hub

Source-checked guides · visible review dates · no blind install promises

AboutMethodologySubmit a Skill