Cybersecurity
Oct 26, 2026
Oct 27, 2026
•
9 min read
With CloudConnexa, the MCP server stays on a private network behind a Connector that only makes outbound connections. You publish it as an Application, grant one user group access to it, and everyone else, including the internet, has no route to it.
This guide explains why MCP servers need their own access controls, the mistakes teams make most often, and how to set up private access step by step.
What is an MCP server?
An MCP server is a service that lets AI assistants and agents use your tools and data through the Model Context Protocol (MCP), an open standard for connecting AI models to external systems. The official MCP site describes it as an open-source standard for connecting AI applications to data sources, tools, and workflows. For example, an MCP server might let an AI assistant search your internal knowledge base, look up support tickets, or query a database.
MCP makes AI far more useful at work. It also means every MCP server is a doorway from an AI model into your company systems, so it deserves the same care you'd give any other internal application.
Learn more about MCP gateway in the 2026 OpenVPN [Con]nected session here.
Why MCP server security matters
An MCP server inherits the sensitivity of everything it connects to. If it can read your ticketing system, anyone who reaches the MCP server can potentially read your tickets.
Attackers have noticed. In April 2026, Censys counted 12,520 internet-accessible MCP services across 8,758 IP addresses, and noted that the protocol doesn't require authentication by default. In July 2026, the SANS Internet Storm Center reported distributed scans sending MCP handshake requests from 49 source IPs to find servers that answer.
The MCP security risks most teams run into:
- Public exposure for convenience. It's tempting to give an MCP server a public address so remote employees and cloud-hosted AI tools can reach it. That makes it discoverable by anyone scanning the internet.
- Weak or shared authentication. Early MCP deployments often rely on a single shared token. If it leaks, there's no way to tell who used it.
- Flat network access. Putting the MCP server on a network that every VPN user can reach means every remote user, and every device they connect, can reach it, whether or not their job needs it.
- No per-person control. Without identity-based access, you can't easily say "Support can use the ticketing MCP server, but Sales can't."
The Zero Trust approach to MCP server security
Zero Trust replaces "anyone on the network can reach it" with "only verified, authorized identities can reach it." For an MCP server, that means three things:
- No public exposure. The server has no public IP address and no inbound firewall rules.
- Verified identity for every connection. Every user or agent is authenticated before it connects.
- Access per application, not per network. Being authorized for one MCP server doesn't give access to anything else.
CloudConnexa delivers this with Application Domain-based Routing and Access Groups. When an authorized user's device looks up the MCP server's domain, CloudConnexa returns an intermediary IP address and routes the traffic to the real server through the tunnel. The private subnet is never sent to the device as a route, so the user reaches that one application without joining the network. A user who isn't authorized for the MCP server has no route to it.
Running a self-hosted VPN instead? Access Server 3.1 and newer offers the same per-application model through its Zero Trust Application Broker.
How to secure an MCP server with CloudConnexa: step by step
The MCP Gateway is currently in beta. However, below are a few step-by-step instructions on how you can secure your server today.
Step 1: Keep the MCP server on a private network
Deploy the MCP server on a private subnet, in your office, data center, or cloud VPC, with no public IP address. Remove any inbound firewall rules or port forwarding that exposed it before.
Step 2: Install a CloudConnexa Connector
Install a Network Connector on the same private network, or a Host Connector on the MCP server itself. Connectors make an outbound connection to a CloudConnexa region, so you don't need to open any inbound ports.
Step 3: Publish the MCP server as an Application
In CloudConnexa, add the MCP server as an Application using its domain name, for example kb-mcp.internal. This tells CloudConnexa which specific service authorized users should be able to reach. If you use a private domain, add a DNS record for it in CloudConnexa or on your internal DNS server, and keep the DNS Proxy setting on.
Step 4: Grant access to the right group only
Create or use an existing user group, for example Support. Then create an Access Group with Support as the source and the MCP server Application as the destination. Users outside that group can't reach it, even when they're connected to CloudConnexa.
Access Groups take effect when your WPC topology is set to Custom. Delete or edit the Default Full Mesh Access Group, which otherwise allows unrestricted connectivity. The CloudConnexa ZTNA tutorial walks through each setting.
Step 5: Connect users through OpenVPN Connect
Users install the OpenVPN Connect app and sign in through your identity provider using SAML, LDAP, or a local username and password. Once connected, their AI assistant can reach the MCP server at its internal address. For extra assurance, add a Device Posture policy so only devices that meet your security requirements can connect.
Step 6: Test access and denial
Verify three things:
- An authorized user, connected, can use the MCP server from their AI assistant.
- The same user, disconnected, can't reach it.
- A user from another group, connected, can't reach it.
Access Visibility shows the allowed and blocked events from your Access Groups, so you can confirm each test hit the rule you expected. Optionally, scan the server's network from the outside to confirm nothing is exposed.
Securing MCP servers used by autonomous AI agents
The same approach works for AI agents that run without a person. An agent running unattended on a server or VM connects through a Host Connector, which uses its own OpenVPN connection profile as its identity instead of a person's login. Add that host as the source in an Access Group with only the MCP server Application as its destination, and the agent can reach that MCP server and nothing else.
We use the same pattern to secure the OpenClaw AI gateway with CloudConnexa. For the wider case for giving every agent its own narrow identity, read Your AI Agent Should Get Less Network Access Than Your Intern.
What network-level access control does and doesn't cover
CloudConnexa controls who can reach the MCP server. It doesn't inspect the content of MCP requests or responses, or decide which individual MCP tools a user may call. Use the MCP server's own permissions to limit which tools and data it exposes, and keep its scope as narrow as possible. The MCP project's security best practices cover server-side controls such as token validation and scope minimization.
Combining both layers gives you defense in depth: the network can't be used to reach the server without authorization, and the server only exposes what it needs to. If you need per-agent, tool-level control across many MCP servers, we're building MCP Gateway for exactly that.
MCP server security checklist
- The MCP server has no public IP address or inbound firewall rules.
- A Connector links the server's network to CloudConnexa through an outbound connection.
- Access is granted to specific groups through an Access Group, not to everyone on the network.
- The Default Full Mesh Access Group is removed or restricted.
- Every user signs in through your identity provider.
- Autonomous agents connect with their own Host Connector identity.
- The MCP server exposes only the tools and data its users need.
- Access is tested for both authorized and unauthorized users.
Frequently asked questions
Is it safe to expose an MCP server to the internet?
Exposing an MCP server to the internet makes it discoverable by anyone scanning for MCP services, and researchers have already observed those scans. The safer approach is to keep it on a private network and allow access only through an authenticated, identity-based connection, such as a CloudConnexa Application restricted by an Access Group.
How do remote employees access a private MCP server?
Remote employees install the OpenVPN Connect app and sign in with your identity provider. If their user group is authorized for the MCP server, their AI assistant can reach it at its internal address. Users who aren't authorized have no route to it.
Do I need to open firewall ports to use CloudConnexa with an MCP server?
No. The CloudConnexa Connector makes an outbound connection, so the MCP server's network doesn't need any inbound ports opened.
Is a VPN enough to secure an MCP server?
A traditional VPN that gives every user the whole network isn't enough on its own, because anyone connected can reach the MCP server. Per-application access, where only an authorized group can reach that one server, closes the gap. Our post on ZTNA vs. VPN explains how the two work together.
How do I secure a self-hosted MCP server?
Run it on a private subnet with no public IP, connect that network to CloudConnexa with a Connector, publish the server as an Application, and grant access to one user group. The server's own authentication and tool permissions still apply on top.
Does CloudConnexa inspect MCP traffic?
No. CloudConnexa controls which users, devices, and agents can reach the MCP server. It doesn't inspect the content of MCP messages. Use the MCP server's own permissions to control which tools and data it exposes.
.png)