An MCP security checklist is the set of checks to run before an AI agent loads an MCP server: who publishes it, what exact command it runs, which version, what it can reach, how secrets and network access are handled, and whether anyone will notice when it changes. The 12 checks below cover those areas. Each one is tied to a risk in the OWASP MCP Top 10 or a requirement in the MCP specification's security best practices, and each one would have stopped or limited at least one real attack. Most take under a minute per server.
How to use this MCP security checklist
Run checks 1 to 9 once, before a server is approved for anyone to use. Run checks 10 and 11 whenever a server updates. Check 12 is about the whole organization rather than one server, and it comes first in practice: you can only review servers you know exist.
The checklist is written for the people who approve tools, usually a security engineer or a platform lead, but a developer can run it on their own machine just as well. You need the server's entry from the agent's config file and its source repository or package page. Nothing here requires running the server.
Record the result for each server: pass, fail, or not applicable, with one line of reason. A server that fails a check is not automatically rejected. A filesystem server needs file access, and a deploy tool needs a powerful token. The point is that someone decided, in writing, knowing what the server can do. That record is also what an auditor will ask for.
Before install: who publishes it and what it runs
1. The publisher matches the project it claims to be
Compare the package's publisher on npm or PyPI with the official project or company. postmark-mcp, the first malicious MCP server found in the wild, used Postmark's name but had no connection to Postmark. This is OWASP MCP04, software supply chain attacks.
2. You can see the exact command, in full
Read the whole command and args entry, not a summary. The MCP specification says clients must show the exact command before connecting a new local server, because a config line can chain extra commands onto the real one. OWASP lists this as MCP05, command injection and execution.
3. The version is pinned
A line like npx -y package with no version runs whatever was published last. Pin an exact version so that updates arrive only when someone chooses them. postmark-mcp turned malicious in its sixteenth release.
4. The tool descriptions contain no instructions
Read the description of every tool the server offers. A description should say what the tool does. Text that tells the model how to use other tools, what to send where, or what to hide from the user is tool poisoning, OWASP MCP03.
Permissions: what the server can reach
5. File access is limited to the folders the job needs
Filesystem servers take folder paths as arguments. Give one project folder, never / or the whole home folder. The MCP documentation warns that a local server runs with your user account permissions, so it can do anything you can.
6. Tokens carry the smallest scope that works
Give each server a token that reaches only what the task needs: one repository, read-only where possible. The MCP specification calls this scope minimization, and OWASP lists over-broad access as MCP02, privilege escalation via scope creep. The GitHub prompt injection case leaked private repositories because the agent's token could reach all of them.
7. Secrets are not written into the config file
Pass API keys through environment variables or the agent's secret storage, not as literal values in mcp.json. VS Code's documentation puts it directly: a personal configuration file is not a secret store. Config files get copied, synced and committed. This is OWASP MCP01, token mismanagement and secret exposure.
Network and transport
8. Local servers use stdio, or HTTP with authentication
The MCP specification recommends the stdio transport for local servers so only the client can talk to them. A local server listening on HTTP without a token can be reached by other processes on the machine, including a malicious web page through DNS rebinding.
9. Remote servers use HTTPS on a host you recognize, and the client is current
Check that every url entry is HTTPS and belongs to the vendor you expect. Then check the client and any bridge it uses. CVE-2025-6514 let a malicious remote server run commands through mcp-remote versions 0.0.5 to 0.1.15; version 0.1.16 fixed it.
After install: watch for changes
10. Changes to tools are reviewed, not auto-accepted
A server can pass every check on day one and change later. In Invariant Labs' WhatsApp research, the server swapped its tool description on its second launch, after the user had approved it. Re-read descriptions when a server updates, and prefer clients that warn when they change.
11. Tool calls are logged somewhere you can search
Keep a record of which tools each agent called and with what arguments. Without it, an incident has no trail to follow. OWASP lists this as MCP08, lack of audit and telemetry. If you run your own servers, our guide to MCP server logging best practices covers what each record needs.
Across the org: know every server
12. Every MCP server in use is in one inventory
List every server across every developer machine and repository, with who runs it and where. OWASP calls the ones nobody knows about shadow MCP servers, MCP09. Our guide shows how to find MCP servers on developer machines for each major coding agent, and the inventory is what the other 11 checks run against.
MCP security checklist mapped to the OWASP MCP Top 10
The table maps each check to the OWASP risk it addresses. OWASP's MCP10, context injection and over-sharing, is covered in part by checks 5 and 6, since a server that can reach less has less to over-share.
| Check | OWASP MCP Top 10 (2025) |
|---|---|
| 1. Publisher matches the project | MCP04 Software supply chain attacks and dependency tampering |
| 2. Exact command visible | MCP05 Command injection and execution |
| 3. Version pinned | MCP04 Software supply chain attacks and dependency tampering |
| 4. Descriptions contain no instructions | MCP03 Tool poisoning; MCP06 Prompt injection via contextual payloads |
| 5. File access limited | MCP02 Privilege escalation via scope creep; MCP10 Context injection and over-sharing |
| 6. Smallest token scope | MCP02 Privilege escalation via scope creep; MCP07 Insufficient authentication and authorization |
| 7. No secrets in config | MCP01 Token mismanagement and secret exposure |
| 8. stdio or authenticated HTTP | MCP07 Insufficient authentication and authorization |
| 9. HTTPS, known host, current client | MCP05 Command injection and execution |
| 10. Changes reviewed | MCP03 Tool poisoning |
| 11. Tool calls logged | MCP08 Lack of audit and telemetry |
| 12. One inventory | MCP09 Shadow MCP servers |
What this checklist does not cover is how the agent itself is configured: which tools it may call without asking, whether it runs unattended, and what model it uses. Those settings change the risk of every server it loads, and they belong in a separate review of each coding agent.
To see checks 3, 5 and 7 applied to a real config, look at our mcp.json example. For agents that can skip approvals entirely, read what the --dangerously-skip-permissions flag does in Claude Code.
Next step: run the MCP security checklist on what you already have
The MCP security checklist works one server at a time, which is fine for a new request and slow for the servers already in use. Look up any single server on the NoFly list for a quick answer, or use the MCP security scanner to check every server across your machines and repositories in one pass.