> ## Documentation Index > Fetch the complete documentation index at: https://docs.neuraltrust.ai/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > These docs cover three products: TrustGate (AI agent gateway), TrustGuard (runtime security), and TrustTest (AI red teaming). Start from each product overview for the definition and How it works. Prefer the .md URL next to a page in /llms.txt when you need the full article. Use /llms-full.txt for a single-file dump of the site. # Registry > What a gateway may reach: model providers on the LLM plane, MCP servers on the MCP plane. An entry is a destination plus the credential to reach it, and who holds that credential is the decision that shapes everything else. 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 | | Models | MCP | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Serves** | The LLM Gateway: chat, embeddings, images, audio, files, rerank. | The MCP Gateway: tools and resources for agents. | | **An entry is** | A model provider — OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex AI and the rest of the [catalog](/trustgate/registry/models#every-provider), or any OpenAI-compatible endpoint. | An MCP server — one from the [catalog](/trustgate/registry/mcp#every-server), a server you register by URL, or an HTTP API described by an OpenAPI document that TrustGate turns into tools. | | **Who uses it** | Applications, through routing. | Applications, and people through the Portal. | | **Credential** | Always yours: one identity per instance. | Yours, each user's own, the caller's own token, or none. | 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 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](/trustgate/concepts/auth). 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](/trustgate/access/overview) 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](/trustgate/registry/models) lists what each one needs. **MCP.** The instance's mode decides what the server sees: | Mode | What the server sees | Use it when | | ---------------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **User account** | Each person as themselves. They connect their own account once, the first time they use the instance. | The server has per-user permissions worth keeping. | | **Shared account** | One identity, obtained by OAuth client credentials you supply. | The server has no per-person concept, or you want one account and one audit line, and the vendor wants OAuth rather than a key. | | **API key** | One identity, the key you supply. For a custom server, a static header of your choosing. | Same as above, where a key is what the vendor takes. | | **Caller's own token** | Whatever the caller already had, forwarded. | The caller is already authenticated upstream and TrustGate should stay out of it. Set through the API; an instance in this mode cannot be switched to another later. | | **No authentication** | An unauthenticated caller. | Internal servers on a trusted network. | 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](/trustgate/mcp/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](/trustgate/access/overview); 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](/trustgate/policies/overview). 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 What each provider needs, and the contract pricing that makes cost reporting true. Who holds the credential, and turning an OpenAPI document into tools.