MCP Security Checklist

Knowing which servers you run, what they expose, and when that changes.

• You choose which MCP protocol revisions are allowed instead of accepting SDK defaults, and the version in use shows up in your logs.
• Each server has a written baseline of the tools, resources, and prompts it is expected to expose.
• When a server starts advertising new or changed tools, they are reviewed before the agent can call them. Guards against a 'rug pull', where a trusted server quietly changes what a tool does after you approved it.
• Every MCP client and server is in an inventory, and the identity each one claims is checked against it.

How clients and servers talk to each other, locally and over the network.

• Local, single-user servers talk over stdio instead of opening a network port.
• Remote servers are reachable over TLS only; plaintext HTTP is refused.
• HTTP servers check the Origin header on every request. Without this, a malicious web page can use DNS rebinding to reach a server listening on localhost.
• Authentication still holds when traffic passes through proxies and gateways, and routing headers are checked against the request body so they can't be spoofed.

Who the agent is, and what it is allowed to do on whose behalf.

• Local server credentials come from environment variables or the OS keychain, never hard-coded in config files. §3.1
• Remote servers use OAuth 2.1 / OIDC or short-lived tokens rather than long-lived static API keys. §3.1
• Access is decided per tool and per requesting user, not granted to the whole server at once. This is the core defense against confused-deputy attacks, where the agent acts with more authority than the user holds. §3.2
• The server never forwards the client's token to downstream APIs; it uses its own credentials for those calls. §3.2
• Labels a server puts on its own tools (such as 'read-only' or 'destructive') are never used to grant access or skip human approval. A server can describe its tools however it likes. Treat those labels as claims, not facts. §3.2
• Tokens are bound to the specific MCP server they were issued for, so a stolen token can't be replayed against another service. §3.3
• OAuth discovery metadata is fetched over TLS, and only authorization servers on an approved list are trusted. §3.3
• Each tool or server has its own downstream service identity; no service account is shared between them. §3.3
• OAuth scopes start small and are raised only when a task actually needs more. §3.3
• Servers that proxy OAuth to a third party under one shared client ID collect consent for each client, so one approval can't be reused by another. §3.3

Consent, human oversight, and what the host application lets servers touch.

• A tool can't run until the user consents or it is on a pre-approved allowlist. §4.1
• Server definitions that ship inside a repo or project are never started automatically; a person reviews and approves them first. A server definition is a command your machine will run. Cloning a repo shouldn't mean agreeing to run it. §4.1
• When a server asks the user for information, the user can see which server is asking, and sensitive fields are protected. §4.1
• When a server asks the client's model to generate text, the user approves it and sensitive context is redacted. §4.1
• A person can deny any tool call, and high-impact actions wait for confirmation that shows the real parameters, not a model-written summary. §4.1
• Filesystem access is limited to the folders the task needs, enforced by the operating system rather than by the app alone. §4.2
• Local servers start with only the environment variables they need, not your full shell environment and its secrets. §4.2
• Links and resource addresses from a server are not opened in a browser or OS handler unless the scheme and destination are allowed. §4.2
• Interactive UI that servers provide (MCP Apps) runs sandboxed with a strict Content Security Policy, and its permission requests are denied by default. §4.3

How the server validates input, handles requests, and contains side effects.

• Tool, resource, and prompt inputs are validated against declared schemas before anything runs. §5.1
• Change notifications from the server are rate-limited so they can't flood the client. §5.2
• A session ID is never treated as proof of who the caller is; every request is authorized on its own. §5.2
• In stdio mode, logs go to stderr or a file and never mix into the protocol stream. §5.3
• Tools can't reach files outside their allowed directories; '../' tricks and absolute paths are blocked. §5.4
• Long-running tasks can only be checked or collected by whoever started them, and they expire. §5.5
• Tools with side effects require an idempotency key, so a retried request can't pay, send, or delete twice. §5.6

What reaches the model, where secrets live, and where servers can connect.

• The model only gets the context it needs for the current step, and content types are handled as declared.
• Credentials are stored securely on both the client and server side, and never pass through the model's context.
• Servers that fetch external content go through an egress proxy with approved DNS resolvers and a destination allowlist.

Being able to see, after the fact, exactly what happened.

• Every tool call and connection event is logged with who made it, what was asked, and the outcome. §7.1
• Audit records carry request IDs and trustworthy timestamps, so events can be correlated and put in order. §7.1
• Tokens presented with the wrong audience or issuer raise an alert, not just a rejection. §7.2
• Unusual patterns of cancellations or progress updates are monitored as possible signs of abuse. §7.2

Where your MCP servers come from, and how you know they haven't changed.

• Before anyone installs an outside MCP server or connector, it passes a security review, and only approved ones are allowed.
• Outside servers are locked to an exact build you have checked by its hash, and a new version is reviewed again before it replaces the old one.
• Server packages are installed from an internal mirror rather than pulled straight from public registries.

Limiting the blast radius if a server is compromised or misbehaves.

• Network-facing servers are isolated in their own container or virtual machine with minimal permissions, and a gateway controls what traffic reaches them.
• The operating system kernel, not the server code, limits which directories each server can touch (for example AppArmor, SELinux, or container mounts).
• Local servers run under a low-privilege account or sandbox, not with your full user permissions.

Keeping costs, load, and cached data under control.

• Only safe, static content is cached, with expiry; one user's data is never served from a shared cache.
• Hard caps exist for payload sizes, model token spend, and how much any one user can consume.

Good practice beyond the Benchmark's domains: treat retrieved content and tool output as untrusted.

• Retrieved content and tool output are treated as untrusted input that can carry injected instructions.
• System instructions are kept separate from user- and tool-supplied content.
• Untrusted content can't silently change which tools are called or with what arguments.