> ## Documentation Index
> Fetch the complete documentation index at: https://neuraltrust-92b43583-develop.mintlify.site/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

> A registry entry is a destination plus the credential to reach it. What that credential is decides what the destination sees — and it is the only decision here that you cannot quietly change later.

The **registry** is what a gateway is allowed to reach: model providers, and MCP
servers. Nothing routes anywhere until it exists here.

An entry is two things — a **destination** and a **credential**. Everything else
about it follows from the second.

## The credential decides what upstream sees

| Credential                              | What the destination sees        | Use it when                                                                                    |
| --------------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------- |
| **API key**                             | One identity for every caller.   | The destination has no per-person concept, or you want one bill and one rate limit.            |
| **Shared account** (client credentials) | One identity, obtained by OAuth. | Same, where the provider wants OAuth rather than a key.                                        |
| **User account**                        | Each person as themselves.       | The destination has per-user permissions worth keeping — a ticket tracker, a repo host, a CRM. |
| **Caller's own token**                  | Whatever the caller already had. | The caller is already authenticated upstream and TrustGate should stay out of it.              |
| **None**                                | An unauthenticated caller.       | Internal services on a trusted network.                                                        |

The practical consequence: with a shared key, the destination's audit log says
*TrustGate* and every user inherits the same permissions. With per-user accounts
it says who it actually was, and each person reaches exactly what their own
account reaches — which is also why someone who has not connected an account yet
gets nothing until they do.

## Instances

One entry can hold several **instances**: the same provider configured more than
once, each with its own credential and name. Two Azure OpenAI deployments,
production and staging keys, one MCP server registered against two accounts.

Instances are how you separate environments without separating gateways. Routing
picks between them, and applications and policies refer to them individually.

A server that is a single URL with a single sign-in holds exactly one instance,
and a server people install themselves gets its instance created on first
install.

## Built-in and custom

**Built-in** entries come from the NeuralTrust catalog: the connection details are
already known, so you supply a credential — or, for many MCP servers, nobody
does, and each person connects their own account the first time they use it.

**Custom** entries are the ones you register yourself: an OpenAI-compatible
endpoint, a self-hosted model, an MCP server by URL, or an HTTP API described by
an OpenAPI document that TrustGate turns into tools.

## 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

<CardGroup cols={2}>
  <Card title="Model providers" icon="plug" href="/trustgate/registry/models">
    What each provider needs, and the contract pricing that makes cost reporting true.
  </Card>

  <Card title="Servers catalog" icon="bot" href="/trustgate/registry/mcp">
    Who holds the credential, and turning an OpenAPI document into tools.
  </Card>
</CardGroup>
