Registry

The registry is what a gateway is allowed to reach. Nothing routes anywhere until it exists here. It has two parts, one per plane.

​

Two registries

The last row is the one that matters. A model provider has no notion of your users, so the gateway always speaks to it as one account. An MCP server usually does — a ticket tracker, a repository host, a CRM — and the registry lets each person reach it as themselves.

​

Instances

One entry can hold several instances: the same provider or server configured more than once, each with its own name and its own credential. Two Azure OpenAI deployments; production and staging keys for OpenAI; GitHub registered once with a shared token and once per user. Instances are how you separate environments without separating gateways. Routing picks between them, applications bind to them, and policies can target them individually. Each instance shows how it authenticates upstream and whether its last connection test passed. Two cases need nothing from you. A server that is one URL with one sign-in holds exactly one instance. A built-in server people install themselves from the Employee portal gets its instance created the first time someone installs it.

​

Authentication, in both directions

Two different questions hide under one word. Keep them apart and the registry is simple.

​

Callers to the plane

Who is calling the gateway. An application proves itself with its API key or a token from an identity provider you trust — the same on both planes, covered in Authentication. On the MCP plane a person can also sign in directly, with the platform account or an identity provider, and that identity decides which servers they see through Access and, below, whose account reaches upstream. The registry takes no part in this. An entry never authenticates a caller.

​

The plane to upstream

How the gateway authenticates to the destination. This is the registry’s credential, set per instance. Models. Always a credential you hold: an API key, or the provider’s equivalent — an Azure key or service principal, AWS access keys, a GCP service account. The provider sees one identity per instance, whoever the caller was. Model providers lists what each one needs. MCP. The instance’s mode decides what the server sees: The consequence to remember: with a shared credential, the server’s audit log says TrustGate and every caller inherits the same permissions. With user accounts it says who it actually was, each person reaches exactly what their own account reaches, and someone who has not connected yet gets nothing until they do. An application on a user-account instance acts as the account an admin linked for it — see Acting for end users.

​

What the registry does not decide

Two things live elsewhere, and looking for them here is the most common wrong turn:

• Who may use an entry. People are governed by Access; machine callers by the application’s own list of entries.
• What may be done with it. Budgets, allowed models, allowed tools and guardrails are policies.

A registry entry makes something reachable. That is all it does.

​

Failure worth watching

An entry whose stored credentials stopped working keeps its place and keeps receiving traffic. The failure reaches your callers as provider errors rather than as anything that looks like a gateway problem, so a failed connection test is worth acting on when you notice it, not when someone reports it. Deleting an entry is permanent and stops all routing through it immediately.

​

Next