Home › Learn › MCP server security checklist

MCP server security checklist

Updated 2026-09-23

The MCP specification opens its security section with a plain statement: the protocol "enables powerful capabilities through arbitrary data access and code execution paths." A tool call is code running somewhere with some credential. This checklist is written for the person installing servers, not the person writing them.

1. Know what a listing does and does not tell you

Presence in a directory is not a security review. The MCP Registry's own docs say it delegates security scanning to the underlying package registries and to downstream aggregators, and its moderation policy says consumers should assume minimal-to-no moderation; it explicitly does not remove servers with security vulnerabilities. Anthropic's Claude Code security page says Anthropic "does not security-audit or manage any MCP server." Cursor's docs say to install only from trusted developers and repositories.

mcpnav is in the same position: the site's data comes from the Official MCP Registry and two MIT-licensed curated lists, and listing here is not a vetting step. Use the repository link, the star count and the archive status as inputs, not as a verdict.

2. Treat a stdio server as code you are about to run

A local server runs with your user's privileges. The MCP security best-practices document lists the attacks that follow from that: a malicious startup command embedded in a configuration, a malicious payload inside the server, and an insecure local server left listening on localhost. Its guidance to clients is to show the exact command before executing it and to highlight patterns such as sudo, rm -rf, and access to home or SSH directories.

Before you paste a command/args block:

Read the command. npx -y <package> fetches and executes whatever that package name resolves to today.
Pin the version (<package>@x.y.z) rather than floating on latest.
Check that the package name matches the repository you think you are installing.

3. Check package provenance, not just the README

npm and PyPI both offer a signal that ties a published artifact to its source.

npm provenance statements publicly link a package to its source repository and the build that produced it, generated when publishing from GitHub Actions or GitLab CI/CD. You can check a project's dependencies with npm audit signatures, which reports verified registry signatures and attestations.
PyPI Trusted Publishers use OpenID Connect to exchange short-lived tokens between a CI provider and PyPI, so the publisher never holds a long-lived upload token that an attacker could steal and reuse.

Neither proves the code is safe; both answer "is this artifact really from that repo," the question a typosquat or hijacked account exploits.

4. Least privilege for every credential

The MCP security document's scope-minimisation section describes the failure mode: a broad-scope token leaks and the attacker gets lateral access with no further prompts. GitHub's engineering post on remote MCP servers says each server instance should only have access to the secrets it absolutely needs.

Concretely: create a dedicated, narrowly scoped API key or token per server, and revoke it when you remove the server. When an OAuth consent screen asks for broad scopes, decline and look for a narrower option.

5. Keep secrets out of the config you commit

All three major clients support a way to reference a secret by variable name:

Claude Code: ${VAR} and ${VAR:-default} in .mcp.json, in command, args, env, url and headers.
Cursor: ${env:NAME} in command, args, env, url and headers; envFile for stdio servers.
Codex: bearer_token_env_var, env_http_headers and env_vars, all of which store a variable name rather than a value.

Commit the file with the reference; keep the value in your shell environment or a secret manager.

6. Use the client's approval and allow-list controls

Claude Code prompts before using servers from a project's .mcp.json and refuses to expand its own credential variables toward remote servers.
Cursor asks for approval before running an MCP tool by default and lets you toggle servers off from Customize; enterprise admins can allow-list by command or URL pattern and restrict which tools run automatically.
Codex has enabled_tools, disabled_tools, default_tools_approval_mode (auto, prompt, writes, approve) and per-tool approval_mode.

The spec's principle is that hosts "must obtain explicit user consent before invoking any tool"; the client settings are how you keep that consent meaningful.

7. Remember that tool descriptions are untrusted input

The spec says descriptions of tool behaviour such as annotations "should be considered untrusted, unless obtained from a trusted server." A tool's description is text the model reads and can act on. Prefer servers whose tool set is stable, and read the tool list once after connecting.

8. Remote endpoints: authentication, HTTPS, and audience

For a remote server:

Expect HTTPS. The security document says clients should reject http:// except for loopback addresses.
Expect authentication. The Streamable HTTP spec says servers "SHOULD implement proper authentication for all connections."
Do not hand a server a token meant for something else. Token passthrough is forbidden: a server "MUST NOT accept any tokens that were not explicitly issued for the MCP server."
Sessions are not auth. Servers "MUST NOT use sessions for authentication."

If a remote server's setup instructions ask you to paste a long-lived token for a third-party API into its config, that server is acting as the proxy the spec warns against.

9. Local HTTP servers: bind to localhost, validate Origin

Some "local" servers listen on a port. The transport spec requires Origin validation to stop DNS rebinding, and says local servers should bind to 127.0.0.1 rather than 0.0.0.0.

10. Remove what you stop using

Every configured server is a standing capability. Claude Code deletes stored OAuth tokens when you claude mcp remove a remote server; Cursor and Codex let you disable a server without deleting it, which leaves the credential in place. Periodically list your servers (claude mcp list, codex mcp list, Cursor's Customize page) and remove the ones you no longer recognise.

Sources

MCP specification, Security and Trust & Safety: https://modelcontextprotocol.io/specification/2026-07-28
MCP Security Best Practices: https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices
Streamable HTTP transport, Security & Endpoint: https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http
Claude Code security: https://code.claude.com/docs/en/security
Claude Code MCP docs: https://code.claude.com/docs/en/mcp
Cursor MCP docs (Security considerations, Enterprise admin controls): https://cursor.com/docs/mcp
Codex MCP docs (tool allow/deny lists, approval modes): https://developers.openai.com/codex/mcp
npm, Generating provenance statements: https://docs.npmjs.com/generating-provenance-statements
PyPI, Trusted Publishers: https://docs.pypi.org/trusted-publishers/
GitHub Blog, "How to build secure and scalable remote MCP servers" (Den Delimarsky, 2025-07-25): https://github.blog/ai-and-ml/generative-ai/how-to-build-secure-and-scalable-remote-mcp-servers/
MCP Registry, About (Trust and Security): https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/about.mdx
MCP Registry, Moderation Policy: https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/moderation-policy.mdx

All pages accessed 2026-09-23.