Auth Options, Ports, and Network Setup for Remote MCP Access

What authentication options actually work for a remote MCP server?

Three auth shapes cover almost every real remote MCP deployment. The first is OAuth 2.1 with PKCE, which is the spec-blessed path when a human is behind the agent: the agent redirects to your identity provider, the user consents, and the MCP server gets a scoped access token plus a refresh token. The second is a short-lived bearer token issued by your own auth service, useful when the caller is another backend (a CrewAI worker, a LangChain runner, an n8n flow) and there is no human in the loop. The third is mutual TLS, where both the client and server present certificates: heavier to operate, but the right call when the MCP server exposes destructive tools and you cannot tolerate a stolen token. Avoid static API keys baked into config: they leak, they never rotate, and they make every audit harder than it needs to be.

Which ports should a remote MCP server expose and which should it hide?

The only port that should reach the public internet is 443. Everything else (the raw MCP process, the database, the worker queue, the metrics endpoint) lives on the loopback interface or on a private network. The MCP transport itself usually speaks HTTP plus Server-Sent Events or a streaming WebSocket, so a standard reverse proxy (Caddy, Nginx, Traefik) on 443 terminates TLS and forwards to your upstream MCP server on 3000 or 8080. Block 80 unless you genuinely need an HTTP-to-HTTPS redirect, and even then redirect at the proxy and never let the MCP process answer on plain HTTP. If you self-host on a VPS or a home box, treat every open port as a liability: run a host firewall (ufw, nftables, cloud security groups), default-deny inbound, and explicitly allow only 443. Sistava users skip this entirely because the managed integration layer never exposes a raw MCP port to the customer at all.

What is the safest step-by-step network setup for a remote MCP server?

The setup I run on every self-hosted MCP server I touch follows the same five steps, in the same order, every time. The order matters: each step closes a class of mistake before the next one can be made. Skip the order and you end up with a working MCP server that is also reachable on three ports you forgot you opened. The trick is to treat the network and the auth as one design, not two: a token leaks less when there are fewer places to leak it from, and a port hurts less when the thing behind it cannot accept the wrong token. Sistava, Lindy, and other managed agent platforms collapse these five steps into a single configuration screen, which is a fair trade if you do not want to operate the path yourself.

1. Bind MCP to loopback only — Start the MCP process listening on 127.0.0.1:3000 (or 8080), never on 0.0.0.0. This guarantees the process is unreachable from outside the host until you choose to expose it.
2. Put a reverse proxy in front — Caddy, Nginx, or Traefik on 443 terminates TLS with an automatic certificate, forwards to the MCP upstream over loopback, and adds rate limits, request logging, and IP allow-lists in one place.
3. Wire OAuth or short-lived bearer auth — Pick OAuth 2.1 with PKCE for human-tied callers, or a short-lived JWT signed by your auth service for backend callers. Reject any request without a valid token at the proxy before it reaches MCP.
4. Lock the firewall to one inbound port — Default-deny inbound on the host (ufw or nftables) and the cloud security group. Allow 443 only. Block 80 unless your proxy needs it for cert renewal.
5. Add observability and an egress allow-list — Log every auth decision, every tool call, and every outbound HTTP request the MCP server makes. Restrict outbound destinations so a stolen token cannot phone home to an attacker-controlled host.

Two practical notes from running this setup against real agents. First, refresh-token rotation is the part most teams skip and most teams regret: without rotation, a leaked refresh token is effectively permanent access until you discover it. Second, the moment you let multiple agents share one credential (a CrewAI worker pool, an Apollo enrichment job, a few n8n flows all pointing at the same MCP), audit logs become much less useful because you cannot tell which caller did what. Issue one credential per caller, even when it feels like overkill, and rotate often.

If the entire stack above sounds like a side project you do not have time for, that is the honest reason the managed-integration category exists. Sistava ships with the auth, ports, and network policy already wired, which is the same shortcut Lindy takes for its agent connectors and that platforms like n8n offer through their hosted version. The trade is the usual one: faster start, less control. For most solo founders and growth teams, the trade is worth it, because the time saved goes into the actual work the agent does.

How do managed agent platforms remove this work entirely?

Managed AI Employee platforms move the auth, port, and network problem inside the vendor and hand you a UI instead. Sistava embeds MCP servers behind its own managed reverse proxy, issues short-lived per-tenant tokens to each AI Employee, and never exposes the raw MCP port to customers. Lindy does something similar for its connector library, CrewAI Cloud handles it for its managed crews, and Apollo wraps it for its data tools. n8n offers two flavors: self-hosted (you operate everything we just described) and n8n Cloud (they operate it for you). The benefit is obvious for non-technical buyers: no firewall to configure, no certificate to rotate, no OAuth client to register. The cost is that you accept the vendor's defaults for token TTL, scope shape, and egress policy, which is usually fine and occasionally not.

When should you self-host MCP instead of using a managed platform?

Self-hosting MCP is the right call in three honest scenarios. First, when you must keep data inside a specific network boundary for compliance (regulated industries, government, a customer contract that bans third-party processors). Second, when you need a custom transport or a custom tool surface that no managed platform exposes, for example a private internal tool the vendor will never integrate. Third, when you have the engineering bench to operate the auth, ports, firewall, observability, and rotation yourself without it eating a meaningful share of the team's week. If none of those three apply, a managed platform like Sistava is the faster path, because the work of building the network setup correctly is not the work that earns you customers. The work that earns you customers is the work the AI Employee actually does once the network is out of the way.

Frequently asked questions

If you are choosing between operating this stack yourself and using a managed AI Employee platform, the next read is the practical companion: it walks through the integration patterns AI Employees use to act on your real tools (Gmail, Slack, your CRM, your CMS) without you wiring agents from scratch. It covers what an AI Employee can do once the network is out of the way, which is the part most of these auth and port decisions are really in service of.

The honest framing: remote MCP access is a solved problem at the spec level, but the operational tax (cert rotation, token TTLs, firewall hygiene, egress allow-lists, audit logging) is real and never ends. If you have the bench, self-hosting gives maximum control and is right for regulated workloads or custom internal tools. If you would rather spend those hours on the work the AI Employee actually does, a managed platform like Sistava collapses every step in this article into a connect-account UI. Pick on the constraint that actually binds you today: control over the wire, or speed to the first useful result.