MCP server security checklist: review before you install or build

What should you check before installing or building an MCP server?

1-minute summary

• Treat every server, tool definition, returned value, and connected server as an untrusted boundary.
• Pin the server's source and version, review definition changes, and grant only the permissions each tool needs.
• Validate OAuth tokens for this server, sandbox local execution, require informed approval for sensitive actions, and keep useful audit logs.

Who this is for

Use this checklist if you are choosing a third-party MCP server, adding one to an AI client, or building a server that can access company data or perform actions.

Conclusion

An MCP connection is a code and data boundary, not just a convenient plugin. Before enabling it, establish where the server came from, what code will run, what each tool can read or change, and how those facts will be checked after updates.

For a remote server, authenticate the caller and validate that access tokens were issued for that MCP resource. For a local server, assume its process can act with the client's operating-system privileges unless you restrict it. In both cases, tool descriptions and results can carry indirect prompt injections, so approval and policy enforcement must not rely on the model interpreting them safely.

Explanation

Tool poisoning and definition changes

Tool descriptions, parameter schemas, annotations, and returned content enter the model's working context. A malicious instruction can be hidden in otherwise ordinary metadata or output and steer the model toward another tool or toward disclosing data. Invariant Labs documented this as a tool poisoning attack, including cross-server shadowing: one server's description can influence how the agent uses a different, trusted server.

A server can also change its tool definitions after a review or approval. This “rug pull” means an earlier inspection is not evidence that the current tool is unchanged. Compare definitions on every meaningful update and at runtime where the client supports it; pause use when a change is unexplained.

Indirect prompt injection is a data-flow problem

An email, web page, issue, document, or tool result may contain instructions aimed at the agent. Treat such content as data, not as a source of policy. Prevent sensitive reads from flowing to unrelated write or network tools; validate actions in server-side code and enforce destination and permission rules outside the model.

Local execution and remote authorization have different risks

An MCP server using stdio is a child process that can execute code with the privileges of its launcher. The transport does not sandbox it. Review the exact command and arguments, package and install scripts, environment variables, filesystem access, and network needs; run it with a restricted account or sandbox where practical.

For remote HTTP authorization, validate issuer, signature, expiry, scopes, and especially audience (aud) against the MCP server's own resource identifier. Do not accept a token issued for another API, and do not pass an incoming client token through unchanged to a downstream API. Obtain a separately scoped downstream credential or use a deliberate token exchange flow.

Practical guide

1. Establish provenance and change control

• Prefer an official repository or verified publisher. Check the exact package name, repository, release, and maintainer identity.
• Pin a release or immutable commit and lock transitive dependencies. Review install scripts and integrity/signature information available from the distribution channel.
• Read the server source or obtain a focused security review for sensitive capabilities. A scanner can help find suspicious descriptions; it cannot prove the implementation safe.
• Save a baseline of tool names, descriptions, input schemas, annotations, and server version. Alert and re-review when any of them change.

2. Minimize authority

• Give each server only the data, filesystem paths, network destinations, and API scopes it needs.
• Separate read tools from write or destructive tools. Prefer narrow operations over generic shell, SQL, filesystem, or arbitrary-URL tools.
• Use per-server credentials. Keep secrets out of source code, prompts, tool descriptions, logs, and shared configuration where possible.
• On remote servers, enforce authorization for every request and every object. Derive user identity from a verified credential, not a tool argument.

3. Secure OAuth and transport

• Use HTTPS for remote MCP endpoints and validate tokens at the MCP resource boundary.
• Check token issuer, signature, expiry, scopes, and audience. Reject tokens intended for another resource.
• Never implement token passthrough. Do not forward a caller's MCP access token to a downstream API unchanged.
• Keep credentials short-lived and scoped. Do not log bearer tokens or authorization codes.

4. Constrain stdio and tool behavior

• Inspect the exact executable, arguments, package version, working directory, and environment before launch.
• Avoid unpinned npx/package execution in production. Disable unnecessary network access and mount only required paths read-only where possible.
• Validate tool inputs against strict schemas and business rules; reject undeclared fields and unsafe paths, commands, or URLs.
• Treat tool output as untrusted. Bound its size and prevent returned instructions from silently triggering privileged follow-up calls.

5. Make approval and logging meaningful

• Require explicit human approval for sending data externally, modifying or deleting records, financial operations, or expanding permissions.
• Show the full action and consequential parameters in the approval UI. Approval of a server install is not blanket approval of every future tool call.
• Log server identity/version, tool name, decision, timestamp, actor/request ID, and outcome. Redact secrets and sensitive payloads; restrict and retain logs according to policy.
• Test whether prompt injection can cause a denied action, cross-server data flow, or an unapproved call. Record the expected block and alert on violations.

Pitfalls

• Approving a tool based only on its display name while ignoring its full description and schema.
• Trusting the original review after a package, server implementation, or tool definition changes.
• Treating stdio as a sandbox or assuming localhost means inaccessible to other local processes.
• Passing a valid but wrong-audience OAuth token through to another service.
• Relying on “the model should ignore that instruction” instead of isolating data and enforcing authorization in code.
• Logging complete prompts, arguments, or results and creating a second store of credentials or personal data.

Checklist

• [ ] Publisher, repository, package name, and release provenance are verified.
• [ ] Dependencies and executable versions are pinned and reviewed before updates.
• [ ] Current tool descriptions, schemas, and annotations have been inspected.
• [ ] Definition changes are detected and trigger renewed review.
• [ ] Permissions and credentials are scoped per server and per task.
• [ ] Remote requests enforce authentication and object-level authorization.
• [ ] OAuth issuer, signature, expiry, scopes, and audience are validated.
• [ ] Incoming access tokens are never passed through unchanged to downstream APIs.
• [ ] Local stdio commands, arguments, environment, and install scripts are reviewed.
• [ ] Local processes are sandboxed or restricted to the minimum filesystem and network access.
• [ ] Inputs and outputs are validated, bounded, and treated as untrusted.
• [ ] Sensitive or destructive actions require approval showing consequential parameters.
• [ ] Indirect prompt injection and cross-server data-flow cases are tested.
• [ ] Logs support incident reconstruction without storing secrets or unnecessary raw content.

FAQ

Is stdio automatically safer than HTTP?

No. It avoids exposing a network listener in a direct local setup, but it launches a local process with the launcher's privileges. Review and constrain that process. A proxy that spawns stdio children adds its own command-execution boundary.

Is a scanner enough to approve an MCP server?

No. Scanners can flag suspicious tool metadata or known patterns. They do not establish publisher trust, audit all executable code, prove runtime behavior safe, or prevent later definition changes.

Should an MCP server accept an access token with a different audience?

No. The server must accept only tokens issued for its resource. Pass-through of a token that was issued for another service breaks the resource boundary and can create a confused-deputy path.

Sources

• MCP Security Best Practices
• OWASP MCP Security Cheat Sheet
• Invariant Labs: MCP Security Notification—Tool Poisoning Attacks

Internal links

• Hub: AI development
• Related:
  • Prompt injection defense checklist
  • npm supply chain defense checklist
  • RAG data poisoning defense checklist

Disclaimer

General security guidance only. Review the current MCP specification and your client, identity provider, and deployment behavior before relying on a control.