How to Secure MCP Servers That Employees Connect to AI Tools: A 2026 Checklist (NSA, OWASP and the Endpoint)

Short answer: To secure the MCP servers employees connect to AI tools, you need two layers: harden the servers you run (OAuth 2.1 with audience-bound tokens, least-privilege scopes, sandboxed tool execution, signed and logged tool calls, as the NSA and the MCP specification recommend) and govern the servers you do not run, which is most of them. dope.security handles the second layer: its on-device agent sees every outbound MCP connection from Claude Desktop, Cursor, VS Code or any other client on the laptop, attributes it to a user and a process, lets you allow approved MCP endpoints and block unknown ones, and runs Dopamine DLP on the data an AI tool sends through them.

The NSA's Artificial Intelligence Security Center published its Cybersecurity Information Sheet on the Model Context Protocol on May 20, 2026, and its summary is blunt: established cyber defense strategies do not adequately address the new risks MCP introduces, and the problems are not isolated ones that can be patched at the interface or endpoint level. OWASP now maintains a dedicated MCP Top 10. Between the two, there is a clear checklist for the servers you operate. What neither covers is the hundred MCP servers your employees have already wired into their AI clients without telling anyone, which is where this post picks up and where governing MCP traffic from the endpoint comes in.

What is an MCP server, and why do employees connect them to AI tools?

The Model Context Protocol is an application-level protocol that lets an AI client (Claude Desktop, ChatGPT, Cursor, Copilot, a custom agent) call tools and read data from a server over a standard messaging format. An MCP server might expose a GitHub repo, a Jira project, a Postgres database, a Google Drive, a Slack workspace or a company's internal API. Employees add them because they make the AI useful: an engineer connects the repo and the ticket tracker, an analyst connects the warehouse, a marketer connects the CMS.

Each connection is an integration with real credentials and real data access, created in a client config file on a laptop, with no change ticket. The NSA notes that MCP is now in production use for sensitive tasks including querying personally identifiable information. The OWASP MCP Top 10 lists Shadow MCP Servers (MCP09) as a category of its own: unapproved MCP deployments operating outside formal security governance. Shadow MCP is the shadow IT problem, one layer down.

What are the main security risks of MCP servers?

Drawn from the OWASP MCP Top 10, the MCP specification's security best practices, and the NSA's May 2026 guidance:

• Token mismanagement and secret exposure (MCP01): long-lived tokens and API keys stored in client config files, model memory or logs.
• Privilege escalation via scope creep (MCP02): a server granted broad scopes such as files:* or admin:* up front, so one stolen token reaches everything.
• Tool poisoning (MCP03): a compromised or malicious server feeds misleading tool descriptions or outputs that steer the model.
• Command injection (MCP05): the agent builds and runs commands from untrusted input returned by a tool.
• Prompt injection via context (MCP06): data a tool returns contains instructions the model follows.
• Insufficient authentication and authorization (MCP07): unauthenticated remote servers, token passthrough, and the confused-deputy attack on MCP proxy servers that the specification describes in detail.
• Lack of audit and telemetry (MCP08): no record of which tool was invoked, by whom, with what.
• Shadow MCP servers (MCP09) and context over-sharing (MCP10): servers nobody approved, and persistent context leaking one user's data to another.

Researchers filed more than 30 CVEs against MCP servers, clients and infrastructure in January and February 2026 alone, according to Cycode's analysis of the OWASP list. The protocol is young and the implementations are younger.

How do you secure the MCP servers you run? (The server-side checklist)

If your company hosts MCP servers for employees or customers, this is the baseline the NSA and the specification set out.

• Authenticate every remote server. Use OAuth 2.1 with PKCE. Never expose an unauthenticated MCP endpoint on a network; coverage of the NSA guidance singles this out as a critical finding.
• Validate token audience and never pass tokens through. The specification forbids token passthrough outright: a server must reject any token not explicitly issued to it, or it becomes a confused deputy for downstream APIs.
• Minimize scopes. Start with a low-risk discovery scope and step up only when a privileged tool is first called. Do not publish wildcard or omnibus scopes.
• Implement per-client consent on proxy servers. If your server fronts a third-party API with a static client ID, show your own consent screen per registered client, validate redirect URIs with exact matching, and use single-use OAuth state values.
• Sandbox tool execution. Run tools with restricted file system and network access; validate and type-check every parameter; treat tool output as untrusted input to the model.
• Sign and log everything. Sign and verify messages where the deployment supports it, and log every tool and model invocation with the identity behind it, as the NSA recommends.
• Keep internal servers off public networks and apply per-identity rate limiting to anything reachable from the internet.
• Harden local servers. Prefer the stdio transport for servers that run on the laptop, require a token on any local HTTP transport, and show users the exact command a one-click install will execute.
• Audit the code and the supply chain. Choose supported MCP projects, review server code before deployment, and pin versions.

How do you govern the MCP servers employees connect that you do not run?

This is the harder half, and the half the NSA guidance points at when, as industry coverage of the sheet summarizes it, it lists scanning for open or unauthorized MCP servers among its recommended controls. Most MCP connections your employees make go from a laptop to a remote server you have never seen, run by a SaaS vendor, an open-source maintainer, or a stranger on GitHub. You cannot harden a server you do not control. You can control whether the laptop talks to it and what it sends.

Three approaches exist, and the architecture decides what each one can see.

DNS filtering (Cisco Umbrella, DNSFilter)

DNS sees a hostname. It cannot tell a connection from an approved MCP client to an approved server apart from a connection to a malicious one on the same cloud provider, cannot read the request, and cannot tell which process on the laptop made it. Cisco's own MCP and agent gateway controls, announced in March 2026, live in Secure Access rather than Umbrella, and Umbrella itself reaches end of sale on January 31, 2027.

Cloud proxy SSE with an AI add-on (Zscaler, Netskope, Cloudflare, Palo Alto)

Cloud proxies can inspect MCP traffic if it is routed through them and TLS-inspected, and most now sell an AI or agent product to do it: Zscaler's AI Broker for agent and MCP traffic was announced at Zenith Live in June 2026 with GA and pricing not disclosed; Netskope's Skylight Agentic Broker was announced September 15, 2026 with Agent Action Control due later and tier not disclosed; Cloudflare's shadow-MCP detection, released August 14, 2026, is an experimental selector that only works on traffic Gateway already TLS-inspects. Palo Alto's Prisma AIRS gateway integration is announced, not shipped. In every case the control is an extra SKU on a proxy that adds a round trip to every request, and it cannot see traffic from a process that bypasses the tunnel, which is exactly what cert-pinned developer tools and bypass lists create.

On-device SWG (dope.security)

dope.security runs on the laptop and inspects every outbound connection from every process, including the MCP client inside Claude Desktop, Cursor, VS Code or a terminal, with no tunnel to bypass and no detour to a PoP. Shadow IT discovery surfaces the domains MCP clients talk to, attributed to the user and the application, so you get an inventory of real MCP usage instead of a survey. Cloud Application Control and URL policy let you allow the MCP endpoints you have approved and block or warn on the rest, per group, with the policy live on every endpoint in under a minute. Dopamine DLP reads what the AI tool sends on the device and blocks PII, PCI, PHI and source code before it leaves. The on-device architecture case for shadow AI and shadow MCP covers why process-level visibility matters more here than anywhere else in AI governance. For developer-heavy fleets, see shadow AI tools for Claude Code, Cursor and developer AI.

A 30-day plan to secure MCP across the company

• Days 1 to 7, discover: deploy the dope.security agent to a pilot group via Intune or Jamf and read the Shadow IT and AI Analytics reports. List every MCP-related domain and the process behind it. Our list of 56 common MCP domains hiding in plain sight is a starting map.
• Days 8 to 14, classify: sort servers into approved (vendor-run, authenticated, scoped), tolerated (open source, reviewed) and blocked (unknown, unauthenticated, remote with broad scopes). Apply the server-side checklist to anything your own teams host.
• Days 15 to 21, enforce: allow approved endpoints, warn on tolerated ones, block the rest. Turn Dopamine DLP to Monitor for AI tools, then Block once the false-positive rate is what you expect (with LLM classification, there are no regex rules to tune).
• Days 22 to 30, prove it: stream dope.security logs to your SIEM so every MCP connection and DLP verdict has an audit trail, which closes OWASP MCP08 for the client side, and write the acceptable-use policy from what you actually found.

When to choose dope.security

Choose dope.security when your employees use AI clients on laptops you manage, when you cannot inventory the MCP servers they have connected, and when the proxy vendor's answer is an announced-but-unpriced agent broker that still routes every request through a data center. It is the right fit for 250 to 5,000 employee companies with engineering, finance or healthcare teams who have adopted Claude, Cursor or Copilot faster than IT could write policy, and for any team that wants discovery, tenant control and AI DLP from one agent and one console rather than three SKUs. Greylock Partners moved off DNS-only filtering for the same reason: the risk had moved inside HTTPS, and DNS could not follow it.

Choose a server-side gateway product alongside it when your company builds and hosts MCP servers at scale and needs centralized OAuth, scope management and tool signing for them. The two layers are complementary: one hardens what you run, the other governs what your people connect to.

The servers you operate can be hardened with a checklist. The servers your employees connect to can only be governed from the device that connects. Start a free trial or book a demo to see every MCP connection on your fleet in the first hour.

FAQ

How do I find out which MCP servers my employees are using?

You cannot rely on a survey or on proxy logs that only see tunneled traffic. An on-device agent such as dope.security records every outbound connection by process and user, so MCP endpoints contacted by Claude Desktop, Cursor, VS Code or a terminal appear in Shadow IT discovery with the application attributed. That inventory is the first step the NSA guidance calls for.

What does the NSA recommend for securing MCP?

The NSA's May 20, 2026 Cybersecurity Information Sheet, as summarized in industry coverage, recommends choosing supported MCP projects, auditing server code, defining trust boundaries, validating parameters, sandboxing tool execution, signing and verifying messages, logging all tool and model invocations, and scanning for unauthorized MCP servers. The NSA's own release stresses that MCP introduces systemic risks that existing defenses do not adequately address.

Can a DNS filter or Cisco Umbrella secure MCP connections?

No. DNS filtering sees only hostnames; it cannot read the MCP request, distinguish an approved server from a malicious one on the same cloud, or tell which process on the laptop connected. Cisco's own MCP controls live in Secure Access, not Umbrella, which reaches end of sale on January 31, 2027.

Do Zscaler or Netskope secure MCP traffic?

Both have announced products: Zscaler's AI Broker (June 2026) and Netskope's Skylight Agentic Broker (September 2026), with GA dates and pricing not disclosed at announcement. Both work by routing agent traffic through the vendor's cloud proxy, which adds latency and misses any process that bypasses the tunnel. dope.security inspects on the device with no add-on and no detour.

Should employees be allowed to connect MCP servers at all?

Yes, with controls. Blocking MCP outright pushes usage to personal devices and unmanaged accounts. The workable policy is allow approved servers, warn on reviewed ones, block unknown ones, and run DLP on what the AI tool sends, which is what dope.security enforces per group from one console.

Does dope.security replace an MCP gateway for servers we host?

No. dope.security governs the client side: which MCP endpoints managed laptops may reach and what data leaves them. If you host MCP servers, you still need OAuth 2.1, scope minimization and tool sandboxing on the server, either built in or through an MCP gateway. The two layers work together.