MCP security best practices have become non-negotiable for any team running AI agents in production. The Model Context Protocol is now the default way LLMs talk to tools, files, databases, and APIs. That convenience comes with real risk. Knostic researchers scanned nearly 2,000 publicly accessible MCP servers and found that every single verified instance granted access to internal tool listings without any authentication. 

Backslash Security identified another pool of servers bound to all interfaces (0.0.0.0), many configured in ways that would allow arbitrary code execution. If your AI agents touch sensitive systems, the practices below decide whether you ship safely or get breached. 

The threat model: what you are actually defending against

Get the threats straight before the checklist. MCP introduces six attack patterns worth naming:

1. Confused deputy attacks through proxy servers acting with server privileges instead of user privileges.
2. Tool poisoning and rug pulls, where a malicious server changes a tool description after install to inject prompts.
3. Token passthrough abuse, where servers accept tokens not issued for them.
4. Credential theft from environment variables or logs.
5. SSRF during OAuth metadata discovery, exploiting URLs in protected resource metadata.
6. Supply chain attacks on the MCP server or its dependencies.

Every practice below maps back to one or more of these.

10 MCP Security Best Practices

1. Treat every MCP server as untrusted

No exceptions for community servers. Pin versions. Check signatures. Keep a registry of approved servers and block everything else at the host level.

2. Use OAuth 2.1 with strict token audience validation

The June 2025 spec revision formalized the separation: MCP servers are officially classified as OAuth Resource Servers, and the authorization function belongs to a dedicated authorization server. Servers must reject any token not issued for that specific MCP server. 

3. Stop the confused deputy with per-client consent

MCP proxy servers must maintain a registry of approved client_id values per user, check this registry before initiating the third-party authorization flow, and store consent decisions securely. The consent page must show the client name, scopes, and redirect URI. Add CSRF protection with the state parameter and block iframing with frame-ancestors CSP. 

4. Scan tool descriptions for prompt injection

Tool descriptions are model input. A malicious server can embed instructions inside a description to hijack the agent. Scan descriptions at install time and at every server update. Reject silent changes.

5. Store credentials in a vault, not environment variables

Recent analysis of more than 5,000 open-source MCP servers revealed that over half relied on static secrets, while only a small fraction used OAuth for downstream connections. The LLM should never see a secret. Use short-lived tokens scoped per service with automatic rotation. 

6. Sandbox tool execution

Run each tool with the minimum permission set required. Containerize. Apply seccomp, AppArmor, or gVisor for syscall filtering. Block outbound network access for tools that do not need it.

7. Validate every input against a strict JSON schema

JSON-RPC’s simplicity makes it easy to layer new commands or tools, but it also introduces risk because it lacks built-in authentication or encryption by default. Validate types, ranges, lengths, and formats on every tool call. 

8. Log every tool call with full context

Without observability, incident response is guesswork. Log the prompt, the tool invoked, the arguments, the response, the user, and the session. Forward to a SIEM. Alert on high-frequency calls, unexpected tools, and large data egress.

9. Require human approval for high-risk actions

MCP currently lacks out-of-the-box, human-in-the-loop workflows for critical actions. Build it yourself. Any action that writes, deletes, sends money, or touches production data needs explicit user approval. Default to deny. 

10. Apply supply chain controls

Cryptographic signing of MCP server packages. Version pinning. SBOM tracking. Dependency scanning with Trivy or Grype. Verify package integrity before any update reaches production.

The Quick Audit Checklist

Before any MCP server goes live, your team should answer yes to all of these:

• OAuth 2.1 with audience-bound tokens
• Per-client consent stored server-side
• Tool descriptions scanned and version-locked
• Secrets in a vault, never in env vars
• Tools sandboxed with least privilege
• JSON schema validation on every call
• Full logging with SIEM forwarding
• Human approval gates for destructive actions
• Signed packages and dependency scans
• mTLS for all non-stdio transport

Conclusion 

MCP security moves faster than most security teams can read specs. Your team needs hands-on practice with the actual attack patterns: confused deputy exploitation, tool poisoning, SSRF in OAuth discovery, and credential theft from real MCP server code.

That is what the Certified MCP Security Expert (CMCPSE) course covers. Browser-based labs, hands-on exercises, and a practical exam where you find and fix MCP vulnerabilities in a live environment. No theory dumps. No multiple-choice trivia. Your team walks away with the skills to audit and secure any production MCP setup.

FAQs

Varun is a Security Research Writer specializing in DevSecOps, AI Security, and cloud-native security. He takes complex security topics and makes them straightforward. His articles provide security professionals with practical, research-backed insights they can actually use.