MCP is useful because it lets agents act through tools.

That is also why production MCP needs a security checklist. A tool server is not just a convenience setting. It is software with dependencies, credentials, transport behavior, and operational reach.

1. What servers are installed?

Start with inventory. Record every MCP server, package manager, version, source, install method, and owner. Include both official and community packages. Include local-only tools. Include servers that developers run with npx, uvx, pipx, Docker, or direct binaries.

2. Which versions are actually resolved on disk?

package.json, pyproject.toml, or a config file tells you what someone intended. The lockfile and installed tree tell you what actually runs.

3. Are you scanning the installed tree or only the top-level package?

A top-level package scan can report clean while the installed runtime contains vulnerable transitive dependencies.

The scanner should walk the runtime tree and check every resolved package version. Then someone should classify whether each finding is dependency-only, reachable hardening, or confirmed reachable behavior.

4. Which tools can each server expose?

List the tools. For each tool, record:

  • What input it accepts.
  • What system it can reach.
  • Whether it reads data, writes data, executes actions, or starts sessions.
  • Whether it can be disabled.
  • Whether the description is stable and reviewed.

Tool metadata is not harmless. Agents use it to decide what to call.

5. Which credentials can each server reach?

Credential scope is often the real blast radius. For every MCP server, identify:

  • Environment variables.
  • API keys.
  • OAuth tokens.
  • Service accounts.
  • Browser sessions.
  • Cloud credentials.
  • Local files containing secrets.

Then ask whether each credential is scoped to the tool's actual job.

6. Is execution isolated?

Some MCP servers only transform data. Others open browsers, execute commands, read files, or call internal services.

For higher-risk servers, isolation should include:

  • Separate process identity.
  • Limited filesystem access.
  • Network egress rules.
  • Resource limits.
  • Container or sandbox boundaries where practical.
  • No broad admin credentials.

7. Are local transports safe?

If a server exposes local HTTP, check:

  • Bind address.
  • Host validation.
  • Origin validation.
  • CORS behavior.
  • Authentication.
  • Whether browser-originated traffic can reach action paths.

Do not assume localhost is a complete security boundary.

8. Are critical findings blocked?

Define a policy before the emergency.

  • Block known critical runtime dependencies on active MCP paths.
  • Warn on high findings until reviewed.
  • Allow dependency-only findings with a documented exception.
  • Block deprecated packages unless explicitly approved.
  • Require maintainer notification for private findings before public naming.

9. Are tool calls logged with policy context?

Logs should answer more than "a request happened." For production MCP, record:

  • Initiating identity.
  • Agent or session identity.
  • MCP server name and version.
  • Tool name.
  • Policy decision.
  • Credential class.
  • Target system.
  • Timestamp.
  • Result category.

10. Can you prove which policy allowed the call?

The stronger pattern is a receipt. A receipt binds the tool call to the authorization decision that allowed it. It should connect identity, server, tool, policy, dependency state, and result in a tamper-evident audit trail.

A simple launch gate

  • Inventory complete.
  • Installed-tree scan complete.
  • High-risk tools reviewed.
  • Credentials scoped.
  • Local transports checked.
  • Critical findings blocked or remediated.
  • Receipts enabled for sensitive tools.
  • Owner assigned for patching.

MCP is powerful enough to deserve production controls.