Skip to main content
A gateway is a running TrustGate deployment. It has two addresses your clients call — an LLM Gateway URL and an MCP Gateway URL — and one for people: the Employee portal, an MCP endpoint that lists the servers each person may use. A client keeps speaking the API it already speaks: OpenAI-style requests to the LLM URL, MCP to the MCP URL. The gateway authenticates it as an application, applies the policies attached to it, routes to a registry entry with that entry’s credential, and records the hop as a trace.

​
Everything belongs to one

The console shows one gateway at a time — the one in the Gateway selector at the top. Registry, Access, Policies, Activity, Analytics, Playground and Settings all read from that gateway and write to it. Switching gateway switches all of them. Nothing crosses between two gateways. An application registered on one is unknown to the other, and a policy has to exist on each gateway it should apply to.

​
One, usually

Applications separate what your teams built. Access separates people. Instances separate production keys from staging keys on the same provider. Policies separate rules. Each axis you might reach for a second gateway to get, something smaller already provides — without a second set of credentials to manage and a second Activity to watch. A second gateway is for a genuinely separate environment: a different network, a different data residency, a blast radius you want walled off. Those are the cases where “nothing crosses between two” is the feature. Give each one an Environment label — production, staging, development — and it is marked as such wherever it appears.

​
SaaS or Private

The deployment type is chosen at creation and cannot change afterwards without recreating the gateway. The console is identical either way. What differs is where a request physically goes — and that the console cannot reach a private data plane from outside your network, so the Playground and connection tests run from a machine that can. Deployment covers running one.