NeuralTrust | Platform for Agent Security.

An auth credential is how a client proves it may act as a consumer. Credentials are created at the gateway level and attached to one or more consumers, so you can rotate or share them independently of the consumer itself.

The same auth (API key or IdP credential) can be attached to several consumers. The request still targets a consumer by /{consumer_slug}/… — the credential proves access; the slug selects which consumer. Prefer one auth per consumer when you can; sharing is supported but weaker for audit and rotation.

This is distinct from a registry’s target auth, which is how TrustGate authenticates to the upstream provider.

Auth types

`type`	How the client authenticates	Routing mode
`api_key`	`X-AG-API-Key: ag_…` header	inline
`oauth2`	`Authorization: Bearer <jwt>` (or opaque token + introspection) validated against an OAuth2 provider	inline or role_based
`oidc`	`Authorization: Bearer <jwt>` from your IdP; claims select a role	inline or role_based
`mtls`	Client certificate (or a trusted `X-Forwarded-Client-Cert` header)	inline

Plane	Consumer auth types
LLM	`api_key`, `oauth2`, `oidc`
MCP	`oauth2`

A role_based LLM consumer carries exactly one identity credential — oauth2 or oidc.

API keys

API keys are prefixed ag_. The raw secret is returned once, at creation — store it then. TrustGate only persists a SHA-256 hash; at request time it hashes the inbound key and compares, so the secret is never recoverable from the gateway.

# create → returns api_key (cleartext) once
POST /v1/gateways/{gateway_id}/auths
{ "name": "my-app-key", "type": "api_key" }

# attach to a consumer
POST /v1/gateways/{gateway_id}/consumers/{id}/auths/{auth_id}

OAuth2 / OIDC / mTLS

JWT- and certificate-based credentials carry a config block:

Type	Config fields
`oauth2`	`issuer`, `audiences`, `jwks_url`, `introspection_url`, `client_id`/`secret`, `required_scopes`, `allowed_algorithms`, optional `session_mode`.
`oidc`	`issuer`, `audiences`, `jwks_url`, `public_keys`, `required_scopes`, `allowed_algorithms`, `subject_claim`.
`mtls`	`ca_cert`, `allowed_common_names`, `allowed_dns_names`, `allowed_fingerprints`.

For oidc credentials on a role_based consumer, the validated token’s claims are matched against role OIDC mappings to select the consumer’s routing — this is how identity-based routing works. For end-to-end, provider-specific setup (custom authorization servers, scopes, group/role claims, and the exact credential payloads), see the Authorization manuals for Okta and Entra ID.

Managing auth

CRUD lives under /v1/gateways/{gateway_id}/auths; attach/detach via the consumer’s …/auths/{auth_id} sub-resource. See the Auth API.

Introduction

Getting started

Core concepts

Routing

Policies

MCP

Observability

Operate

Admin API

API reference

Auth

Auth types

API keys

OAuth2 / OIDC / mTLS

Managing auth

​Auth types

​API keys

​OAuth2 / OIDC / mTLS

​Managing auth

Auth types

API keys

OAuth2 / OIDC / mTLS

Managing auth