MCP security model

Registering a third-party MCP server means asking Quant to fetch a URL you chose, with credentials you supplied, and to feed the response into a model’s instructions. Each of those steps is a risk. This page describes what the gateway does about each one.

Threats and mitigations

Threat	Mitigation
Token passthrough and confused deputy	The gateway injects your organisation’s credentials. A caller’s token is never forwarded downstream.
SSRF through a registered URL	HTTPS only, private and reserved ranges blocked on the numeric address, every redirect hop re-validated.
Tool poisoning and rug pulls	Tool schemas are hashed and pinned. Descriptions are treated as untrusted content. Allowlists apply at server and agent level.
Credential exposure	Secrets live in Secrets Manager. API fields are write-only and never sync to clients.
Cross-organisation access	Every registry and gateway lookup is keyed to the authenticated organisation.
One bad server wedging an agent	Per-request timeout of 30 seconds within an overall gateway budget of 50 seconds.

Credential handling

Your downstream credentials are written to Secrets Manager when you save the server and are never returned afterwards. The API reports only whether credentials are present.

The gateway fetches them at call time and attaches them to the downstream request. They do not reach:

• a developer’s machine running QuantCode
• a browser session in the dashboard
• any client-side configuration sync
• the model, in any prompt or tool result

This is why direct connections are not offered as an alternative. A direct connection would put the credential wherever the client runs.

Why the caller’s token is not forwarded

The MCP specification forbids token passthrough. A token issued for the gateway carries the gateway as its audience. Forwarding it to a third-party server would present a credential to a party it was not issued for, and would make the audit trail attribute actions to the wrong identity.

Callers authenticate to the gateway. The gateway authenticates to your server. The two are separate.

Egress controls

You supply the server URL, and Quant fetches it from inside our network. Without controls, that is a server-side request forgery primitive.

The gateway enforces:

• HTTPS only. No loopback exception server-side.
• Blocked address ranges. Loopback, RFC 1918 private, link-local (including the cloud metadata endpoint at 169.254.0.0/16), CGNAT, multicast, and reserved ranges are refused, along with their IPv6 equivalents.
• Numeric checks, not string matching. Hostnames are resolved and every returned address is checked as a number. Decimal, hex, and octal IPv4 encodings — https://2130706433/ for 127.0.0.1, for example — normalise to the same numeric path and are caught by it.
• Re-validation on redirect. Redirects are followed manually so every hop is validated again, including a fresh DNS resolution, up to a limit of 5. A server cannot pass validation and then redirect to an internal address.

Residual DNS rebinding risk

Validation performs a fresh DNS resolution and the fetch follows immediately, but the connection is not pinned to the validated IP address. An attacker who controls the authoritative DNS server for a hostname could return a different answer to the resolver used at connect time.

The window is small, but it is not zero. Register servers on hostnames you control or trust.

A blocked URL surfaces as ssrf-blocked in the connection test and in agent tool calls.

Tool schema pinning

When you test a connection, the gateway hashes the server’s full tool list and stores it as a pin. It re-checks that hash on every tools/list, over the complete downstream list before allowlist filtering — so a change to a tool you do not currently expose is still detected.

This matters because tool descriptions are instructions. An MCP server that alters a description after you approved it is editing your agent’s prompt. Treat a schema change alert as a security event, not a version bump: re-read the tool descriptions before accepting it.

All tool descriptions and annotations from a downstream server are treated as untrusted content.

Allowlists

Two allowlists apply, and the effective tool set is their intersection:

1. Server level — which of the server’s tools your organisation exposes at all.
2. Per-agent attachment — which of those a specific agent may call.

An empty array denies everything. An absent or null list means no restriction. Both levels follow that contract.

Keep both as narrow as the work requires. An agent that only needs to read customer records should not be able to call a tool that deletes them.

Failure isolation

Each downstream call has a 30-second timeout, within an overall gateway budget of 50 seconds. A server that stops responding costs the agent one timeout rather than hanging the loop.

Health status is recorded on every connection test and every gateway call, so a server that has started failing is visible in the dashboard before someone reports that an agent has become slow.

Note

There is no circuit breaker. Each call to a failing server waits for its own timeout rather than failing fast after a run of errors. If a server becomes unreliable, disable it in the dashboard or remove it from the agent’s attachments.

Audit

Every tools/call through the gateway emits an audit event with the organisation, the caller class, the server, the tool, the outcome, and the duration. Tool arguments are hashed rather than stored.

These events sit alongside the rest of your AI audit trail, which is written to storage under Object Lock and cannot be altered during the retention period.

Governance

MCP calls pass the same governance checks as every other AI request in your organisation. If your AI configuration blocks a call — the master switch is off, or policy denies it — the gateway refuses before contacting the downstream server, and returns a governance error.

See AI governance for the controls available.