MCP Security Checklist

15 things to verify before you deploy an MCP server. April 2026.

This checklist covers the security basics for evaluating any MCP server, whether you found it on GitHub, received it from a vendor, or built it yourself. Use it as a pre-deployment gate. Print it and tape it next to your monitor if that helps.

• 1. Verify requested permissions match the stated purpose A code formatter should not need network access. A search tool should not need write access. Compare what the server asks for against what it claims to do.
• 2. Check for filesystem access scope Does the server access specific directories or the entire filesystem? Broad access increases risk. Look for path restrictions in the server configuration.
• 3. Review environment variable access Does the server read environment variables? Which ones? Servers that access API keys, tokens, or credentials should be scrutinized carefully.

• 4. Search for dynamic code execution Look for eval(), exec(), new Function(), or language equivalents. These allow arbitrary code execution and are almost always a red flag.
• 5. Check input validation Are user inputs validated before being used in file paths, shell commands, or database queries? Unsanitized inputs are the most common injection vector.
• 6. Review network request patterns Are HTTP requests going to hardcoded, known URLs or are URLs constructed from user input? User-controlled URLs can enable SSRF attacks.

• 7. Verify a lockfile exists Missing lockfiles mean dependency versions can change between installs. Check for package-lock.json, yarn.lock, pnpm-lock.yaml, or equivalent.
• 8. Review dependency count Fewer production dependencies means a smaller attack surface. A server with 3 dependencies is easier to audit than one with 200.
• 9. Check for install scripts Look for preinstall, postinstall, or prepare scripts in package.json. These run automatically during installation and can execute arbitrary code.
• 10. Scan dependency names for typosquatting Malicious packages often use names similar to popular ones (e.g., lodahs instead of lodash). Verify that dependency names match known, legitimate packages.

• 11. Confirm a LICENSE file exists No license means the code is not legally open source, regardless of being on GitHub. Check that the license is compatible with your use case.
• 12. Look for security documentation Does the repo document its security model? What permissions it needs and why? A SECURITY.md or equivalent shows the maintainer thinks about trust.

• 13. Check maintenance status When was the last commit? Are issues being addressed? Abandoned servers may have known vulnerabilities that are not being patched.
• 14. Run an automated audit Use audit.pyfio.com to get a scored report covering all these categories automatically. Takes about 60 seconds.
• 15. Document your decision Record what you found, what risks you accepted, and why. If something goes wrong later, you will want to know what you knew when you deployed.

Using this checklist

You do not need to pass all 15 checks to deploy a server. Some servers legitimately need broad permissions. The point is to make an informed decision rather than a blind one. If you can answer "yes" to items 1 through 12, the server is following good practices. Items 13 through 15 are about your deployment process.

For a deeper explanation of each category, see How to Audit Your MCP Servers Before Installing.