How to secure MCP servers

List every MCP server your people and agents connect to. Include servers that arrive through a project file checked into a repository, because anyone who clones that repository inherits the entry. For each one record the owner, whether it runs locally or remotely, the systems it can reach and the tools it exposes.

Split the tools into two groups: ones that only read, and ones that change something outside the model. The second group is where a mistake costs money or data, so it gets the strictest controls in the later steps. The specification itself says clients must treat tool annotations as untrusted unless they come from trusted servers, so do not accept a server's own claim that a tool is read-only. Check by reading the tool code or by testing against a copy.

Add a column for "can fetch external content". A server that reads web pages, tickets or email brings text you do not control into the model, which is the route for indirect prompt injection. Claude Code's documentation says the same thing in its warning: servers that fetch external content can expose you to prompt injection risk.

For HTTP transports the specification (revision 2026-07-28, the latest when we read it) builds on OAuth 2.1. The MCP server acts as an OAuth resource server and must implement OAuth 2.0 Protected Resource Metadata (RFC 9728). Clients use that metadata to find the authorisation server. Stdio servers are the exception: the specification says they should not follow this flow and should take credentials from the environment instead.

Two rules do most of the work. First, the client must send a resource parameter (RFC 8707) naming the MCP server in both the authorisation request and the token request. Second, the server must check that the token was issued specifically for it, and the specification states that servers "MUST NOT accept or transit any other tokens". Tokens go in the Authorization header on every request and never in the query string. Expired or invalid tokens get an HTTP 401.

If you build the server, validate the audience claim on every request before any tool code runs. If you only consume servers, ask the vendor how they validate audience, and prefer servers that publish the metadata document. Whichever side you are on, test the failure cases in the next step: the controls only count if a wrong token is actually refused.

Token passthrough is the shortcut where an MCP server accepts a token from the client and forwards it to a downstream API unchanged. The security best-practices page forbids it. It breaks audit trails (the downstream API cannot tell which client acted), skips controls that rely on the token audience, and lets a stolen token use your server as a proxy. The fix is plain: the server accepts only tokens issued for itself and, if it needs downstream access, obtains its own token for that API.

If you run an MCP proxy server that sits in front of a third-party API using one static OAuth client ID, you also face the confused deputy problem. The page describes the conditions: a static client ID, dynamic client registration by MCP clients, a consent cookie on the third-party authorisation server, and no per-client consent in the proxy. The attacker registers a client with a malicious redirect URI, sends the victim a crafted link, and the existing consent cookie lets the code flow to the attacker without a consent screen.

The required protections are specific. Keep a registry of approved client IDs per user and check it before forwarding to the third party. Show a consent page that names the client, lists the scopes and shows the registered redirect URI, with CSRF protection and anti-framing headers. Match redirect URIs by exact string, not by pattern. Generate a random single-use state value, and set the state cookie only after the user approves. Use the __Host- prefix and the Secure, HttpOnly and SameSite=Lax attributes on any consent cookie.

Broad scopes turn a leaked token into a skeleton key. The specification's guidance is progressive least privilege: start with a minimal set (it gives mcp:tools-basic as an example) covering low-risk discovery and read operations, and ask for more only when a privileged operation is first attempted.

On the server, use the WWW-Authenticate header to say what is needed for the operation in hand. A 403 with error="insufficient_scope" and the missing scope tells a compliant client to run a step-up authorisation. Include everything the operation needs in one challenge, so the user is not sent round the loop several times. Do not publish every scope you have in scopes_supported, do not use wildcard scopes such as * or all, and do not trust the scopes claimed in a token as a substitute for your own authorisation check on the resource.

Log each elevation with the scope requested, the subset granted and a correlation ID. Over a month those logs show which clients ask for more than they use, and which scopes users decline.

A local MCP server is a program that runs with your privileges. The specification lists how it goes wrong: a malicious startup command in a shared configuration, a malicious payload inside the server, or an insecure server left listening on localhost and reached through DNS rebinding. Its examples include a startup command that posts a private SSH key to a remote host.

The client-side rules are clear. If a client offers one-click setup it must show the exact command, untruncated, mark it as code execution, and require approval. Clients should flag patterns such as sudo, rm -rf, network calls and access outside expected directories, and run servers in a sandbox with minimal default privileges. As the person configuring clients, choose clients that do this, and keep project-level server files under code review like any other file that executes code.

If you write a local server, use the stdio transport so only the client can reach it. If you must use HTTP locally, require an authorisation token or use a Unix domain socket with restricted access. Do not leave an unauthenticated server on a localhost port.

Claude Code adds one control worth turning on knowingly: it asks for approval in interactive sessions before using project-scoped servers from a .mcp.json file. You can reset those approval choices with a command, which is useful after a repository changes hands.

Review each server once against the inventory from step 1, then enforce the result. In Claude Code, organisations can set allowedMcpServers and deniedMcpServers, by server name or by URL pattern, in managed configuration. Other clients have equivalents or can be fronted by a gateway that only forwards to approved servers.

Pin what you can. Record the exact package or image you approved, and re-review when it changes, because a server that changes its tool descriptions after approval changes what the model reads. The protocol lets servers announce changes to their tool list, so clients and gateways should surface a changed list for review instead of silently accepting it.

Prefix tool names with a server identifier where several servers are aggregated. The specification notes that two servers may both expose a tool called search, and recommends a disambiguation strategy such as prefixing. Without it, a hostile server can shadow a trusted tool.

The tools page says there should always be a human in the loop with the ability to deny tool invocations, and that clients should show tool inputs to the user before calling the server to avoid accidental or malicious data exfiltration. Apply that to the write-capable list from step 1: send, delete, pay, deploy, change permissions. Read-only tools on trusted servers can run without a prompt, but keep the log.

On the server, the specification says you must validate all tool inputs, implement access controls, rate-limit tool invocations and sanitise tool outputs. Check against the schema, not just the type: lengths, allowed values, path prefixes. A tool that takes a file path should resolve it and refuse anything outside its allowed directory. A tool that runs a query should use the caller's permissions, not the server's.

Clients should also validate results before passing them to the model and set timeouts on tool calls. A tool result is data from outside your trust boundary. Treat any instruction inside it as text to report, not an order to follow. The same applies to resource and prompt content that servers provide.

During OAuth discovery a client fetches several URLs that a malicious MCP server controls. The security page describes the result: a server can point those fetches at a cloud metadata address, an internal admin service or a local database, and the client acts as a proxy past your firewall.

Mitigations from the page: require HTTPS for OAuth URLs outside local development; block private, loopback and link-local ranges (it lists 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 and the IPv6 equivalents); validate redirect targets and consider disabling automatic redirects; and for server-side clients, route requests through an egress proxy. It names Smokescreen as an example. It also warns against writing your own IP validation, because encoding tricks defeat custom parsers, and notes DNS rebinding can change an address between check and use.

Apply the same egress thinking to the MCP server process. A server that only needs to reach one API should be allowed to reach one API, whether you enforce that with network policy, a proxy or a container profile.

The tools page asks clients to log tool usage for audit purposes, and the best-practices page asks servers to log scope elevations. Put both in one place. For each call record the time, the user or agent identity, the server, the tool, a hash or redacted copy of the arguments, the scopes on the token, the outcome and whether a person approved it.

Keep arguments out of logs where they may hold personal data or secrets, or store them with the same controls as the source system. Decide retention before you need it. A log nobody reads protects nobody, so set a review: weekly for new servers and write-capable tools, monthly for the rest. Look for tools called at odd hours, scopes requested but never used, and servers whose tool lists changed.

When you find a compromise, you need two things fast: a way to revoke the server's tokens and a way to disable it in the allow-list. Practise both once on a test server, so the first time is not during an incident.