MCP Security Best Practices (2026): Risks, OWASP Top 10 and Checklist

Short answer: MCP security best practices come down to five habits. Know every MCP server you run. Install only pinned, sandboxed servers from sources you trust. Enforce the spec’s OAuth rules, including audience checks and no token passthrough. Treat tool descriptions and tool outputs as untrusted input. Log every tool call so you can rebuild what an agent did. The rest of this guide shows why, with 2026 data and a checklist you can copy.

The Model Context Protocol (MCP) is now the default way AI agents reach tools and data, which makes it a new trust boundary. Published MCP vulnerabilities rose from 166 at the end of March 2026 to 748 at the end of September, according to an open dataset we analyse below.

This guide covers what changed in 2026, the OWASP MCP Top 10, our risk matrix and vulnerability map, key incidents and the controls to use. For the wider picture of protecting models, data and agents, see our enterprise AI security guide.

What is MCP security?

MCP is an open protocol that lets an AI application (the host) connect, through a client, to servers that expose tools (functions the model can run), resources (data) and prompts. A server might wrap a database, a code repository, a SaaS API or the local file system.

MCP security is the set of controls that decide which agent may call which tool, with which data and permissions, and how you prove afterwards what happened. The protocol itself does not provide this. The current specification states that tools “represent arbitrary code execution,” that tool descriptions should be treated as untrusted unless they come from a trusted server, and that “MCP itself cannot enforce these security principles at the protocol level.” Authorization is also optional: the authorization spec applies to HTTP transports, while local STDIO servers take credentials from the environment.

In practice, MCP server security is shared: the client validates what servers send, the server authenticates callers and limits its tools, and your organisation owns inventory, network policy, logging and response.

What changed in MCP security in 2026

Five developments since our August research draft change how you should approach MCP:

• A new spec revision (2026-07-28) made MCP stateless. Protocol-level sessions and the Mcp-Session-Id header are gone. Servers that need state now issue their own handles, passed as tool arguments. The security best practices page replaced “session hijacking” with “state handle hijacking”: a server must never treat possession of a handle as proof of identity.
• Client registration and token checks got stricter. The changelog deprecates OAuth Dynamic Client Registration in favour of Client ID Metadata Documents. Clients must now validate the iss parameter (RFC 9207) to block mix-up attacks, and must bind stored credentials to the issuing authorization server.
• The OWASP MCP Top 10 is still a beta. The project page says it is in “Phase 3 – Beta Release and Pilot Testing.” One entry was renamed: MCP06 is now “Prompt Injection via Contextual Payloads.”
• The NSA published MCP-specific guidance. Its May 2026 Cybersecurity Information Sheet warns that MCP’s “rapid proliferation has outpaced the development of its security model” and makes nine recommendations, from egress filtering to scanning networks for open MCP servers.
• Exploitation is confirmed. On September 2, 2026, CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog. The flaw in LiteLLM’s MCP Streamable HTTP endpoint let an unauthenticated attacker open an authenticated MCP session with any bearer token. It is the only entry in the November 3 catalog whose description mentions MCP.

What this means: Guidance written before mid-2026 is out of date on sessions and client registration. If your servers or SDKs still use session IDs, Dynamic Client Registration or the deprecated HTTP+SSE transport, put an upgrade on the roadmap and re-test authorization.

MCP vulnerabilities by the numbers

To see where real flaws land, we analysed the AKRENON MCP Security Vulnerabilities Dataset (version 2026.10.23, CC BY 4.0). It combines CVE, GitHub Advisory and OSV records and deduplicates them into 833 vulnerabilities in MCP servers, clients and SDKs published between May 2025 and October 23, 2026, plus 187 malicious-package reports.

Three numbers stand out: 80% of the findings were published from April 2026 onwards; 51.1% of rated findings are high or critical and 83.2% are network-exploitable; and 159 of the 187 malicious packages were on npm, 129 of them published in 2026. The dataset counts only published advisories, so treat every figure as a floor.

Our analysis: mapping 833 flaws to the OWASP MCP Top 10

We then assigned each vulnerability to one OWASP MCP Top 10 category using its CWE codes and summary text. Classes OWASP does not list got their own buckets. The method is described at the end of this article.

Two findings matter for defenders. Almost half of all published flaws are classic implementation bugs: missing authentication and command injection. And 30% fall into path traversal and server-side request forgery (SSRF), which have no dedicated OWASP MCP entry even though the spec’s own guidance covers SSRF in detail.

The flip side matters as much. Tool poisoning, prompt injection, shadow servers and missing telemetry barely show up as CVEs, not because they are rare but because they are design weaknesses with no single package to patch.

What this means: Patch management and a vulnerability scanner will catch the bugs in the top half of the chart. They will not catch tool poisoning or a developer’s unregistered server. You need both code hygiene and architectural controls.

The OWASP MCP Top 10, scored: our risk matrix

The OWASP MCP Top 10 is the most widely cited taxonomy for MCP risks. It does not rank or score the ten entries. So we scored each one on likelihood and impact (1 to 5) using November 2026 evidence: the advisory counts above, the CISA KEV listing, the NSA guidance and the incidents in the next section.

Tool poisoning scores lower on likelihood only because confirmed in-the-wild compromises are still rare. Its impact is top-tier, and models rarely resist it: the MCPTox benchmark found an attack success rate of 72.8% against o1-mini, and no model it tested refused more than 3% of attacks.

What this means: Start with the five red cells. Supply chain and command injection are the most likely ways an MCP deployment gets compromised today. Authentication, secrets and prompt injection decide how far an attacker gets once inside.

Real MCP incidents and CVEs, 2025 to 2026

The table below is our curated timeline of disclosures that shaped MCP security practice. Dates are publication or disclosure dates.

Even official and big-vendor code ships the basics wrong: the reference servers, the Python SDK and AWS’s own MCP server all appear above. A reputable publisher is not a security review.

MCP security best practices: 12 controls that work

These controls combine the MCP spec, the OWASP MCP Security Cheat Sheet, the NSA guidance and lessons from the incidents above.

1. Inventory every MCP server, and hunt for shadow ones

OWASP’s MCP09 describes “shadow MCP servers”: deployments spun up by developers or data teams outside security review, often with default credentials or open APIs. You cannot secure what you have not found.

Keep a register with each server’s owner, source, version, tools, data reached, scopes and logging status. Then look for the ones missing from it: search repositories and IDE configs for MCP SDKs, check endpoints and containers, and scan your network for open MCP listeners, as the NSA recommends. Give developers a fast approval path, or the shadow servers come back. Many AI governance tools now include agent and MCP inventories that can help here.

2. Install only pinned, verified servers

Most MCP compromises in 2026 arrived through package registries. Pin every server to an exact version and integrity hash. Prefer scoped package names from the publisher you mean: in June 2026, attackers registered unscoped names such as mcp-server-fetch and mcp-server-git to catch npx launches, according to OSV. Add a release-age delay, mirror approved packages internally and keep an SBOM. Review project-level MCP config files as executable code, because coding agents can start them when a folder is opened.

3. Sandbox every server with least privilege

A local STDIO server runs with the user’s permissions unless you stop it. The spec’s best practices say clients offering one-click setup must show the full command and get explicit approval, and should sandbox servers with minimal privileges. Use containers or OS sandboxes (seccomp, AppArmor, AppContainers), mount only the directories a server needs, and give each server its own non-admin account.

4. Implement authorization exactly as the spec says

For remote servers, the 2026-07-28 spec is precise. Authorization servers must implement OAuth 2.1. MCP servers must publish Protected Resource Metadata (RFC 9728). Clients must send the RFC 8707 resource parameter naming the server. Servers “MUST validate that access tokens were issued specifically for them” and “MUST NOT accept or transit any other tokens.” That last rule bans token passthrough. Tokens never go in query strings. Validate iss on authorization responses, and bind any state handle to the user ID from the verified token, not to whatever the client sends.

The AWS audience-validation CVE above shows how easily one of these checks gets skipped. Write a test for each rule.

5. Keep scopes small and step up when needed

Broad tokens turn small bugs into big breaches. The best-practices page warns against wildcard scopes such as files:* and publishing every scope in scopes_supported. Start with a minimal read-only set. When a tool needs more, return HTTP 403 with insufficient_scope and let the client step up. Split tools by effect, so read, write, send and delete are separate tools with separate scopes.

6. Defend against tool poisoning and rug pulls

Tool poisoning hides instructions in a tool’s description, schema or output, so the model does something the user never asked for. A “rug pull” is a trusted tool that changes after approval. The Deadbugz server behaved normally for three calls before it rewrote its metadata.

Record a hash of every approved tool definition (name, description, input and output schema). Compare it on every connection, and fail closed or require re-approval when it changes. Flag descriptions that address the model directly, mention other tools or ask for secrets. Use strict JSON Schemas that reject undeclared properties. Isolate servers so one cannot shadow another’s tools. The NSA notes that a trusted server’s capabilities can often change “without approval,” so make re-approval your rule, not the client’s default.

7. Treat every tool output as untrusted input

Prompt injection (MCP06) arrives through documents, web pages, issues, emails and tool results. Models cannot reliably tell data from instructions. Label external content, strip or neutralise instruction-like text where you can, and never let raw tool output trigger a privileged action without a policy check. Be most careful where one agent can read private data, see untrusted content and send data out at the same time. Remove at least one of the three.

8. Validate parameters and never build shell commands from model output

Command injection is joint-top in the advisory data. Use typed, allowlisted parameters. Call programs with argument arrays, never a shell string. Parameterise SQL. Canonicalise file paths and check them against an allowlist to stop traversal, the third-largest class in our map. The NSA’s advice is blunt: validate “every tool invocation” against schemas, expected ranges and context.

9. Lock down network egress and SSRF

SSRF made up 14.9% of published MCP flaws, including one in the reference fetch server. Route outbound traffic through an egress proxy that blocks private ranges, loopback and cloud metadata endpoints such as 169.254.169.254, and allows only the destinations a tool needs. The spec warns against hand-written IP validation, because attackers use octal, hex and IPv6 tricks that custom parsers miss. Validate each redirect hop. Bind local HTTP servers to localhost and check Origin and Host headers to stop DNS rebinding. That missing check was behind the MySQL MCP Server’s CVSS 10 rating.

10. Keep secrets out of model context and logs

Store credentials in a secret manager or OS keychain, never in config files, tool descriptions or prompts. Issue short-lived tokens per server and environment, and redact secrets from logs. When a malicious package is found, rotate everything the affected machine could reach: 2026’s worms went for npm, GitHub and cloud tokens first.

11. Require human approval for high-impact actions

The spec says hosts must get explicit consent before invoking any tool. At minimum, require it for sending messages, moving money, deleting data, changing permissions, pushing code and sharing data outside the company. Show the real tool, destination and arguments, not a model-written summary. An approval must come from the user interface, never from text the model generates. Platforms differ widely here, so compare approval controls when you choose among AI agent platforms.

12. Log every tool call and rehearse the kill switch

OWASP’s MCP08 asks for “detailed logs of tool invocations, context changes, and user-agent interactions with immutable audit trails.” A useful trace answers these questions: who asked, which client and server were used, which tool definition (by hash) was visible, what arguments were passed, what came back, whether approval was given, and what changed downstream.

The 2026-07-28 spec now documents OpenTelemetry trace context (traceparent) in request metadata, which makes end-to-end tracing easier. Send events to your SIEM, never log raw tokens, and test a playbook to disable a server, revoke its credentials and preserve evidence within minutes. Our enterprise AI agents coverage tracks how vendors are building these controls into agent products.

MCP OAuth in brief: the confused deputy problem

MCP OAuth (the authorization flow for remote servers) has its own classic attack. An MCP proxy server talks to a third-party API with one static client ID. An attacker registers a new client with a malicious redirect URI and sends the victim a crafted link. Because the third-party site remembers the earlier consent, it skips the consent screen, and the authorization code goes to the attacker.

The spec’s mitigation is specific. Proxies must keep a per-user registry of approved client IDs and show their own consent screen first, naming the client, scopes and redirect URI. Redirect URIs must match exactly. The state value must be random and single-use, expire in about ten minutes, and be set only after consent. Consent cookies need the __Host- prefix, Secure, HttpOnly and SameSite=Lax. We will cover MCP OAuth implementation in a separate, detailed guide.

MCP security checklist

For vendors that sell MCP gateways, scanners and agent security tools, see our ranking of top AI cybersecurity companies.

FAQ

What are the most important MCP security best practices?

Inventory every server, install only pinned and sandboxed servers, follow the spec’s OAuth rules, treat tool descriptions and outputs as untrusted, require approval for high-impact actions, and log every tool call.

Is MCP secure?

MCP is a protocol, not a security product. The specification itself says it cannot enforce security principles and leaves authorization optional. A well-built deployment can be secure, but published data shows many servers ship without authentication or input validation.

What is the OWASP MCP Top 10?

It is an OWASP list of the ten most critical MCP risks, from token mismanagement (MCP01) to context over-sharing (MCP10). As of November 2026 it is still a beta in pilot testing, so treat it as a strong reference rather than a final standard.

What is MCP tool poisoning?

Tool poisoning hides malicious instructions in a tool’s description, schema or output so that the AI model takes actions the user did not intend, such as reading SSH keys. Defend against it by pinning and hashing tool definitions, re-approving changes and limiting what tools can reach.

How do I find shadow MCP servers?

Search repositories and IDE configs for MCP SDKs and config files, check endpoints and containers, scan your network for open MCP listeners and review new OAuth clients. Pair discovery with a fast approval path.

What changed in the 2026 MCP specification?

The 2026-07-28 revision removed protocol-level sessions and made MCP stateless, deprecated Dynamic Client Registration in favour of Client ID Metadata Documents, required clients to validate the issuer (iss) in authorization responses, and documented OpenTelemetry trace propagation.

Methodology and sources

Vulnerability map. We downloaded the frozen AKRENON MCP Security Vulnerabilities Dataset, version 2026.10.23 (CC BY 4.0; 833 vulnerabilities and 187 malicious-package reports; we verified the published SHA-256 checksum). We gave each vulnerability one primary category, using the first match in this order: command injection, tool poisoning, prompt injection, supply chain, secret exposure, SSRF, path traversal, authentication and authorization, scope creep, information exposure, telemetry, denial of service, other. The CWE lists for each bucket are in our analysis script. The mapping is our own judgment, not an OWASP or AKRENON classification. The dataset covers published advisories only, so all counts are lower bounds.

Risk matrix. Likelihood: 5 means 100+ advisories or active campaigns, 4 repeated real-world cases or an insecure default, 3 research demonstrations or isolated cases. Impact: 5 means code execution or credential theft that spreads beyond the MCP host, 4 unauthorized data access or actions, 3 slower detection and response. Scores are editorial and will change as evidence changes.

Sources. MCP specification 2026-07-28 and its security best practices; OWASP MCP Top 10 and Cheat Sheet; NSA CSI (May 2026); CISA KEV (version 2026.11.03); CVE records; and the researcher disclosures linked above, all checked on November 4, 2026. Figures marked † are reported by the researcher and were not independently verified. This article is general information, not a substitute for a security assessment of your own deployment.