NeuralTrust | The leading security platform for generative AI

Beyond per-consumer auth, TrustGate hardens its own HTTP surface and its connections to upstream providers.

Admin authentication

The Admin plane requires a JWT (HS256) signed with SERVER_SECRET_KEY:

Authorization: Bearer <admin-jwt>

Keep SERVER_SECRET_KEY secret and rotate it like any signing key — anyone who can sign a token with it can administer every gateway. Mint short-lived tokens (see the Quickstart). The Proxy plane validates consumer credentials (API-key hash, OAuth2/OIDC JWT, or mTLS), and the MCP plane runs a full OAuth2 server — see MCP.

Security headers

A middleware sets hardened response headers on every plane:

X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: no-referrer
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-site
Strict-Transport-Security: max-age=31536000; includeSubDomains   # HTTPS only

Client TLS to upstreams

A gateway’s client_tls configures TLS per upstream hostname (keyed by host), so you can pin certificates or constrain protocols for specific providers:

Field	Purpose
`ca_cert`	Custom CA to trust.
`client_certs.{certificate, private_key}`	Mutual TLS to the upstream.
`min_version` / `max_version`	TLS version bounds.
`cipher_suites` / `curve_preferences`	Allowed cipher suites / curves.
`disable_system_ca_pool`	Trust only your `ca_cert`.
`allow_insecure_connections`	Skip verification (testing only).

mTLS clients

For consumer authentication by client certificate, use an mtls auth credential. When TrustGate runs behind a TLS-terminating proxy, set TRUST_XFCC_FROM to the trusted sources allowed to present the forwarded client-certificate (XFCC) header.

​Admin authentication

​Security headers

​Client TLS to upstreams

​mTLS clients

Admin authentication

Security headers

Client TLS to upstreams

mTLS clients