MCP Server Security Checklist: 8 Steps Before You Go Live

In December 2025, Bitsight's TRACE research team scanned the internet and found roughly 1,000 exposed MCP servers with zero authorization in place - any stranger with a curl command could list their tools, query their databases, and pivot into whatever services those servers were wired to. One exposed server offered a pods_exec tool for running arbitrary commands inside a live Kubernetes cluster. Another had bulk_send_whatsapp. Another had execute_shell_command. Wide open.

MCP (Model Context Protocol) is the open standard Anthropic introduced in late 2024 to let AI assistants connect to external tools, APIs, and data sources. Think of it as a USB-C port for AI. That analogy is great for onboarding - and terrible for security intuition, because USB-C ports don't execute shell commands on your production database.

The protocol itself doesn't enforce authentication. It doesn't enforce authorization. (We dig into the MCP authentication gap - and the 41% of servers running wide open - in a dedicated post.) The NSA published a formal advisory on MCP security in May 2026 warning that "MCP adoption has outpaced security safeguards." That's the situation we're in. If you're about to push an MCP server live, this checklist is what stands between you and a very bad day.

---

💡 TL;DR - Key Takeaways

• MCP has no built-in auth. You must implement it yourself, every time.
• Use OAuth 2.1 with RBAC and short-lived, scoped tokens - never shared secrets.
• Validate and sanitize everything: inputs, outputs, tool metadata, and file paths.
• Enforce TLS 1.3 for all remote connections; use mTLS for service-to-service traffic.
• Run servers in isolated containers as non-root users with resource limits.
• Treat prompt injection and tool poisoning as first-class threats, not edge cases.
• Audit your supply chain: pin dependency versions, verify hashes, watch for post-adoption changes.
• Store secrets in a dedicated secrets manager (Vault, AWS Secrets Manager, Azure Key Vault) - never in code.
• Log everything, alert on anomalies, and have an incident response plan ready before go-live.

---

What Is MCP Server Security (and Why Does It Matter)?

MCP server security is the set of controls you put in place to protect a Model Context Protocol server - the component that bridges your AI model to real-world tools, APIs, and data sources - from unauthorized access, data exfiltration, and abuse.

It matters more than most API security because MCP servers operate with delegated user permissions, execute chained tool calls, and often hold credentials for multiple downstream systems. A single vulnerability doesn't just expose one endpoint - it can hand an attacker the keys to your database, your file system, your Kubernetes cluster, and every third-party API your AI is wired into.

The MCP spec is explicit: authorization is optional. That word has already caused hundreds of real-world exposures. Treating MCP security as an afterthought is not an option.

---

What Are the Biggest MCP Security Risks?

The threat landscape for MCP is broad. Here are the ten risks you need to understand before you touch a single config file:

Risk	What It Means
Prompt injection / indirect content injection	Malicious instructions hidden in tool outputs or fetched content steer the model into unsafe actions
Tool poisoning	Attackers manipulate tool descriptions or schemas to trigger harmful tool selection
Supply-chain compromise	Malicious or modified MCP servers published to registries, changed post-adoption ("rug pulls")
Confused deputy / privilege escalation	The MCP server acts with broader privileges than the user intended
Weak or missing authentication	MCP spec doesn't enforce auth; many implementations ship with none
Command injection & RCE	Unvalidated inputs to shell-executing tools open classic Remote Code Execution paths
Path traversal, SSRF, unsafe deserialization	Dangerous because MCP bridges sensitive internal systems
Credential / config exposure	Hardcoded secrets enable lateral movement into connected services
Tool name collisions & rogue servers	Attackers register similarly named tools or fake servers to intercept calls
Context poisoning & memory integrity attacks	Tainted shared context corrupts later tool decisions across an entire session

In 2025, the Supabase/Cursor incident showed prompt injection in the wild: an AI agent with service-role database access processed a support ticket containing hidden instructions and leaked sensitive integration tokens into a public thread. This isn't theoretical anymore.

---

Step 1: Enforce Strong Authentication & Authorization

The bottom line: MCP has no built-in auth. You must implement it yourself, and you must do it before anything else.

The official MCP specification recommends OAuth 2.1 - an open standard for secure, delegated authorization. Use it per-user, not as a shared token across your whole team. Shared tokens mean one compromised developer credential exposes everyone. (For a full implementation walkthrough, see MCP OAuth 2.1 with PKCE.)

What to implement:

• OAuth 2.1 with PKCE for all remote MCP server connections. Validate the redirect_uri with exact string matching - no wildcards, no pattern matching.
• RBAC (Role-Based Access Control) - give different users different permission levels. A read-only analyst should never hold a token that can delete records. (For the tool-by-tool approach, see per-tool access control.)
• Explicit token validation on every request: check the audience, claims, and expiry. Don't assume a token is valid because it arrived.
• Short-lived, scoped credentials only. Never long-lived shared secrets. Start with a minimal scope set (e.g., mcp:tools-basic) and escalate incrementally when privileged operations are first attempted.
• Least-privilege principle: request only the scopes the task actually needs. Broad tokens like files:* or admin:* massively expand your blast radius if one gets stolen.
• Bind session IDs to user-specific information (e.g., <user_id>:<session_id>) to prevent session hijacking and impersonation attacks.
• Never use sessions for authentication - the MCP spec explicitly forbids it.

⚠️ Token passthrough - where an MCP server accepts tokens from a client without validating they were issued for that server - is explicitly forbidden in the MCP authorization spec. It breaks audit trails, bypasses rate limiting, and enables lateral movement.

---

Step 2: Validate and Sanitize All Inputs and Outputs

The bottom line: Every input is potentially hostile. Every output is potentially tainted. Treat them both that way.

MCP servers often sit at the intersection of user input, model output, and real-world actions - file writes, database queries, shell commands, external API calls. That's exactly where injection attacks land.

What to implement:

• Strict schema validation on all incoming JSON-RPC requests. Reject malformed, unexpected, or out-of-range parameters before they reach any tool.
• Sanitize inputs for every action that touches files, databases, shell commands, or external services. Don't rely on the model to "know better."
• Treat ALL tool output as untrusted. Scan it for embedded instructions before it feeds back into the model's context. This is how indirect prompt injection works - the malicious payload lives in the response, not the request.
• Redact sensitive data from outputs. API keys, tokens, PII, and internal paths should never appear in tool responses that flow back to the model or the user.
• Maintain a strict tool allowlist. Only pre-approved, explicitly registered tools can run. If a tool isn't on the list, it doesn't execute - full stop.

---

Step 3: Secure Your Transport Layer

The bottom line: Unencrypted MCP traffic is a data exfiltration waiting to happen. Lock down your transport before you expose anything remotely.

What to implement:

• Enforce TLS 1.3 (the latest encryption standard for data in transit) for all remote MCP connections. No exceptions in production.
• Disable TLS 1.0 and 1.1 explicitly. These are deprecated and vulnerable to known downgrade attacks.
• Validate certificates strictly - no self-signed certs in production environments. Use a trusted CA.
• Use mTLS (mutual TLS) for service-to-service traffic. Regular TLS only verifies the server; mTLS verifies both sides, which matters when your MCP server talks to internal microservices.
• Block SSRF paths: validate all OAuth-related URLs fetched during discovery. Block requests to private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata endpoints (169.254.169.254) - a malicious MCP server can point these at your internal infrastructure.
• Don't expose MCP servers directly to the public internet unless you have a specific, justified reason. If you're running internal AI tooling, keep it on the internal network. Use the stdio transport type for local-only use cases - it eliminates the remote attack surface entirely.

---

Step 4: Harden Your Server Environment

The bottom line: Assume your MCP server will be compromised at some point. Hardening limits what an attacker can do when it happens.

This is classic defense-in-depth, applied to the MCP context. The goal is to shrink the blast radius.

What to implement:

• Run in containers, VMs, or sandboxes - isolated from the rest of your infrastructure. Platform-appropriate sandboxing (Docker, Firecracker, gVisor) limits filesystem and network access.
• Run as a non-root user inside containers. If a tool call triggers RCE, root access means game over. Non-root means the attacker is still contained.
• Enforce resource limits - CPU, memory, and API call rate caps. This prevents runaway loops, excessive API consumption, and DoS (Denial of Service) attacks triggered through tool abuse.
• Use read-only file systems where possible. If the server doesn't need to write to disk, don't let it.
• Apply secure boot or integrity checks to detect tampering with the server binary or configuration at startup.
• Keep sandboxing solutions up to date - 2025 saw real-world sandbox escape vulnerabilities in MCP-related components. Patching matters.

---

Step 5: Defend Against Prompt Injection & Tool Poisoning

The bottom line: Prompt injection is the most creative and hardest-to-detect attack vector in the MCP threat model. You can't fully prevent it - but you can make it much harder to exploit.

The Supabase/Cursor incident is the canonical real-world example: hidden instructions in a support ticket caused an AI agent with privileged database access to leak sensitive tokens. The attack surface is anywhere the model ingests external content. (We break down prompt injection attacks and the defenses against them in depth.)

What to implement:

• Never trust tool descriptions or metadata from external or unverified sources. Tool names, descriptions, and schemas can all carry injected instructions. Treat them as untrusted input. (See how tool poisoning attacks hijack agent behavior through exactly this channel.)
• Implement prompt injection detection - filters that flag suspicious instruction patterns in tool outputs, fetched documents, or user-provided content before it enters the model's context.
• Require human-in-the-loop approval for high-impact actions: deletes, modifications, payments, privilege escalations. If the model wants to do something irreversible, a human should confirm it.
• Maintain a strict tool allowlist - only pre-vetted, explicitly registered tools can be invoked. This directly counters tool poisoning and tool name collision attacks.
• Monitor tool invocations for anomalous patterns - unexpected tool calls, unusual sequences, or calls to tools the user never explicitly requested are red flags.
• Keep system prompts strictly separated from user content and external data. Context from different sources should be isolated, not blended into a single undifferentiated prompt.

💡 MCP security best practices from OWASP's Practical Guide for Secure MCP Server Development (February 2026) specifically call out chained tool calls as a high-risk pattern - each link in the chain is another injection surface.

---

Step 6: Secure Your Supply Chain

The bottom line: The MCP ecosystem is growing fast, and not every server in a registry is safe. Supply-chain attacks are already documented - treat every third-party MCP server as a potential threat until proven otherwise.

The "rug pull" attack is specific to MCP: a server looks legitimate when you first adopt it, then gets modified post-adoption with malicious tool definitions. Your host never notices because the name and registry entry look the same.

What to implement:

• Verify the integrity of every MCP server and package before use - check cryptographic hashes and signatures. Don't install from a registry and assume it's clean.
• Only use MCP servers from trusted, audited registries. Evaluate the maintainer, the commit history, and the security posture before connecting it to anything sensitive.
• Watch for rug pulls - monitor third-party MCP servers for unexpected changes to tool definitions, descriptions, or schemas after initial adoption.
• Pin dependency versions. Never use floating versions like "latest" or "^1.x". Pin to an exact version and review the diff before upgrading.
• Regularly audit third-party MCP servers for changes - automated dependency scanning tools like Dependabot or Socket can help catch suspicious updates.
• Prefer well-maintained, actively supported servers with a clear security disclosure process. Abandoned projects are a supply-chain risk waiting to happen.

---

Step 7: Manage Secrets and Credentials Properly

The bottom line: Hardcoded secrets are the fastest path from "MCP server compromised" to "entire infrastructure compromised." Don't do it.

MCP servers often hold credentials for databases, external APIs, and cloud services. If those credentials are in a config file, an environment variable baked into a container image, or a .env file committed to git, they're one breach away from becoming an attacker's pivot point.

What to implement:

• Never hardcode secrets, API keys, or passwords in source code, config files, or Dockerfiles. This includes .env files that get committed to version control.
• Use a dedicated secrets manager: HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Fetch secrets at runtime, not at build time.
• Rotate credentials regularly - and immediately after any suspected exposure. Rotation is cheap. Incident response is not. (See token rotation for how short-lived, rotated tokens shrink the blast radius of a leak.)
• Apply least-privilege to service accounts connected to your MCP server. A database service account that can only SELECT from specific tables is far less dangerous than one with full admin rights.
• Audit credential access logs - who accessed which secret, when, and from where. Anomalies in access patterns are often the first signal of a compromise.

---

Step 8: Monitor, Log, and Respond

The bottom line: You can't respond to what you can't see. Comprehensive logging and real-time alerting aren't optional - they're the difference between catching an attack in progress and discovering it six months later in a breach notification.

The NSA's May 2026 advisory specifically calls out logging and monitoring as a core MCP security control. The protocol's flexibility - chained tool calls, dynamic tool registration, delegated permissions - creates a lot of surface area that's invisible without instrumentation.

What to implement:

• Enable detailed logging for all tool calls, authentication events, authorization decisions, and errors. Every tool invocation should produce a log entry with the caller identity, timestamp, parameters (redacted of sensitive values), and outcome. (Our guide to audit logging details the exact fields to capture per invocation.)
• Set up real-time alerting for anomalous behavior: unusual tool invocations, authentication failures, sudden spikes in API calls, or calls to high-risk tools outside normal usage patterns.
• Conduct regular security audits and penetration testing - at least quarterly for production MCP servers. The threat landscape is evolving fast; your defenses need to keep up.
• Have an incident response plan ready before go-live. Know exactly who gets paged, what gets isolated, and how credentials get rotated when something goes wrong. Don't write the playbook during the incident.
• Review logs regularly - don't just collect them. Automated log analysis (SIEM integration, anomaly detection) helps surface signals that manual review would miss.
• Integrate MCP logs with your existing security monitoring stack. MCP tool calls should be visible alongside your other infrastructure events, not siloed in a separate system.

---

Quick Reference: MCP Server Security Checklist Table

Step	What to Do	Why It Matters
1. Authentication & Authorization	OAuth 2.1, RBAC, short-lived scoped tokens, explicit token validation	MCP has no built-in auth; unprotected servers are trivially exploitable
2. Input & Output Validation	Schema validation, input sanitization, output scanning, tool allowlist	Prevents injection attacks across all tool execution paths
3. Transport Security	TLS 1.3, disable TLS 1.0/1.1, mTLS for internal traffic, block SSRF paths	Encrypts data in transit; prevents interception and SSRF pivots
4. Environment Hardening	Containers, non-root user, resource limits, read-only filesystem	Limits blast radius when (not if) something goes wrong
5. Prompt Injection Defense	Distrust tool metadata, injection filters, human-in-the-loop for high-impact actions	Prompt injection is already being exploited in production environments
6. Supply Chain Security	Verify hashes/signatures, pin versions, audit third-party servers	Rug pulls and supply-chain attacks are documented MCP-specific threats
7. Secrets Management	Secrets manager (Vault/AWS/Azure), no hardcoded secrets, regular rotation	Credential exposure enables full infrastructure pivot
8. Monitoring & Response	Full tool-call logging, real-time alerting, IR plan, regular audits	You can't respond to what you can't see

---

FAQ: MCP Server Security

What is MCP server security?

MCP server security is the practice of protecting a Model Context Protocol server - the bridge between an AI model and external tools, APIs, and data sources - from unauthorized access, abuse, and exploitation. Because MCP servers execute real-world actions with delegated user permissions, a compromised server can affect every system it's connected to.

What are the most common MCP server vulnerabilities?

The most common vulnerabilities are missing or weak authentication (the MCP spec makes auth optional, and many servers ship without it), prompt injection (malicious instructions hidden in tool outputs or fetched content), tool poisoning (manipulated tool metadata that steers the model into harmful actions), and credential exposure (hardcoded API keys and secrets that enable lateral movement). Bitsight found ~1,000 exposed MCP servers with no authorization in December 2025.

Does MCP have built-in security?

No. The MCP specification explicitly states that authorization is optional. It recommends OAuth 2.1 as a best practice, but it doesn't enforce any authentication, authorization, input validation, or transport security. Every security control must be implemented by the server operator. This is the core reason MCP security requires deliberate, explicit effort.

How do I prevent prompt injection in MCP?

There's no single silver bullet, but the most effective combination is: treat all tool output as untrusted and scan it for embedded instructions before it re-enters the model's context; maintain a strict tool allowlist so only pre-vetted tools can run; require human approval for high-impact actions; and separate system prompts from user and external content so injected instructions can't masquerade as system-level commands. Monitoring tool invocations for anomalous patterns also helps catch attacks in progress.

What authentication method should I use for MCP servers?

Use OAuth 2.1 with PKCE for remote MCP servers. Issue short-lived, scoped tokens per user - never shared long-lived secrets. Validate every token explicitly on every request: check the audience, claims, and expiry. Implement RBAC so users only hold the permissions their role requires. The MCP spec forbids using sessions for authentication, and token passthrough (forwarding client tokens to downstream APIs without validation) is also explicitly prohibited.

How often should I audit my MCP server security?

At minimum, quarterly penetration testing for production MCP servers, plus automated dependency scanning on every deployment. Given how fast the MCP threat landscape is evolving - the NSA published its first MCP security advisory in May 2026, less than 18 months after the protocol launched - you should also review your security posture whenever the MCP spec updates or a new class of vulnerability is publicly disclosed. Don't wait for an incident to find out your controls are stale.

---

Conclusion

MCP is genuinely powerful. The ability to give an AI model structured, auditable access to real-world tools is one of the most significant developments in applied AI right now. But that power comes with a security surface that most teams are still underestimating.

The eight steps in this checklist aren't theoretical hardening exercises. They're responses to real attacks - exposed servers, stolen tokens, prompt-injected agents, and supply-chain rug pulls - that are already happening in the wild. The NSA noticed. OWASP noticed. The teams running those ~1,000 exposed servers in December 2025 probably noticed too, just too late.

Go through this checklist before you go live. Not after. Treat MCP security as a first-class engineering requirement, not a post-launch cleanup task.

---

Useful Sources

• MCP Security Best Practices - Model Context Protocol Official Docs
• NSA Cybersecurity Information Sheet: MCP Security Design Considerations (May 2026)
• Exposed MCP Servers Reveal New AI Vulnerabilities - Bitsight TRACE Research (December 2025)
• A Practical Guide for Secure MCP Server Development - OWASP Gen AI Security Project (February 2026)
• MCP Security Risks and Mitigations - SOC Prime
• Model Context Protocol: Understanding Security Risks and Controls - Red Hat
• MCP Attack Vectors - Palo Alto Networks Unit 42
• SlowMist MCP Security Checklist - GitHub