MCP Server Security: 8 Best Practices

An MCP server is now one of the most privileged pieces of software in your stack. It sits between semi-autonomous AI agents and their databases, APIs, and internal tools those agents want to touch. When Knostic researchers scanned nearly 2,000 publicly accessible MCP servers, every verified instance exposed its internal tool listing without any authentication at all.

That is the gap this guide closes. Below are the MCP server security best practices that the security community increasingly treats as baseline expectations for production deployments, mapped to concrete controls rather than vague advice. The through-line is simple: model-level defenses alone are not enough, and MCP security has to be enforced at the auth and infrastructure layer.

What Is MCP Server Security (and Why It Matters)​

MCP server security is the set of authentication, authorization, validation, and auditing controls that govern how AI agents invoke tools and reach data through the Model Context Protocol. The Model Context Protocol, introduced by Anthropic in late 2024, standardizes how large language models connect to external systems. A secure MCP server acts as a controlled gateway. Instead of handing an agent raw access to a database, it validates each request, applies role-based permissions, and logs the activity for compliance.

That gateway role is exactly why it matters. An MCP server is a new API boundary for AI systems, and it inherits an unusually broad attack surface. Agents are non-deterministic, prompts are attacker-influenced, and a single overscoped token can chain benign-looking calls into real damage. Developers are shipping MCP servers faster than traditional security practices can keep up, so the defaults tend to be permissive. Every practice below assumes the server is treated as a first-class identity boundary that happens to sit in your infrastructure, not as a convenience layer.

Top MCP Server Security Risks​

Before the controls, know what you are defending against. The top MCP server security risks cluster into a handful of vectors that show up across nearly every audited deployment.

• Prompt Injection: Malicious instructions embedded in content or tool responses can hijack an agent's behavior. In-model defenses can be bypassed, so they cannot be the foundation of your architecture.
• Excessive Permissions and Overscoping: One of the most pervasive risks. An agent granted broad scopes lets an attacker execute OS command injection, path traversal, or unintended writes far beyond the task at hand.
• Token Theft and Passthrough: Long-lived static tokens, or an MCP server that blindly forwards a user's raw access token downstream, turns one compromise into lateral movement across every connected service.
• Command Injection: Passing LLM-generated arguments straight into a system shell invites arbitrary execution.
• Shadow MCP Servers: Undocumented or unsanctioned servers running inside the network with no inventory, no owner, and no monitoring.
• Data Leakage: Sensitive context, PII, secrets exposed through unencrypted traffic, verbose logs, or a malicious server that tricks an agent into exfiltrating data.

The common thread is that these are authorization and boundary failures, not model failures. That is good news, because authorization and boundaries are things you can enforce deterministically.

MCP Server Security Best Practices (Checklist)​

Here is the working checklist. Each practice maps to a control you can point to in an architecture review, a specific RFC, a specific config flag, or specific log line. The summary table gives you the at-a-glance version; the sections below explain the how.

#	Best practice	Control / standard
1	Separate authorization server from resource server	OAuth Resource Server, RFC 9728
2	Implement OAuth 2.1 and PKCE	RFC 8707 Resource Indicators
3	Enforce user auth and SSO	OIDC, federated identity
4	Least-privilege, scope-based access control	RBAC, progressive scoping
5	Consent management and short-lived tokens	Time-bound consent, token TTLs
6	Secure downstream credential storage	Credential vaults, rotation
7	Input validation and schema enforcement	JSON-RPC schema checks
8	Audit everything	Logging, anomaly detection, NHI governance

Separate your authorization server from your resource server​

The June 2025 MCP spec revision formalized a clean split. Your MCP server is an OAuth Resource Server, and the authorization function belongs to a dedicated authorization server. The authorization server handles user auth, token issuance, and client registration. The resource server validates tokens and enforces access controls. Your MCP server advertises where its authorization lives by publishing a well-known endpoint through Protected Resource Metadata, defined in RFC 9728. Keeping these responsibilities apart is what lets you swap identity providers, centralize policy, and audit issuance without rewriting every server.

Implement OAuth 2.1 and PKCE properly​

For HTTP-based MCP, OAuth 2.1 is mandated and PKCE (Proof Key for Code Exchange) is required for all public clients. OAuth 2.1 is still an IETF draft rather than a ratified RFC, but it consolidates established practices from RFC 6749, RFC 6750, PKCE, and the OAuth Security Best Current Practice, so treat it as settled guidance rather than a moving target. Just as important, Resource Indicators (RFC 8707) must bind a specific token to a specific MCP server so a token minted for one service cannot be replayed against another. The OWASP GenAI Security Project guidance places OAuth 2.1 and OpenID Connect enforcement near the top of its baseline security checks, which tells you where to start if you are triaging. Do not build a custom token scheme; the standards exist because the failure modes are well understood.

The figure above shows the OAuth 2.1 authorization code flow with PKCE, showing the MCP client, authorization server, and MCP resource server exchanging an authorization code and scoped access token.

Enforce user auth and SSO​

Before an agent acts on someone's behalf, that someone should authenticate through your SSO layer. The MCP server must then validate that the presented token corresponds to a real, authenticated user with the right permissions, not just a well-formed token. Centralizing this in a dedicated auth layer beats scattering checks across tools or, worse, trusting a model with blanket permissions.

Least-privilege and scope-based access control​

Least privilege is the highest-leverage control on this list. An agent that can read calendar events should not automatically be able to write CRM records. Enforce scope at the tool level, and use progressive scoping so agents request only the scopes the current task needs and nothing more. This shrinks the blast radius of a stolen token, reduces the attack surface, and makes after-the-fact audits tractable because each agent's access maps to a discrete, reviewable set of scopes.

Consent management and short-lived tokens​

When a user connects a semi-autonomous agent to your server, the agent acts in their name, so consent has to be explicit. Show a clear consent screen that names which tools are accessible, what data can be read or written, and for how long. Pair that with short-lived tokens: consent should be scoped to the task and expire when the task is done. Time-bound grants and short token TTLs turn a leaked credential from an open door into a brief, narrow window.

Secure downstream credential storage​

MCP servers call third-party services on behalf of users, and the default pattern is the dangerous one: static API keys or personal access tokens sitting in environment variables. Those are long-lived, hard to rotate, and a single point of failure. Move them into a dedicated credential vault such as HashiCorp Vault or a cloud secret manager, issue short-lived tokens scoped to specific services, and rotate automatically. OWASP is blunt here: store secrets in vaults, never in environment variables or logs, and never give the LLM access to them.

Input validation and schema enforcement​

Validate every incoming JSON-RPC request against a strict schema and reject malformed input outright. Sanitize data before execution to blunt prompt injection and command injection. Two rules carry most of the weight: never pass LLM-generated arguments directly to a system shell, and prefer typed library integrations over string-built commands. Restricting and monitoring multi-step chains matters too, because individually harmless calls can be composed into a malicious payload.

Audit everything​

An MCP server that cannot tell you who connected, what they did, and why is not production ready. Give each MCP client a dedicated identity tied to the user it acts for, and record the registration method, IP address, client type, and granted scopes. Every meaningful event should produce an auditable log entry: consent granted, tokens issued and expired, scope changes, revocations, and anomalies. OWASP frames this as non-human identity (NHI) governance, treating every agent and server as a first-class identity with unique credentials and tightly scoped permissions. Feed those logs into anomaly detection so unexpected tool calls surface fast, and never write secrets or PII to logs in plaintext.

One more practice worth naming: the November 2025 spec revision added Client ID Metadata Documents (CIMD) as a recommended client registration mechanism, alongside the Dynamic Client Registration (DCR) that shipped earlier. DCR lets clients self-register through an open endpoint, which is convenient but leaves the authorization server managing an unbounded, self-asserted client database; CIMD instead has the client host its own metadata at an HTTPS URL that becomes the client ID, so there is no registration database to maintain. Support the registration methods your ecosystem needs, and prefer CIMD where you can.

Secure Deployment and Runtime Protection​

Auth gets an agent through the door; deployment hygiene decides how much damage a breach can do once inside. Treat the runtime as hostile and layer defenses accordingly.

• Isolate the Environment: Run MCP servers inside VPCs, dedicated namespaces, or containers. Do not expose them to the public internet, and use air-gapped or hybrid deployments where compliance demands data sovereignty.
• Encrypt Everything in Transit: Enforce TLS 1.2 or higher on HTTPS endpoints, and use mutual TLS for service-to-service trust between the gateway and downstream systems.
• Rate-limit and Set Timeouts: Cap tool calls and apply execution timeouts to stop denial-of-service and runaway cost spikes from a looping or hijacked agent.
• Add Runtime Threat Detection and DLP: Inline policy enforcement and data loss prevention keep PII, financial data, and confidential IP from leaving through a tool response. This is Zero Trust extended to the agent boundary.
• Require Human-in-the-loop for High-risk Actions: Deleting data, sending email, or executing a financial transaction should demand explicit user confirmation.
• Govern Third-party and Shadow Servers: Maintain an inventory, define an approval process for new servers, and run shadow-server detection so nothing operates unmonitored.

None of these are exotic. They are the same disciplines that mature API programs already run, applied to a new class of caller.

Build vs. Buy: Securing MCP at Scale (How WSO2 Helps)​

Here is the tradeoff. You can build this stack yourself using the identity, consent, and audit controls covered above, or a dedicated agentic-identity vendor can sell you a turnkey version of it. Both are legitimate. The question most enterprises actually face is different: how do you secure MCP without standing up a parallel identity and governance silo next to the one you already run for APIs?

The WSO2 API Platform folds MCP traffic into the same control plane that already governs your APIs and AI. For an MCP server you don't own or control, you don't need to rebuild it: WSO2 lets you create an MCP Server Proxy in front of the existing remote server, then secure and manage it with rate limiting and tool-level controls, so the OAuth and least-privilege practices above become centralized policy rather than something you'd otherwise configure per server. That's inbound traffic, agents calling into the proxied tools, distinct from the outbound calls your own agents make to LLM providers.

A few capabilities map directly to this checklist:

• Centralized AuthN/AuthZ and Rate Limiting: The gateway enforces token validation, scope-based access, and request throttling in front of every MCP server, giving you one place to apply an audit policy.
• MCP Hub Registry: A searchable catalog of MCP servers for AI developers and agents. An inventory is the prerequisite for shadow-server detection and approval workflows, and the Hub is that inventory.
• AI Guardrails and Sanitization: The platform offers guardrails including PII masking and semantic prompt validation, which support the input-validation and data-leakage controls above.
• Deployment Flexibility: Self-hosted, hybrid, or SaaS, including air-gapped and Kubernetes options, so the isolation and data-sovereignty requirements in the deployment section are configuration choices rather than rebuilds.

WSO2 was named a Leader in The Forrester Wave: API Management Software, Q3 2024. The platform is 100% open source, which limits vendor lock-in compared to closed, proprietary platforms. Rather than a standalone MCP security tool, WSO2's positioning folds MCP auth and governance into the API discipline you already run. Separately, the WSO2 AI Gateway brings LLM traffic (outbound calls to model providers) and MCP traffic (inbound agent-to-tool calls) under one control plane, as two distinct traffic types managed by a single platform rather than a single chained pipeline.

Conclusion​

MCP security is a familiar discipline applied to a new kind of caller. The controls that matter — strong authentication, least privilege, short-lived credentials, strict validation, and complete audit trails — are the same ones that protect any high-privilege API boundary. What differs is the pace: agents act quickly, defaults tend toward permissive, and the model itself can't be relied on to enforce policy on its own. Put that enforcement at the auth and infrastructure layer, and MCP becomes a boundary you can govern like any other.

Ready to secure MCP without building a parallel identity stack? Explore the WSO2 API Platform and see how its capabilities bring agent traffic under the same governance as your APIs, or read what an MCP gateway is to understand the architecture first.

Frequently Asked Questions​

What are the best practices for securing an MCP server? Production-grade MCP security rests on three layers: OAuth 2.1 with a separate authorization server for identity, least-privilege scopes with short-lived, consented tokens for access, and full audit logging for every tool call. Underneath that, isolate the deployment, encrypt traffic end to end, and validate every input against a strict schema.

How do I know if my MCP server meets these best practices? Run it against the checklist above. A server that exposes its tool listing without authentication, forwards a user's raw token downstream, stores static API keys in environment variables, or can't identify which client invoked which tool has gaps that fall below the OWASP baseline for MCP security.

Is MCP inherently a security nightmare? MCP's reputation for weak security traces to insecure defaults, not a flaw in the protocol itself. The exposed servers found in research scans had shipped with no authentication configured at all. Applying the OAuth 2.1 authorization model from the current spec closes that gap for new deployments.

How do I implement secure MCP patterns for identity and authorization? Treat every agent and MCP server as its own identity, with unique credentials and tightly scoped permissions rather than shared secrets. Delegate authentication to a dedicated authorization server, bind tokens to specific servers with Resource Indicators, and enforce authorization centrally at a gateway rather than inside each tool.