MCP Server Security: Governing the Model Context Protocol Traffic Your AI Tools Just Opened Up

Short answer: You cannot govern the Model Context Protocol (MCP) from the network edge, because MCP traffic is just outbound HTTPS to servers your tools never catalogued. DNS filters miss it, cloud proxies backhaul it, and neither can tell a sanctioned MCP server from a personal one. dope.security governs MCP on the device: the Fly Direct SWG inspects every MCP call at the egress, names the server, and lets you allow the ones you approved and block the rest, with Dopamine DLP catching sensitive data before it leaves in a prompt or a tool call.

Six months ago, almost nobody in your company had heard of MCP. Now your developers are wiring Claude, Cursor, and a dozen internal agents into MCP servers that read files, hit APIs, and move data on their behalf. That is real productivity. It is also a brand new egress path that most security stacks cannot see, and it showed up without a single procurement ticket.

This is the same pattern we wrote about when we found 56 MCP domains hiding in plain sight across real customer traffic. MCP is the new shadow IT. The difference from the last shadow-IT wave is that these connections are designed to move data and take actions, not just render a web page. If you want the full picture of where this fits, our complete guide to AI visibility and governance is the hub. This post is about the MCP-shaped hole in it.

What is MCP, and why did it become a security problem overnight?

The Model Context Protocol is an open standard that lets an AI model or agent connect to external tools and data sources through MCP servers. A server might expose your file system, a Jira instance, a database, a payments API, or a third-party SaaS. The model calls the server, the server does the work, and results flow back into the model's context.

That design is why MCP is useful and why it is risky. An MCP server is a live connection between a model and something that holds your data. It runs over ordinary HTTPS, often to a domain your security team has never reviewed, sometimes to a server a developer spun up on their own laptop. Nothing about that traffic looks different from any other encrypted request. That is exactly the problem.

Why DNS filters and cloud proxies miss MCP traffic

Most teams assume their existing web security already covers this. It usually does not. A DNS-layer tool like Cisco Umbrella resolves a domain and moves on. It never sees the URL path, the payload, or the tool call inside the session, so it cannot tell you what an MCP server did, only that a name was looked up. Cisco's own documentation is clear that tenant-aware control needs a proxy with SSL decryption, not DNS. When roughly 95% of traffic is encrypted, DNS-only visibility into MCP is close to zero.

Cloud proxies see more, but they add their own tax. Every MCP call from a developer's machine has to detour to the vendor's nearest point of presence and back before it reaches the server. For latency-sensitive agent loops that fire dozens of calls, that round trip is felt. Worse, many cloud proxies bypass inspection on cert-pinned developer tools by default, which is precisely where MCP clients live. The tool you most need to inspect is the one on the blind list.

What governing MCP actually requires

Governing MCP is not one control. It is three, and they have to work together on the same egress point. First, discovery: you need to see every MCP server your people connect to, sanctioned or not. Second, policy: you need to allow the servers you approved and block the rest, by name, not by a blunt category. Third, data control: you need to inspect what leaves in the call itself, because the risk is not the connection, it is the customer record or source file that rides along inside it.

Here is how the common approaches stack up against those three requirements.

How dope.security governs MCP on the device

Because dope.security runs an agent on the endpoint and inspects SSL there, every MCP call is visible at the point it leaves the machine. There is no data center to route through and no domain that slips by because it was never in a category list. The same three-layer model we use for AI governance applies directly to MCP.

Layer one is discovery. Shadow AI and shadow IT discovery surfaces the MCP servers your people are actually reaching, including the ones nobody told you about. You get names, not guesses. Layer two is SWG policy plus Cloud Application Control: allow the MCP servers you sanctioned, block the personal or unknown ones, and do it per user or group with policy that pushes in seconds. Layer three is Dopamine DLP, which inspects the content of the call so a source file or a batch of customer PII cannot ride out inside an MCP request. The classification runs through a zero-retention API, so inspecting the data does not create a second copy of it somewhere else.

The payload is the point

It is tempting to treat MCP governance as an allow-list exercise. Approve a few servers, block the rest, done. That misses the real exposure. An approved MCP server can still be handed data it should never receive, because the model decided that reading a spreadsheet of customer records was the fastest way to answer a question. The connection was fine. The payload was not.

This is why inspecting the traffic beats cataloguing the domains. dope.security treats an MCP call the same way it treats an upload to an AI tool: as data in motion that has to be classified before it leaves. If a prompt or tool call carries PII, PCI, PHI, or source code, Dopamine DLP can block it, warn the user, or log it, depending on the policy you set. You govern the data, not just the destination. Our take on sanctioned versus unsanctioned SaaS makes the same argument: the line between approved and personal is where most tools quietly give up.

A practical starting point

You do not need a committee to begin. Turn on discovery and look at which MCP servers are already in use. You will almost certainly find some you did not know about. Sort them into sanctioned and everything else. Put the everything-else group behind a block or a warning while you review it. Then turn on data inspection for the sanctioned servers, because those are the ones with standing access to real systems. That sequence, see it, sort it, inspect it, takes days on dope.security, not a quarter, because there is no proxy to stand up and no PoP to route through.

MCP is not going away, and blanket-banning it just pushes your best engineers onto personal machines where you have no visibility at all. The winning move is to make the sanctioned path the easy one and watch the rest.

Frequently Asked Questions

What is MCP server security?

MCP server security is the practice of discovering, controlling, and inspecting the Model Context Protocol connections that AI models and agents use to reach external tools and data. Because MCP runs over ordinary HTTPS to servers that are often uncatalogued, effective MCP security means seeing every server in use, allowing only sanctioned ones, and inspecting the data inside each call. dope.security does all three on the device with its Fly Direct SWG and Dopamine DLP.

Can a DNS filter or firewall control MCP traffic?

Not meaningfully. A DNS filter only resolves domain names, so it cannot read the URL, the tenant, or the payload of an MCP call, and most MCP traffic is encrypted. A traditional firewall has the same blind spot. Controlling MCP requires on-device SSL inspection that can name the server and read what is being sent, which is what dope.security provides.

How is governing MCP different from blocking a website?

Blocking a website is a yes-or-no decision about a destination. Governing MCP is about the data and actions a live connection carries, because an approved MCP server can still be handed customer records or source code by a model trying to be helpful. That is why dope.security inspects the content of MCP calls with Dopamine DLP rather than only allowing or denying the domain.

Does inspecting MCP traffic slow down AI agents?

With a cloud proxy it can, because every call detours to a point of presence and back. dope.security inspects on the device and flies direct, so there is no network detour added to agent loops that may fire dozens of MCP calls in sequence. Inspection happens where the traffic already is.

What data can leak through an MCP server?

Anything the model can reach: PII, payment data, health records, intellectual property, and source code, all of which can be passed into an MCP call as context or as a tool argument. dope.security classifies that content in motion through a zero-retention API and can block, warn, or log based on your policy, so sensitive data does not leave inside a request you never inspected.

See it on your own traffic. Start a free trial or book a 20-minute demo and watch dope.security surface the MCP servers already running in your environment.