Securing the environment URL.

The URL is a bearer credential

An environment URL looks like https://mcp.exorails.net/e/7c1f0a2e-9d84-4b6c-a0f1-2b5c8e4d31af/k_7f3a9c2e. The last segment is a secret token. Anyone who has the full URL can reach every tool you added to the environment, with the secrets you stored — no password, no second factor. Treat it like an API key: it is a bearer credential, meaning possession alone is enough.

We store the token hashed, so the dashboard can show the full URL only once, at creation or rotation. Rotating the URL issues a new token and stops the old one immediately, on every laptop and agent that held it. That is your break-glass if a URL leaks into a shell history, a proxy log or a screenshot.

Three access policies

The access policy of an environment decides which of these an agent may use. Set it under Settings → Access; it takes effect the moment you save.

• Token in a header, or sign in. The default for every new environment. A URL that carries a token is refused with 401: the token must arrive in the Authorization header, or the client signs in with OAuth. A URL in a log is then worthless on its own.
• Sign in only. No static token is accepted at all. Every client opens the browser and signs in with an Exorails account, with your 2FA or SSO. Access is per person, expires, and is revocable one client at a time. There is no token to leak.
• Also allow the token in the URL. Off by default, and enabled deliberately. The address itself becomes the password: it ends up in shell history, proxy logs, screenshots and bug reports, and whoever reads it holds every tool of the environment, with no sign-in and no trace of who they are. Turn it on for a client that cannot send a header, then turn it back off.

Switching to a stricter policy stops the URLs and header tokens that no longer qualify. Reconnect each agent from the Connect an agent block on the environment overview.

Header form — the token in a request header

Paste the bare endpoint (no token) and send the token in the Authorization header. Keep the token in your client's secret store, not in the URL.

Claude Code

claude mcp add --transport http acme-api \
  https://mcp.exorails.net/e/7c1f0a2e-9d84-4b6c-a0f1-2b5c8e4d31af \
  --header "Authorization: Bearer k_7f3a9c2e"

Cursor / VS Code / Windsurf

// .cursor/mcp.json — same shape for VS Code (.vscode/mcp.json) and Windsurf
{
  "mcpServers": {
    "acme-api": {
      "url": "https://mcp.exorails.net/e/7c1f0a2e-9d84-4b6c-a0f1-2b5c8e4d31af",
      "headers": { "Authorization": "Bearer k_7f3a9c2e" }
    }
  }
}

Codex

# ~/.codex/config.toml
[mcp_servers.acme-api]
url = "https://mcp.exorails.net/e/7c1f0a2e-9d84-4b6c-a0f1-2b5c8e4d31af"
http_headers = { Authorization = "Bearer k_7f3a9c2e" }

Sign-in form — OAuth, no token at all

Paste the bare endpoint and let the client discover the gateway's authorization server. It opens your browser, you pick the environment on the consent screen, and the client receives its own access token: 24 hours, refreshed automatically for 90 days, revocable per client. Nothing secret is written to disk.

Claude Code

claude mcp add --transport http acme-api \
  https://mcp.exorails.net/e/7c1f0a2e-9d84-4b6c-a0f1-2b5c8e4d31af
# then, inside Claude Code: /mcp → acme-api → Authenticate (opens the browser)

Cursor / VS Code / Windsurf

// .cursor/mcp.json — same shape for VS Code (.vscode/mcp.json) and Windsurf
{
  "mcpServers": {
    "acme-api": { "url": "https://mcp.exorails.net/e/7c1f0a2e-9d84-4b6c-a0f1-2b5c8e4d31af" }
  }
}
// the client opens the browser to sign in on first use

Codex

# ~/.codex/config.toml
[mcp_servers.acme-api]
url = "https://mcp.exorails.net/e/7c1f0a2e-9d84-4b6c-a0f1-2b5c8e4d31af"
# then: codex mcp login acme-api   (opens the browser)

Allowed addresses

On top of the token, you can restrict which client addresses may use the URL. List one IP or CIDR per line, IPv4 or IPv6, under Settings → Access → Allowed addresses. Leave it empty and any address is allowed; add a range and every other address is refused with 403, whatever the token or OAuth session.

• Your office egress or VPN. The public address your team leaves the network from — the single most useful entry for a shared environment.
• CI runners. The static egress of your build fleet, so a leaked URL cannot be replayed from anywhere else.
• A bastion or NAT gateway. Whatever fixed address your agents actually connect from.

The 403 names the caller's address, so a runner that suddenly cannot connect tells you exactly what to add. If you lock yourself out, nothing is lost: the allow-list applies only to agent calls through the gateway URL. The dashboard on app.exorails.net is authenticated separately and is never filtered, so you can always open the environment and correct or clear the list. It takes effect on the next call.

URL lifetime

Give the URL an expiry so a forgotten one does not live forever. The default is 90 days; you can choose 30, 90, 180 or 365 days, or Never. The clock runs from when the URL was created, and applies to every member's URL in the environment.

• The holder gets an email 14 days and 3 days before their URL expires, so a renewal never arrives as a surprise outage.
• When a URL expires, opening the environment in the dashboard issues a fresh one automatically. Paste it into the agent exactly as you did the first time; the expired one answers 401.
• OAuth sign-in is time-boxed on its own terms: access tokens last 24 hours and refresh for 90 days, and you can revoke any client immediately from the keys list.

What we recommend

For people, use the header or sign-in form so nothing secret ever sits in a URL, and set a policy of header or OAuth so a pasted URL cannot be replayed. For CI and headless agents, prefer a short-lived URL scoped to your runner's egress with the allow-list, kept in your secret store like any credential, and rotate it on any exposure. Either way, an expiry and an allow-list turn a single leaked string into a narrow, self-healing window rather than a standing key.

Connect a client → · Secrets and OAuth →