Every consumer routes over the registries bound to it. Who calls it never changes which
registries or models it reaches; a caller’s token, key, or certificate only decides whether
the request is admitted.
Consumers list
Open Agent Gateway → Consumers.Create a consumer
- Open Consumers → New Application.
- Work through the create tabs:
- Auth — Name, Protocol (LLM or MCP), and Authentication (see below). Copy API keys when shown (once only).
- Routing — strategy + registries/models (or MCP target).
- Policies — optional Add Policy or Clone policies from another consumer.
- Save. The success step and the detail Connect tab show ready-to-use snippets.
Detail tabs
Identity
Every consumer is an application.identity says whether a person stands behind each
request and how TrustGate learns who that person is. It never selects a registry or a model.
The identity fixes the credential shape (the gateway enforces it with
409):
When to use which: a backend agent or scheduled job acts as the application (leave the
switch off). An internal assistant where each person reaches their Notion or Linear acts
for users with Users sign in. A product that owns its own user directory and calls MCP
server-side uses
source: app and links accounts through the
end-user connections API. The self-service
MCP Store is a built-in consumer that acts for platform users.
Access rules govern the Store only. A custom consumer’s servers are exactly the registries
bound to it under Routing, the same set for every caller it admits.
Auth binding
Identity providers and mTLS CAs are gateway-level trust anchors shared by many consumers.auth_binding narrows which verified callers may enter this consumer. Empty lists accept
every caller the anchor verifies. API keys need no binding: a key belongs to one consumer.
Enforced after consumer resolution on both the LLM proxy plane and the MCP plane (JWT,
introspection, and mTLS). A caller the anchor verifies but the binding excludes gets
403.
Up to 100 entries per list, 256 characters each.
Attached auth entities
PUT /v1/gateways/{gateway_id}/consumers/{consumer_id} accepts auths: [id, …] and applies
it in the same transaction as identity, so identity and credential move together:
Detaching the last OAuth2 auth from a consumer whose users sign in hands it to the built-in
NeuralTrust login.
Strategies
Load-balancing strategies (including smart routing) are grouped under Load balancing in
the Strategy dropdown; Simple routing and Fallback under Direct.
MCP consumers always bind registries/tools directly — they do not show the Strategy
selector or load-balancing algorithms.
Providers editor
For simple routing and non-smart load balancing, use Add Registry, set optional weight (weighted strategy), choose all models/tools or restrict via the model browser, and set a default model when needed.Smart routing
Use Complexity tiers (at least two): Simple / Medium / Hard, each with a registry and model. Same registry can appear on multiple tiers with different models. Details: Load balancing, Smart routing, Model resolution, Fallback.Model policies
For each bound registry you can:- Allow all models, or filter to a subset.
- Set a default model used when the client does not name one.
"model": "auto" so the gateway picks the registry and model. With multiple registries
and no load balancing, clients must specify the model themselves.
Connect tab
Open a consumer → Connect for:- Gateway host (SaaS or your Private LLM URL)
- Consumer slug
- Auth header examples (
X-AG-API-Key, andX-AG-Gateway-Slugon Private) - Language snippets (cURL, Python, Node, …)
- Same host and key for embeddings, images, files, rerank, and models