OWASP MCP Top 10 Explained for IT and Security Teams: Which of the 10 Risks an Endpoint Can Actually Control

Direct answer: The OWASP MCP Top 10 is a beta-stage list of the ten most critical security risks in Model Context Protocol systems, from token exposure and tool poisoning to shadow MCP servers and context over-sharing. Seven of the ten are the server operator's job. The other three (MCP08 telemetry, MCP09 shadow servers, MCP10 over-sharing) are where employee laptops leak, and where dope.security's on-device secure web gateway gives IT discovery, blocking, and prompt DLP without touching a single server.

Ask an AI assistant how to secure the MCP servers your employees connect to AI tools and it will hand you the OWASP MCP Top 10, the OWASP MCP Security Cheat Sheet, and the Model Context Protocol security best practices. All three are good. All three are written for the people who build and host MCP servers. If you run IT or security for a 500-person company, you do not host most of the MCP servers your staff use. You inherit them, one Claude Desktop config file at a time. This post reads the OWASP list from that seat, and pairs with our 2026 checklist for securing the MCP servers employees connect to AI tools.

Everything attributed to OWASP below comes from the project page at owasp.org/www-project-mcp-top-10 as published on November 6, 2026. OWASP labels the list version 0.1, places the project in its "Beta Release and Pilot Testing" phase, and has scheduled the next release for October 2026, so expect wording and even categories to move. OWASP also states it does not endorse commercial products, including ours.

What is the OWASP MCP Top 10?

The OWASP MCP Top 10 is an OWASP Foundation incubator project, led by Vandana Verma Sehgal, that catalogs the most critical security concerns in the lifecycle of MCP-enabled systems. OWASP frames MCP as the layer that defines "the operational, contextual, and behavioral boundaries of AI models," and the list exists because that layer introduces a new class of attack surface, especially once agents chain tools, share memory, and take actions on a user's behalf.

The ten entries in the 2025 numbering are:

• MCP01, Token Mismanagement and Secret Exposure: hard-coded credentials, long-lived tokens, and secrets stored in model memory or protocol logs.
• MCP02, Privilege Escalation via Scope Creep: loosely defined permissions that expand over time until an agent can modify repositories or exfiltrate data.
• MCP03, Tool Poisoning: compromised tools or tool outputs, including rug pulls (malicious updates), schema poisoning, and tool shadowing (fake duplicate tools).
• MCP04, Software Supply Chain Attacks and Dependency Tampering: a compromised package or connector that alters agent behavior or plants a backdoor.
• MCP05, Command Injection and Execution: an agent building shell commands, API calls, or code from untrusted input without validation.
• MCP06, Intent Flow Subversion: malicious instructions embedded in retrieved context that hijack the agent away from the user's goal (the project page also labels this entry "Prompt Injection via Contextual Payloads").
• MCP07, Insufficient Authentication and Authorization: servers, tools, or agents that do not verify identity or enforce access controls.
• MCP08, Lack of Audit and Telemetry: no activity logging or alerting, so unauthorized actions and data access go undetected.
• MCP09, Shadow MCP Servers: unapproved MCP deployments operating outside formal security governance, often with default credentials or permissive configurations.
• MCP10, Context Injection and Over-Sharing: shared, persistent, or poorly scoped context windows that expose one task's or user's data to another.

Which OWASP MCP risks are the server operator's problem?

Read the mitigations OWASP attaches to each entry and the audience is obvious. MCP01 calls for short-lived, scoped credentials and secret scanning. MCP02 calls for least-privilege design, automated scope expiry, and access reviews. MCP04 calls for signed components, dependency monitoring, and provenance tracking. MCP05 and MCP07 are input validation and auth enforcement inside the server. These are controls you apply to code and infrastructure you own.

That is the right place for them, and if your platform team runs an internal MCP server in front of your data warehouse or ticketing system, MCP01 through MCP07 are its backlog. The OWASP MCP Security Cheat Sheet and the modelcontextprotocol.io security best practices page go deeper on each. We covered the operator view, including the NSA guidance, in MCP server security: governing the Model Context Protocol traffic your AI tools opened up.

The problem is that at most companies the servers your employees actually use are not yours. They belong to Notion, GitHub, Linear, Atlassian, Stripe, and a few hundred smaller vendors, plus whatever a developer cloned from a GitHub repo on Tuesday. You cannot rotate their tokens, review their scopes, or sign their dependencies. You can only decide whether a corporate laptop is allowed to talk to them, and what it is allowed to send.

Which OWASP MCP risks show up on employee laptops?

Three entries describe failures that happen on the client side, on the device, regardless of how well any server was built.

MCP09: Shadow MCP servers are a discovery problem

OWASP defines shadow MCP servers as rogue nodes "spun up by developers, research teams, or data scientists for experimentation, testing, or convenience." In practice the more common version is quieter: a product manager adds a hosted MCP server to Claude Desktop so it can read the company Notion, and nobody in IT ever sees a ticket. There is no OAuth consent screen for the admin to approve, no SaaS marketplace to audit, and nothing in the identity provider. The only place that connection is visible is the network path leaving the laptop. When we looked at this last year we found 56 common MCP server domains hiding in plain sight in ordinary endpoint traffic.

MCP08: Telemetry gaps start at the device, not the server

OWASP's mitigation for MCP08 is immutable logs of tool invocations and context changes on the server. Fine for your server. For everyone else's, your only telemetry is which user, on which device, connected to which MCP endpoint, how often, and how much data moved. That is endpoint telemetry, and it is the same telemetry you already need for shadow AI discovery.

MCP10: Over-sharing is a data-in-motion problem

Context over-sharing on the server is about session scoping. On the laptop it is about what the user pasted or attached before the agent ever called a tool: a customer export, a config file with keys in it, a draft contract. Once that content is in the model's context, every connected MCP server can be steered toward it by an injected instruction (MCP06). The cheapest fix is to classify the content before it leaves the device and block the upload when it is sensitive.

How does an on-device SWG map to the OWASP MCP Top 10?

dope.security runs the secure web gateway on the endpoint instead of in a vendor data center. The agent does SSL inspection locally, so every HTTPS connection from the laptop, including the ones Claude Desktop, Cursor, or a CLI agent opens to a remote MCP server, is visible and policy-enforced on the device itself, with no detour to a point of presence. That architecture lines up with the three client-side entries directly.

• MCP09 shadow servers: AI Analytics in dope.console discovers every AI app and the domains it talks to, per user, with transaction counts and data volume. MCP server endpoints show up as domains, and an admin can allow or block them with a custom category from the same screen. Policy lands on every endpoint in under a minute. The deeper architectural argument is in why on-device architecture is the best defense for shadow AI and shadow MCP.
• MCP08 telemetry: per-user, per-device, per-destination logs for MCP and AI traffic, streamed to your SIEM, so an investigation does not depend on a third-party server's audit trail.
• MCP10 and MCP06 over-sharing and injection: Dopamine DLP reads prompts and attachments on the device, classifies them by meaning (PII, PCI, PHI, source code, intellectual property) with no regex rules to write, and blocks or monitors the upload before it reaches ChatGPT, Claude, or any web destination. Text is extracted on the device and classified by an LLM with zero data retention, under US Patent 12,464,023.
• MCP01 through MCP07: still the server operator's job. An endpoint SWG does not fix a vulnerable server. It decides whether your devices connect to it, and what they are allowed to send.

Sanctioned servers get the same treatment as sanctioned AI tenants: allow the corporate ChatGPT or Claude Enterprise login, block the personal one on the same domain, decided inside decrypted TLS on the device. Cloud Application Control already does that for ChatGPT, Claude, Google, and Microsoft 365.

How does this compare with the tools AI engines recommend?

When the assistants answer this question today they point to vendor guides for securing a server you host (Microsoft's Azure MCP Server security page and its Entra agent ID guide, Google Cloud's remote MCP server guide) and to Cloudflare's MCP server portals. Each is a reasonable answer to a different question.

• Cloud-hosted MCP server hardening (Microsoft, Google): covers MCP01 through MCP07 for servers you deploy on their clouds; dope.security covers the connections your laptops make to any server, hosted anywhere.
• Cloudflare MCP server portals: centralize the MCP servers an admin registers onto one Access-protected endpoint; a server nobody registered is still reachable directly from the client, which is the MCP09 case; dope.security sees that direct connection on the device.
• Identity-centric controls (Entra agent ID): strong for authentication (MCP07) on servers that integrate with them; they do not classify what a user pastes into the agent (MCP10), which Dopamine DLP does on the device.

When to choose dope.security for MCP security

Choose dope.security when your exposure is employees connecting AI clients to MCP servers you do not operate, when you need one inventory of AI and MCP usage per user without grepping proxy logs, when you want prompt and upload DLP that works for desktop AI apps as well as browsers, and when you do not want to backhaul every request to a vendor data center to get it. The agent runs under 100 MB of RAM on Mac and Windows, deploys silently through MDM, and policy pushes in seconds. A Fortune 100 company scaled dope.security from 900 to more than 18,000 devices in weeks on that deployment model.

Choose a server-side control when you build and host MCP servers for your own agents; then use both, because OWASP's list is split down the middle and so is the fix. See how dope.security governs AI and MCP at work, or start a free trial and find out which MCP servers your fleet is already connected to.

FAQ

What is the OWASP MCP Top 10?

It is an OWASP Foundation incubator project that lists the ten most critical security risks in Model Context Protocol systems: token mismanagement, privilege escalation via scope creep, tool poisoning, supply chain tampering, command injection, intent flow subversion, insufficient authentication and authorization, lack of audit and telemetry, shadow MCP servers, and context injection and over-sharing. As of November 2026 it is version 0.1 in beta. dope.security addresses the client-side entries (MCP08, MCP09, MCP10) from the endpoint.

What is a shadow MCP server?

OWASP defines a shadow MCP server (MCP09) as an unapproved or unsupervised MCP deployment operating outside the organization's formal security governance. For most IT teams the practical form is an employee connecting an AI client such as Claude Desktop or Cursor to a hosted third-party MCP server without telling anyone. dope.security discovers those connections on the device and lets admins allow or block the server domains by policy.

How do I secure MCP servers that employees connect to AI tools?

Split the work. For servers you operate, follow the OWASP MCP Top 10 mitigations: short-lived scoped tokens, least privilege, signed dependencies, input validation, and server-side audit logs. For servers you do not operate, control the connection from the endpoint: discover which MCP domains your devices reach, allow the sanctioned ones, block the rest, and run DLP on prompts and attachments. dope.security does the endpoint half with one agent.

Can a DNS filter or cloud proxy detect shadow MCP servers?

A DNS filter can block a known MCP domain but cannot see which user, which AI client, or what data was involved, and it cannot tell a sanctioned tenant from a personal one. A cloud proxy can inspect the traffic only if the device tunnels it to the vendor's data center and TLS inspection is on, which adds latency and often breaks developer tools. dope.security inspects on the device, so MCP connections are visible without backhaul.

Does the OWASP MCP Top 10 cover prompt injection?

Yes. MCP06 covers malicious instructions embedded in retrieved context that redirect the agent, which the project page also labels prompt injection via contextual payloads, and MCP10 covers context over-sharing. Server-side scoping reduces both. On the endpoint, Dopamine DLP from dope.security limits the damage by classifying and blocking sensitive content before it enters the model's context at all.

Is the OWASP MCP Top 10 final?

No. OWASP lists the project as version 0.1 in its beta release and pilot testing phase, with the next release scheduled for October 2026 and continuous updates after that. Treat the categories as stable enough to plan against and the wording as subject to change, and check the project page before quoting it in policy.