Skip to main content
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/IDP 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:
FieldPurpose
ca_certCustom CA to trust.
client_certs.{certificate, private_key}Mutual TLS to the upstream.
min_version / max_versionTLS version bounds.
cipher_suites / curve_preferencesAllowed cipher suites / curves.
disable_system_ca_poolTrust only your ca_cert.
allow_insecure_connectionsSkip 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.