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:
- Confused deputy attacks through proxy servers acting with server privileges instead of user privileges.
- Tool poisoning and rug pulls, where a malicious server changes a tool description after install to inject prompts.
- Token passthrough abuse, where servers accept tokens not issued for them.
- Credential theft from environment variables or logs.
- SSRF during OAuth metadata discovery, exploiting URLs in protected resource metadata.
- 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
MCP security is the set of controls protecting Model Context Protocol servers, clients, and hosts from confused deputy attacks, prompt injection, credential theft, supply chain compromise, and unauthorized tool execution.
Yes, for any non-stdio MCP server exposed over a network. The June 2025 spec revision made OAuth 2.1 with proper token audience separation the standard.
Public, unauthenticated MCP servers. Multiple security firms have found thousands of production servers with no auth and overbroad permissions.
Standard API security still applies. MCP adds prompt injection through tool descriptions, model-driven tool selection, and chained tool calls that amplify the blast radius of any single weakness.
