How to Secure an Existing Remote MCP Server (Even One With No Auth)

Plenty of teams already have an MCP server running in the cloud — deployed on a VPS, a container platform, or shipped by a vendor — reachable at a plain HTTPS URL. The security posture is usually one of two flavors:

1. A static token in a header, pasted into every client config that needs it. One credential, shared everywhere, rotated never, logging nothing.
2. No auth at all. The URL is the secret. Anyone who finds the endpoint has a remote tool API pointed at your systems.

Either way, you have no record of which tools were called with what arguments, no way to disable a dangerous tool without redeploying, and no way to cut off one client without breaking all of them.

You don’t need to touch the server to fix this. This guide puts MCP Trail in front of your existing server’s URL — five minutes, no code changes, no redeployment — and gets you authentication, per-tool policies, DLP, rate limits, and a full audit trail.

How it works

You register your server’s URL as the upstream. The gateway gives you a new, authenticated endpoint; clients connect to that instead of the original URL. Every call is checked against your policies, logged, and then forwarded — with your upstream token attached server-side, where clients can’t see it.

Step 1: Create your free MCP Trail account

Sign up at app.mcptrail.com.

Step 2: Add your server by URL

Go to Guardian servers → Add server and choose Web address — for any MCP server with a normal http(s) link (Streamable HTTP). Fill in:

• Backend service URL — your server’s existing MCP endpoint
• Upstream API key (only if your server asks for one) — stored encrypted, injected on every forwarded call, never shown to clients
• Optionally a separate discovery URL if your server exposes tool discovery on a different address

Step 3: Grab your new gated endpoint

On creation you get the two things your clients will use from now on: a Guardian endpoint URL and a bearer token (with a visible expiry — these are meant to rotate, unlike the forever-token in your old configs).

Step 4: Point your clients at the gateway

Swap the URL in each client’s MCP config from the original server to the Guardian endpoint:

{
  "mcpServers": {
    "my-server": {
      "url": "https://<your-guardian-endpoint>",
      "headers": { "Authorization": "Bearer <your-token>" }
    }
  }
}

The Connect an agent panel generates this per client — Claude Code, Claude Desktop, Cursor, VS Code, and more (full walkthrough).

Step 5: Close the back door

The gateway protects traffic that goes through it — so make sure traffic can’t go around it:

• If your server uses a token: rotate it now, and give the new one only to MCP Trail (Step 2’s upstream API key). Old configs with the leaked token stop working; the gateway becomes the only working path.
• If your server has no auth: add the cheapest possible barrier at the source — a static header check or a firewall/IP rule on your host — so only the gateway can reach it. An unauthenticated URL that stays reachable is still an open door, gateway or not.

Step 6: Turn on the controls you never had

Open your server under Guardian servers:

• Per-tool policies — disable dangerous tools, or route them through the Approval queue for human sign-off
• DLP scanning — block or redact secrets and PII in arguments and results (full guide)
• Rate limits and payload caps — stop runaway agent loops and oversized requests
• Audit log — every call, with arguments and status, across all clients

Verify it works

Call a tool from any connected client, then check Audit log — the request appears with its arguments, status, and timing. Then try the original URL path: a client using the old direct config (with the rotated-away token) should now fail. That’s the sign the gateway is the only door.

FAQ

Do I need to change or redeploy my MCP server?

No — the gateway consumes your server’s existing HTTP endpoint as-is. The only server-side change we recommend is rotating its token (or restricting its network access) so the gateway is the only caller.

My server is unauthenticated. Does the gateway alone make it safe?

It makes all gateway traffic authenticated, logged, and policy-checked — but the original URL is still reachable by anyone who has it. Pair the gateway with Step 5: token-gate or firewall the upstream so direct access dies.

Does this add latency?

One HTTP hop, typically small next to the tool call itself — and the optional response cache can make repeated identical calls faster than direct ones.

What if my server runs on localhost or a private network?

Expose it to the gateway through a tunnel and use the tunnel address as the Backend service URL — or check the hosted route if the server could simply run on MCP Trail instead.

What about servers that require OAuth?

That’s a first-class flow — discovery, dynamic client registration, and automatic token refresh are handled for you. See How to Add OAuth to an MCP Server.

Related Articles

• How to Add OAuth to an MCP Server (Without Writing Auth Code)
• How to Protect Sensitive Data When Using MCP Servers
• How to Check and Monitor MCP Server Logs
• MCP Firewall / Gateway Explained

Your server is already running — it just needs a front door. Create your free MCP Trail account and gate it in the next five minutes.