MCP security

Letting an AI assistant act on production infrastructure is a reasonable thing to be cautious about. This page describes exactly what controls exist.

Four checks on every call

Access is decided by your server, never by the connector. Every tool call must pass all four:

1. MCP is enabled on the server. Off by default.
2. The key is marked for MCP. An API key without Allow MCP access cannot be used by an assistant at all, whatever its other permissions.
3. The tool is exposed. The list under Settings → MCP is a server-wide ceiling. A tool switched off there cannot be called by any key.
4. The key holds the permission that tool requires.

Checks 3 and 4 work in opposite directions on purpose. The key grants; the exposed-tool list restricts. The restriction always wins, so you can issue a key with projects: write for a script and still be certain no assistant can create projects with it.

These are re-checked on every call. Nothing is cached from when the assistant connected.

Irreversible actions do not exist

Deleting a project and restoring a backup are not implemented as MCP tools. There is no setting to enable them, because the safest version of that control is the one nobody can misconfigure.

Your server stays private

The connector runs on your own machine. Your Supascale server only needs to be reachable from that machine — a LAN address, VPN hostname or tunnel is fine, and nothing needs to be exposed to the internet.

The connector also refuses to send your API key over plain http:// to anything other than localhost, since that would put the key on the wire in the clear.

Keys are opt-in, including existing ones

Keys created before MCP shipped are not MCP-capable after upgrading, and new keys are not by default. You have to tick Allow MCP access deliberately.

This matters because API keys are often long-lived and shared with scripts. A key sitting in a cron job should not become an assistant's credentials because someone enabled a feature elsewhere.

Everything is audited

Every MCP action is written to Settings → Logs with the timestamp, the API key used, the originating IP address and the device, alongside your normal login and activity history. That includes:

• Successful tool calls, with the arguments and how long they took
• Refused calls, with which check rejected them
• Connections, and connection attempts that were rejected

Refusals are logged deliberately. An assistant repeatedly trying a tool it cannot reach is exactly the pattern worth noticing, and it would otherwise be invisible.

You can filter by date and status, and export to CSV.

The HTTP endpoint

Most installs should use the local connector and leave the HTTP endpoint off. If a client cannot launch a subprocess and you need it, Settings → MCP → HTTP endpoint enables /api/v1/mcp, with these controls:

There is also a per-key rate limit, defaulting to 60 requests a minute.

Supascale usually runs behind a reverse proxy, which means it cannot see the real address of an incoming connection — only what the proxy claims in a forwarding header. Those headers are set by the client and can be forged.

Supascale therefore refuses to guess. With Trust reverse proxy headers off, any mode stricter than "Any address" denies requests it cannot verify, rather than believing a header. That is restrictive on purpose: the alternative is a "same machine only" setting that anyone can walk through by sending one header.

If you do sit behind a proxy you control, enable that option and list your proxy's addresses. If your Supascale port is reachable directly, leave it off — enabling it there lets any client claim any IP address.

A firewall rule is still the strongest control available to you. These settings complement it; they do not replace it.

If a key is compromised

Delete it under Settings → API Keys. It stops working immediately, for MCP and for the REST API. Check Settings → Logs, filtered to that key, for what it was used for.

Related

• Available tools — the permission each tool needs
• API Key Management
• Security overview