AIAI Toolbox
Submit a tool
AI SECURITY

MCP Security Checklist: How to Review Servers, Clients, and Tools

A practical security review for Model Context Protocol integrations, from install commands and OAuth boundaries to tool approval and recovery.

By AI Toolbox Team··12 min read

Secure an MCP integration by treating every server as code and every tool as an authority boundary: verify the server and install command, isolate the process, grant narrow data and action scopes, use the protocol’s authorization requirements for remote HTTP, validate tokens and destinations, require approval for consequential tool calls, and log enough context to revoke access and investigate incidents.

Key takeaways

  • MCP standardizes context and tool exchange; it does not make an unknown server trustworthy
  • A local stdio server runs as a process with the user or host’s effective privileges unless additional isolation exists
  • Remote HTTP deployments need correct OAuth resource and audience validation, not token passthrough
  • Scopes, filesystem roots, network access, and tool schemas should be minimized independently
  • Session identifiers are not authentication and every authorized inbound request still needs verification
  • High-consequence actions need deterministic policy and human approval outside model-generated reasoning

Model the authority before reviewing the protocol

MCP uses a host-client-server architecture to expose resources, prompts, and tools to an AI application. Resources provide context; tools can retrieve information or take actions. That separation is useful, but a protocol label is not a trust certificate. Security starts with the code that runs, the identity it uses, the systems it can reach, and the actions the host allows a model to request.

Draw the path from user to host, client instance, MCP server, downstream API, and target data. For each boundary, record authentication, authorization, data classification, network route, storage, logs, and failure handling. Separate read from write and reversible from irreversible operations. A calendar lookup, a draft email, and a sent email should not share one undifferentiated permission merely because one server offers all three.

The MCP architecture expects a host to coordinate connections, enforce security policies and consent, and maintain boundaries between servers. Treat those as implementation responsibilities to verify. Ask whether one compromised server can influence another server’s context, whether tool results are treated as trusted instructions, and whether the model can chain low-risk permissions into a high-impact outcome.

Review local servers as software installation

A local stdio server is a program launched by the client. If it runs under a person’s normal account, it may inherit access to files, environment variables, credential helpers, local sockets, and the network. The official security guidance therefore tells clients offering one-click configuration to show the exact command, identify the risk, require explicit approval, and allow cancellation. It also recommends sandboxing and restricted filesystem and network access.

Before installation, verify the publisher, repository, release provenance, dependency chain, package name, version, and command. Prefer a pinned version or digest over an unbounded latest package. Expand wrappers and scripts so the reviewer can see what executes. Watch for shell operators, downloads at startup, privilege elevation, writes outside an expected directory, and commands that transmit local data.

Run the server with the least capable identity practical. Give it only named project directories, deny home-directory access by default, remove inherited secrets, and allow only required network destinations. A server that needs a repository should not automatically receive browser profiles, SSH keys, cloud configuration, and every neighboring project. Reassess permissions and provenance at every update rather than treating the first approval as permanent.

Implement remote authorization as a resource boundary

For protected remote HTTP servers, the MCP authorization specification builds on OAuth conventions. The client sends bearer access tokens in the Authorization header, not the query string, and the server validates each inbound request. Tokens must be intended for the MCP server as their audience. HTTPS is required for authorization endpoints, redirect URIs must be exact and protected, and public clients use PKCE to protect authorization codes.

Token passthrough is explicitly forbidden. An MCP server that calls a downstream API acts as a separate OAuth client to that API and uses a separate token issued for the downstream resource. Forwarding the inbound client token unchanged breaks audience boundaries, weakens audit trails, and can turn the server into a confused deputy. Validate issuer, audience, expiry, signature, and required scopes with tested libraries, then make a server-side authorization decision for the requested tool.

Design narrow, comprehensible scopes. Do not request files:*, db:*, or admin:* at installation because a future workflow may need them. Begin with low-risk discovery or read scopes and elevate only when a specific action requires it. Keep the consent screen tied to the requesting client, destination, exact scope, and redirect URI. Store tokens in protected storage, rotate refresh tokens where required, and ensure logs never contain credentials.

Validate discovery, sessions, tools, and resources

OAuth discovery introduces network input. A malicious server can point metadata, authorization, or token endpoints toward internal services or cloud metadata addresses. The MCP security guidance calls out server-side request forgery: clients should enforce production HTTPS, restrict private and reserved destinations, validate redirects at every hop, and consider controlled egress. Use established URL and IP parsing rather than handwritten string checks that miss encoding or DNS-rebinding tricks.

Sessions support continuity but must not become identity. The official guidance says authorized servers must verify every inbound request and must not use session IDs for authentication. Generate unpredictable identifiers, expire or rotate them, and bind stored session state to the authorized user. In horizontally scaled deployments, prevent one tenant’s events or resumable stream data from entering another tenant’s session.

For every resource URI and tool call, validate structure, authorization, size, and destination. Schemas improve shape checking but do not enforce business meaning. A tool argument that is valid JSON can still name an unauthorized file, dangerous shell fragment, external recipient, or excessive payment. Apply deterministic allowlists, path boundaries, row-level authorization, rate limits, and output encoding after model generation and before the effect occurs.

Put meaningful approval at consequential boundaries

A generic ‘allow tool’ prompt is not meaningful approval. The person should see the action, target, relevant fields, identity, data leaving the system, and whether the change is reversible. Require a fresh decision for sending messages, publishing, deleting, changing permissions, spending money, exposing secrets, or crossing a data boundary. Do not allow tool-supplied text or untrusted documents to rewrite the approval policy.

Separate planning from execution. The model can prepare a proposed action, but trusted code should calculate the final parameters, enforce policy, and create a stable preview. Bind approval to that exact request so later model output cannot substitute a different recipient or amount. Expire approvals quickly, prevent replay, and demand stronger authentication for unusually sensitive operations.

Where review would be constant and low-value, narrow the action until it is safe to automate: write only to a staging table, create drafts rather than send, operate below a small limit, or restrict changes to reversible fields. Autonomy should grow from observed reliability and containment, not from a persuasive demonstration.

Operate for detection, revocation, and recovery

Logs should reconstruct who authorized which client, server, tool, and effect without recording secrets or unnecessary sensitive content. Capture correlation IDs, sanitized arguments, policy decisions, scope elevation, downstream status, duration, and failure class. Alert on new tools, scope changes, repeated denials, unusual destinations, excessive calls, unexpected process launches, and large data movement.

Set maximum request duration, steps, retries, output size, rate, and spend. Cancellation must stop downstream work where possible, not merely stop displaying progress. Retries need idempotency keys or duplicate detection for actions such as messages, tickets, payments, and file writes. Define circuit breakers that disable a server or tool independently when behavior changes.

Practice offboarding before production: remove the server, revoke its tokens, rotate any exposed downstream credential, invalidate sessions, preserve evidence, identify completed actions, and roll back what can be reversed. Track server versions and tool definitions so unexpected capability changes trigger review. MCP is evolving; pin the protocol and SDK behavior you tested, monitor official security guidance, and repeat the threat model when transport, authorization, or tool surfaces change. This checklist is documentation-based analysis, not a penetration test of any named product.

Practical checklist

  • Record the server owner, source repository, version, package digest, install command, and update channel
  • List every tool, resource, prompt, filesystem root, network destination, credential, and downstream API
  • Run local servers with a dedicated identity or sandbox and deny unnecessary filesystem and network access
  • For remote HTTP, use HTTPS, PKCE, exact redirect URIs, secure token storage, and audience-bound tokens
  • Reject token passthrough and give downstream APIs separate credentials issued for that resource
  • Validate tool arguments, resource URIs, OAuth discovery URLs, redirects, outputs, and authorization on every request
  • Require preview and approval for messages, publication, payment, deletion, permission changes, or secret access
  • Set time, step, rate, spend, and output-size limits plus safe cancellation and retry behavior
  • Log actor, server, tool, sanitized arguments, authorization decision, result, and correlation ID without logging secrets
  • Test revocation, server removal, credential rotation, rollback, and incident containment before production

Warning signs

  • A copied configuration executes a long or obfuscated shell command that nobody reviewed
  • The server requests a home directory, broad drive, database, or administrator scope for a narrow feature
  • One bearer token is accepted by the MCP server and forwarded unchanged to another API
  • An HTTP server binds broadly, accepts unvalidated origins, or uses plaintext outside loopback development
  • A session ID is treated as proof of identity or authorization
  • Tool descriptions promise safety but no deterministic validation or approval gate enforces it
  • Logs contain authorization headers, access tokens, refresh tokens, secrets, or raw sensitive payloads
  • The team cannot disable one server or revoke one integration without disrupting unrelated systems

Frequently asked questions

Is MCP itself secure?

MCP defines protocol behavior and authorization requirements, but security depends on the client, host, server, identity system, tool implementation, permissions, and deployment. A conforming connection can still expose an unsafe tool or overly broad credential.

Are local MCP servers safer than remote servers?

They remove some remote network concerns, but a local server is executable code with access determined by its process privileges. Verify its source and command, sandbox it, restrict filesystem and network access, and update deliberately.

Should an MCP server receive a user’s API token?

Only when the credential design is appropriate for that server and resource. For remote OAuth, the server must validate tokens issued specifically for it and must not forward the inbound token unchanged to a downstream API.

Does user approval make every tool call safe?

No. Approval helps only when the person can understand the exact action and consequences. Clients and servers still need schema validation, authorization, least privilege, business rules, limits, logging, and rollback.

What should an MCP security review cover first?

Start with authority: what process runs, which identity it uses, what it can read or change, where it can send data, and which actions happen without another approval. Then review protocol and operational controls.

Primary sources and further reading

Research before you rely.

AI products, prices, policies, and capabilities change. Verify consequential details with primary sources and test tools using representative work.