MCP Server Security Checklist for Developers

The Model Context Protocol lets an AI client call your tools and read your data through a small server. That convenience is also a liability: every primitive you expose is something an attacker can try to reach through the model. An MCP server is production software, and it deserves the same threat modeling you would give any public API.

This checklist pulls together the guidance in the MCP specification with recent findings from the Cloud Security Alliance and OWASP. Work through it before you connect a server to real credentials or ship it to a marketplace. The items run from the highest-impact controls down to operational hygiene.

The core checklist

If you do nothing else, do these. Each item closes a hole that has been exploited in real MCP deployments, and none of them requires exotic tooling.

Treat this as a pre-flight list and confirm every line before your server touches a real token or a real user's data:

• Validate the audience of every incoming token and reject any token that was not issued for your server. The MCP specification bans token passthrough for exactly this reason.
• Require explicit user consent before a dynamically registered client can act on someone's behalf, so your server never becomes a confused deputy.
• Generate non-deterministic, unguessable session IDs and bind each session to a verified user identity rather than to the session string alone.
• On HTTP transports, validate the Origin and Host headers and block outbound requests to internal addresses such as the cloud metadata endpoint at 169.254.169.254 to stop SSRF.
• Never build a shell command from unsanitized model input on a stdio server, which is the classic command-injection path.
• Pin and review tool definitions so a server cannot silently swap a harmless description for a malicious one after you have approved it.

Authentication and the confused deputy

Most serious MCP incidents start at the auth boundary. A server that accepts any bearer token, or that forwards a token it received to a downstream API, hands an attacker a way to borrow someone else's authority. The specification is blunt about this: a server must only accept tokens minted for itself, and must not pass tokens through to other services.

When your server sits in front of an OAuth provider it can become a confused deputy that acts with more privilege than the caller should have. The fix is consent and audience checks, enforced at the edge. A minimal hardening profile for a Streamable HTTP server looks like this:

# Streamable HTTP MCP server hardening (env)
BIND_ADDRESS=127.0.0.1            # never 0.0.0.0 on a shared host
ALLOWED_ORIGINS=https://app.example.com
REQUIRE_AUTH=true                 # close the optional-auth gap
TOKEN_AUDIENCE=mcp.example.com    # reject tokens minted for anything else
BLOCK_INTERNAL_IPS=169.254.169.254,127.0.0.1,::1  # stop SSRF to metadata

Transport-specific risks

The two common transports fail in different ways, so the controls differ too. Know which one you are running and defend it accordingly.

• stdio servers run as a local subprocess, so the main risk is command injection: any place you interpolate model output into a shell or SQL string is a target.
• According to the Cloud Security Alliance, command injection through stdio servers is one of the most common MCP flaws found in the wild.
• HTTP servers are reachable over the network, so they inherit web risks: SSRF, missing origin checks, and session hijacking through predictable identifiers.
• Run every server with least privilege. A tool that only needs to read one directory should not have write access to the whole disk or the network.

Supply chain: tool poisoning and rug-pulls

The tools an MCP server advertises are instructions the model will trust, and that trust is the attack surface. In a tool-poisoning attack a description carries hidden instructions; in a rug-pull a server behaves well during review and swaps in malicious behavior later.

According to OWASP GenAI's Q1 2026 exploit round-up, prompt-injection and tool-poisoning techniques against agent tooling are being actively catalogued, not treated as theoretical. Handle any third-party MCP server the way you would an unvetted dependency: pin its version, review its tool definitions, and re-review on update.

Operational hygiene

The last layer is the boring one that saves you at 3 a.m. These controls do not stop a specific exploit; they limit blast radius and make incidents visible.

• Log every tool call with its arguments and outcome, and keep those logs somewhere the model cannot edit them.
• Store secrets outside the code in environment variables or a secret manager, never in the tool definitions the model can read.
• Rate-limit and set timeouts on every tool so a runaway agent cannot exhaust a downstream service or your budget.
• Keep dependencies patched and monitor advisories, since a vulnerable transport library undoes every control above it.

MCP security is not exotic; it is ordinary application security applied to a new kind of caller. Validate tokens, bind sessions, guard your transport, distrust third-party tools, and log everything. Run this checklist once before launch and again on every dependency bump, and most of the MCP crisis headlines stop being about you.