MCP security checklist: 12 checks before you connect a server

Model Context Protocol makes AI tools dramatically more useful. It also turns a chat or coding session into a client for external tools, data sources and privileged actions. A server may read local files, query a database, open tickets, call cloud APIs or execute commands.

That means an MCP server belongs in the same risk conversation as a browser extension, command-line tool and service account. “It connected successfully” is not a security review.

Use this checklist before adding a server to a developer machine or an organization-wide configuration.

1. Verify who published the server

Start with identity. Find the official repository and package listing. Check the publisher, commit history, release cadence and ownership changes. Confirm that the installation instructions come from the same organization that maintains the software.

A familiar name is not enough. Typosquatting and dependency confusion work precisely because names look plausible. If an agent suggested the server, verify it independently before installation.

2. Read the installation path

Understand what will run. Some servers execute through a package runner. Others download binaries or start containers. Inspect post-install scripts and remote downloads. Prefer pinned versions and immutable checksums over commands that always fetch the latest code.

A clean server package can still inherit risk from its dependencies. Capture the resolved lockfile or image digest so the reviewed artifact is the one that runs.

3. List every tool the server exposes

Tool names and descriptions become part of the model’s decision environment. Review the actual tool schema, not the product summary. A “project helper” may expose file deletion, deployment or arbitrary query execution beside harmless read operations.

Remove unused tools where the client or server supports allowlists. A server that only needs to read issue metadata should not also inherit issue deletion or organization administration.

4. Separate read and write authority

Read-only access is not risk-free, but it is easier to contain than mutation. Use separate identities or server configurations for read and write operations. Make production writes an explicit mode rather than a side effect of connecting the server.

When possible, require a second approval or downstream policy for actions such as deleting cloud resources, changing access controls, merging code or mutating customer data.

5. Use narrow credentials

Create credentials for the MCP integration instead of recycling the developer’s broad personal token. Restrict the audience, scopes, projects and environments. Use short-lived tokens when the platform supports them.

The official MCP authorization guidance is explicit about validating token audience and avoiding token passthrough. A server should not accept a token intended for another service then forward it downstream.

6. Keep secrets out of prompts and logs

Do not place API keys directly in project configuration that will be committed, indexed or supplied to a model. Use an operating-system credential store, secret manager or injected environment variable with the narrowest possible visibility.

Review server logs too. Tool arguments and responses may contain customer data, source code or credentials. Redact sensitive fields before they enter local logs, hosted telemetry or support bundles.

7. Assume tool output can be hostile

Prompt injection can arrive through a web page, issue description, document, database row or tool response. The content does not need to look malicious to a human. It only needs to influence the model into using another tool or revealing data.

Treat external content as untrusted data. Do not let a tool response silently expand permissions. Keep sensitive tools behind explicit policy and prevent untrusted output from deciding where secrets are sent.

8. Protect against the confused deputy problem

A confused deputy occurs when a trusted component uses its authority on behalf of an attacker. For example, a malicious link could trigger an authorization flow that causes a broadly trusted MCP proxy to act against the wrong account.

Bind authorization requests to the initiating client and user. Validate redirect URIs. Use state and PKCE correctly. Never assume that a request is legitimate merely because it arrived through a trusted MCP client.

9. Isolate local filesystem and process access

If a server runs locally, constrain its working directory, environment and network access. Do not expose the whole home directory when it only needs one repository. Avoid passing the parent process’s complete environment into a server that requires one token.

Containerization can help but it is not automatic safety. Review mounts, host networking, Docker socket access and privileged mode. Mounting the Docker socket often gives the container effective control over the host.

10. Review persistent configuration changes

MCP configuration is durable authority. Monitor additions and modifications across user-level and project-level configuration. Flag server command changes, new arguments, new environment variables and altered endpoints.

Project configuration deserves special care because it can arrive through a cloned repository. A repository should not silently gain trusted tool access just because a developer opened it.

11. Log actions without leaking evidence

Record which server, tool, user, session and target participated in an action. Bind the record to a configuration and policy revision. For sensitive actions, store reason codes and fingerprints rather than raw secrets or complete command content.

Logs should answer “what authority was used and why was it allowed?” They should not become a second secret store.

12. Plan removal before installation

Know how to disable the server, revoke its credentials and remove persisted configuration. Test that revocation works. Maintain an inventory so a compromised package or leaked token can be found across developer machines quickly.

Re-review servers after ownership changes, major releases or permission expansion. Trust is a maintained state, not a one-time checkbox.

A minimum policy for teams

Risk	Minimum requirement
Unknown software	Approved publisher, pinned version and recorded artifact
Excess authority	Tool allowlist plus environment-specific credentials
Prompt injection	Untrusted output cannot authorize a sensitive action
Credential misuse	Audience validation, no token passthrough and short-lived access where possible
Configuration drift	Continuous monitoring of user and project MCP configuration
Incident response	Inventory, revocation path and action evidence

MCP is valuable because it joins models to real systems. That is also why it needs deliberate security. Keep the connection useful, but make the server’s identity, authority and behaviour visible before it becomes trusted infrastructure.