MCP Security Checklist

An MCP server runs with your permissions

This is the fact that makes MCP security matter. When you install a server, you are giving code the ability to act inside your environment - read your files, hit your APIs, touch your data - on your behalf. That is exactly why MCP is powerful, and exactly why an untrusted server is dangerous. This checklist walks you through the questions that actually determine whether a given server is safe to add, and weights them by impact so a high score reflects real coverage of the risks that matter.

Nothing here is theoretical. Committed API keys, over-broad file access, and prompt injection through tool output are the real failure modes people hit. The checklist is grouped into the four areas that cover them: trust in the code, least-privilege access, secret handling, and prompt injection.

1. Trust: do you actually know what this is?

• Read the source, or at least confirm it comes from a maintainer you have reason to trust. An MCP server is arbitrary code running with your access.
• Do not equate popularity with safety - a well-starred repo can still ship a bad release. A quick review of what it exposes catches the obvious problems.
• Pin a version. A server that floats to latest can update into a compromised or breaking release without you choosing to.

2. Access: grant the minimum, not the maximum

• Scope the server tightly - a filesystem server pointed at one project directory cannot leak your whole home folder.
• Default to read-only. Read access can leak data; write access can delete or corrupt it. Escalate to write only when the job truly needs it.
• Know whether the server reaches the network and where it sends data. Network access plus read access is an exfiltration path.

3. Secrets: keep them out of shared configs

A funded API key committed to a shared .mcp.json is a real security incident - anyone with repo access now has your key. Reference secrets through environment variables and keep the values out of version control. Give the server a scoped, revocable credential so that if it is ever compromised, the blast radius is small and you can close it fast. The speed at which you can rotate a key is your last line of defense.

4. Prompt injection: tool output is untrusted data

When an MCP server returns content - a web page, a file, a database row - that content can contain text crafted to hijack the model, along the lines of 'ignore your previous instructions and do X'. This is prompt injection, and it is the MCP-specific risk most people underestimate. Treat everything a server returns as untrusted data, not as instructions. Gate destructive or sensitive actions behind your own confirmation so an injected instruction cannot silently trigger them.

What the score means, and what it does not

The score is weighted: trust, least-privilege access, and prompt-injection awareness count for more than nice-to-haves like version pinning, because they cover the highest-impact failures. A score at or above 85% means you have covered the risks that actually cause incidents - proceed, and keep the credential scoped. Below that, some real gap remains. But treat any score as a signal, not a certificate. Security is a practice, not a one-time checkbox pass.

A safe default install flow

1. Read or vet the server source before touching your config.
2. Add it with the narrowest scope that does the job - one directory, read-only, minimal token.
3. Reference any secret via an env var; never commit the raw value.
4. Test it in a low-stakes context before pointing it at anything sensitive.
5. Keep untrusted-web servers away from high-privilege servers in the same trust boundary.
6. Know how to revoke the credential in under a minute, and be ready to.