Configuration

Every chart switch that changes a deployment — products, datastores, operational telemetry, ingress, Firewall workers, and cross-cluster endpoints.

This is the values reference the model guides link into. Start from your model’s page — Hybrid, Self-hosted, or Central — and come here for the individual settings.

The exhaustive list, with every default, is values.yaml in the chart.

​

Values cheat sheet

The switches that matter most. In Hybrid, global.products is opt-in: set a product to true to run it. In External and Central it is opt-out: set a product to false to leave it out (TrustGuard only).

Value	Guidance	Effect
global.deploymentMode	hybrid | external | saas	Selects the topology. saas is a Central control plane that you run.
global.controlPlane.domain	Empty for NeuralTrust SaaS	A bare DNS suffix enrols this data plane into your own central control plane instead.
global.products.trustgate	true to run TrustGate	Renders the TrustGate proxy and MCP data plane. Hybrid needs at least one product.
global.products.trustguard	true to run TrustGuard	Renders the TrustGuard data plane. In Hybrid it calls the NeuralTrust-hosted Firewall unless global.firewall.deploy: true; see Firewall.
global.products.dataPlane	true for the red-teaming shim	Renders the data-plane API. Needs no DataAgent and no config sync.
global.postgresql.deploy	false in production	true runs an in-cluster store, which is the proof-of-concept default.
global.redis.deploy	false in production	Same for Redis.
agentgateway.configSync.existingSecret	Reference your Secret	TrustGate config-sync token. Config sync is on by default in Hybrid — do not restate enabled: true.
trustguard.configSync.existingSecret	Reference your Secret	TrustGuard config-sync token.
agentgateway.dataagent.enrolment.existingSecret	Reference your Secret	TrustGate DataAgent enrollment token (OTLP egress and DataBridge).
trustguard.dataagent.enrolment.existingSecret	Reference your Secret	TrustGuard DataAgent enrollment token.
agentgateway.mcp.enabled	true	TrustGate MCP entry point.
global.platform	aws | gcp | azure | openshift | kubernetes	Selects provider-specific ingress and storage behaviour.
global.imageRegistry	Your mirror	Rewrites the registry prefix — see Container images.
global.imageRegistryScope	all	Also moves the OTel collector images onto global.imageRegistry.
global.autoGenerateSecrets	true	Chart owns the credentials it can generate.
global.preserveExistingSecrets	false	For GitOps: pre-create every Secret and set true.
global.observability.operationalTelemetry	false by default; recommended true	TrustGate and TrustGuard export their own health traces and metrics — see Operational telemetry.

Leave watchdog.enabled off unless NeuralTrust asks you to enable it.

Product telemetry export is mandatory in Hybrid and always on — there is no global.clickstack.enabled: false opt-out. TrustGate and TrustGuard send OTLP to a co-located, enrollment-backed egress collector, which is why the enrollment tokens are required. For a deployment with no NeuralTrust dependency at all, use Self-hosted. Operational telemetry, below, is separate and off unless you turn it on.

​

Operational telemetry

Operational telemetry is TrustGate and TrustGuard reporting on their own health — how many requests they serve, how many fail, and how long they take — rather than on the traffic they inspect. It is off by default and controlled by one value, global.observability.operationalTelemetry.

	Product telemetry	Operational telemetry
Describes	Each request your gateways handle: request metadata, timings, detector verdicts, and counts	The services themselves: server spans, request rate, errors, and latency
Hybrid	Always on, exported to NeuralTrust	Off until you set true; then exported to NeuralTrust
External	Your in-cluster ClickHouse	Your in-cluster collector. TrustGuard’s is always on; TrustGate’s is off until you set true
Prompt and response payloads	Not exported	Not exported

​

What it contains

• TrustGate exports server spans and HTTP request rate, error, and duration metrics. Health and readiness probe requests are sampled at 1%; every other request is traced at 100%.
• TrustGuard exports traces and metrics for evaluation latency and errors.

The attributes are operational: route templates, status codes, durations, and verdict and plugin labels. Neither service exports prompts or responses through this path.

​

Where it goes

Model	Destination
Hybrid	NeuralTrust, through the same telemetry egress collector that already carries product telemetry, authenticated with the DataAgent enrollment credentials. There are no new hosts to allow, no new Secrets, and no new firewall rules.
External	Your in-cluster collector. It does not leave your environment.

In Hybrid, turning it on means NeuralTrust receives health data about your gateway and TrustGuard in addition to product telemetry. That is why it is a choice you make, not a default.

​

Why turn it on

With operational telemetry on in Hybrid, NeuralTrust support can see the health of your TrustGate and TrustGuard — error spikes, latency, saturation — and diagnose problems from it directly, often without asking you for logs or a support bundle. Turning it on is the recommended practice for faster support.

Turn it on while a support case is open. If you prefer to keep it off day to day, enable it when you open a case and disable it once the case is closed. Each switch is one upgrade and a rolling restart, so it is cheap to flip both ways.

​

Turn it on or off

ntctl

ntctl install asks whether to turn it on. To answer up front, for example in a script:

ntctl install --operational-telemetry=true

On an existing install, switch it with ntctl upgrade. Pass the chart version you already run, which ntctl status prints, so the switch changes nothing else. Without --version, ntctl upgrade also moves you to the latest chart.

ntctl upgrade --operational-telemetry=true  --version <installed version>   # turn on
ntctl upgrade --operational-telemetry=false --version <installed version>   # turn off

An upgrade without the flag keeps the current setting. ntctl never turns operational telemetry on by itself.

Helm

Switch it on a running release, keeping every other value as it is. Pass the --version you already run, so the switch does not also upgrade the chart:

helm upgrade neuraltrust-platform \
  oci://europe-west1-docker.pkg.dev/neuraltrust-app-prod/helm-charts/neuraltrust-platform \
  --version <VERSION> \
  --namespace neuraltrust \
  --reuse-values \
  --set global.observability.operationalTelemetry=true   # or false

If you upgrade from a values file rather than with --reuse-values, set it there instead. Otherwise the next upgrade from that file returns it to false:

global:
  observability:
    operationalTelemetry: true

​

What happens when you switch it

The TrustGate and TrustGuard pods roll with the new setting in a normal rolling update. Their Deployments carry a checksum of the configuration that changes, so no manual rollout restart is needed. Nothing else is reconfigured: config sync, policies, and product telemetry are untouched, and there is no downtime beyond the rolling restart. Telemetry starts or stops within a minute or two of the new pods becoming Ready.

The single value is the supported switch. For finer control, the chart’s per-component environment variables can override it through extraEnv — OPS_TRACES_ENABLED and OPS_METRICS_ENABLED set to "false" in the extraEnv of a TrustGate component (agentgateway.dataPlane, agentgateway.mcp, or, in External, agentgateway.controlPlane), or OPENTELEMETRY_ENABLED set to "false" in trustguard.dataPlane.extraEnv.

​

Managed stores

Managed PostgreSQL and Redis are the usual production choice in every self-hosted model. Pre-create the database, role, and Redis credentials on the managed instance, or, in External, let the chart create the PostgreSQL roles and databases with an administrator login you provide — see Let the chart create the roles. The chart can still run both in-cluster with deploy: true for evaluation; in External and Central mode that path also bootstraps the per-service roles automatically.

global:
  postgresql:
    deploy: false
    host: postgres.example.com
    port: 5432
    user: neuraltrust
    database: neuraltrust
    sslMode: require
    passwordSecret:
      name: external-postgresql
      key: POSTGRES_PASSWORD
  redis:
    deploy: false
    host: redis.example.com
    port: 6379
    tls: "true"
    existingSecret:
      name: external-redis

How you supply credentials depends on the topology:

Topology	Endpoints	Credentials
Hybrid	global.postgresql / global.redis (one shared role)	Password via global.postgresql.passwordSecret, or a whole Secret via global.postgresql.existingSecret with the DB_* key contract
External / Central	The same global blocks — per-service hosts inherit them	Control-plane password via global.postgresql.passwordSecret; runtime roles via per-service existingSecret hooks

A Secret you supply through postgresql.existingSecret is consumed with envFrom and never renamed, so it must hold DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME, DB_SSL_MODE and, in Hybrid, SENSIBLE_PG_DSN — not the POSTGRES_* names the chart uses in its own Secret. Prefer the narrower global.postgresql.passwordSecret, which keeps the chart’s Secret and replaces only the password. See Bringing your own Secret.

Store	Minimum for production
PostgreSQL	2 vCPU, 4 GiB RAM, 20 GiB storage
Redis	1 GiB memory

Provider	PostgreSQL	Redis
AWS	RDS/Aurora db.t4g.medium, 20 GiB+	ElastiCache cache.t4g.small
GCP	Cloud SQL db-custom-2-4096, 20 GiB+	Memorystore 1 GiB
Azure	Flexible Server 2 vCores / 4 GiB, 20 GiB+	Cache for Redis C1 (1 GiB)+

Reach both over private networking from the cluster. When you run two clusters across regions, they share one writable PostgreSQL primary with a cross-region read replica, and each region gets its own Redis — see High availability.

​

IAM database authentication

Against a managed PostgreSQL (global.postgresql.deploy: false), set global.postgresql.authMode: iam to have the services log in with a short-lived cloud token instead of a static password. The chart’s own PostgreSQL has no token login, so authMode: iam is ignored there.

Each runtime service’s database.iamAuth inherits the global setting when you leave it unset. Set it explicitly to true or false only for a mixed-auth install where one service keeps a password.

Which cloud mints the token follows the identity block you configure:

Identity block	POSTGRES_LOGIN	Database
None (default)	aws	RDS / Aurora with IRSA. Set global.postgresql.awsRegion
global.azureIdentity.method	azure	Azure Database for PostgreSQL with Microsoft Entra ID
global.gcpIdentity.method	gcp	Cloud SQL or AlloyDB with IAM database auth

With token auth, global.postgresql.sslMode must be require, verify-ca or verify-full; the services refuse to start over anything weaker. The bootstrap Jobs never run under IAM auth, so you pre-create every role and database yourself.

​

Cloud SQL and AlloyDB (GKE)

Works in every deployment mode, with GKE Workload Identity:

global:
  gcpIdentity:
    method: workload-identity
  postgresql:
    deploy: false
    host: 10.10.0.5
    authMode: iam
    sslMode: require
    user: "[e-mail]"

Every PostgreSQL client — TrustGate, TrustGuard, DataAgent, DataCore, AlertEngine, data-plane-api, and the control-plane API and console — then gets POSTGRES_LOGIN=gcp and mints a token from Application Default Credentials for each new connection.

• Database users. Each user is a Google service account’s email without .gserviceaccount.com, for example [e-mail]. The control plane’s is global.postgresql.user (also every Hybrid client’s); the others are <service>.database.user. A full email is refused at render.
• Identities. Map each Google service account to its Kubernetes ServiceAccount with iam.gke.io/gcp-service-account in <service>.serviceAccount.annotations, and in control-plane-api.controlPlane.serviceAccount.annotations for the shared control-plane ServiceAccount. To use one Google service account for everything instead, set global.gcpIdentity.serviceAccount and global.gcpIdentity.applyGlobally: true.
• Instance setup, once per service account.

  1. Enable the cloudsql.iam_authentication (Cloud SQL) or alloydb.iam_authentication (AlloyDB) flag.

  2. Create the user with gcloud sql users create <user> --type=cloud_iam_service_account or gcloud alloydb users create <user> --type=IAM_BASED.

  3. Grant roles/cloudsql.instanceUser and roles/cloudsql.client (Cloud SQL), or roles/alloydb.databaseUser and roles/serviceusage.serviceUsageConsumer (AlloyDB), plus roles/iam.workloadIdentityUser for <project>.svc.id.goog[<namespace>/<serviceaccount>].

  4. As an administrator, create each database owned by its user, and enable pgcrypto in the TrustGuard database:

     CREATE DATABASE trustguard;
     ALTER DATABASE trustguard OWNER TO "[e-mail]";
     -- connected to the trustguard database:
     CREATE EXTENSION IF NOT EXISTS pgcrypto;
     

GCP IAM auth needs service images that accept POSTGRES_LOGIN=gcp. An older pinned image tag stops at boot instead of trying a password against a passwordless role. Installs that do not set global.gcpIdentity render unchanged.

​

Memorystore for Redis Cluster (GKE)

For Memorystore for Redis Cluster or Valkey with IAM auth, combine global.gcpIdentity with three opt-in global.redis keys:

global:
  gcpIdentity:
    method: workload-identity
  redis:
    deploy: false
    host: 10.10.0.20 # the discovery endpoint
    port: 6379
    tls: "true"
    authMode: iam
    cluster: true
    caSecret:
      name: redis-ca
      key: ca.pem

Key	Effect
authMode: iam	TrustGate, TrustGuard and data-plane-api send a Google access token as the AUTH password (REDIS_LOGIN=gcp). No Redis password is needed: leave any <service>.redis.existingSecret unset.
cluster: true	A cluster client seeded from the discovery endpoint (REDIS_CLUSTER=true). A Redis Cluster has database 0 only, so a non-zero agentgateway.redis.db or data-plane-api redis.db is refused.
caSecret	A Secret holding the server CA bundle, mounted at /etc/neuraltrust/redis-ca/ca.pem (REDIS_TLS_CA_FILE), including in data-plane-api’s evaluation Jobs.

Each service account needs roles/redis.dbConnectionUser. For Memorystore, put every certificate printed by gcloud redis clusters get-cluster-certificate-authority <cluster> into one file and create the Secret from it:

kubectl create secret generic redis-ca -n neuraltrust --from-file=ca.pem=./redis-ca.pem

These keys apply only to a Redis you run (deploy: false). Installs that set none of them render unchanged.

​

Ingress

global:
  platform: aws
  domain: platform.example.com
  storageClass: gp3
  ingress:
    className: alb
    aws:
      certificateArn: arn:aws:acm:region:account:certificate/id

global.domain combines with default host prefixes to render the public names. In Hybrid that is two: gateway.<domain> for the LLM/proxy Ingress and mcp.<domain> for MCP. External and Central add the console, its API, and the gateway admin surface.

The chart creates separate agentgateway-gateway and agentgateway-mcp Ingress resources backed by separate Services. Each Service exposes port 80: the proxy Service targets TrustGate container port 8081 and the MCP Service targets 8082. Set the corresponding full URLs, including https://, in Settings → Agent Gateway → General — global.domain does not update those console settings.

The chart can auto-add wildcard hosts (*.llm.<domain> / *.mcp.<domain>) for slug-based gateway discovery; set agentgateway.config.autoWildcardHosts: false to use exact hosts instead. Ingress class, annotations, and certificate sources are provider-specific — see Cloud notes.

With two clusters active/passive, put one global LLM URL and one global MCP URL in front of both clusters’ Ingress resources and configure those stable URLs in the console.

​

Firewall

The Firewall holds the ML detectors TrustGuard calls. In every mode it is NeuralTrust-hosted by default — the inference plane — and global.firewall.deploy: true runs it in your cluster instead.

Mode	Where the firewall key comes from
Hybrid	app.neuraltrust.ai shows it once, when it creates the private TrustGuard
External, Central	Ask NeuralTrust before you deploy; it is sent to you over a secure channel. Central needs one per cluster that runs TrustGuard, remote clusters included

NeuralTrust-hosted Firewall. TrustGuard authenticates with its own FIREWALL_JWT: a per-install client that carries the Firewall URL, so no signing key is shared with your cluster, and the client can be revoked on its own. Store it in a Secret (key FIREWALL_JWT):

trustguard:
  firewall:
    jwtExistingSecret:
      name: "trustguard-firewall"

trustguard.firewall.jwt takes the token inline instead. TrustGate’s smart-routing complexity scoring takes its own token the same way, under agentgateway.firewall. The hosts are firewall.neuraltrust.ai (EU) and firewall.us.neuraltrust.ai (US), on 443 or over Private Service Connect. The Firewall is stateless: it scores the text it receives and stores none of it.

Installs that run the Firewall in their cluster, in any mode: add global.firewall.deploy: true to your values before upgrading to keep it. Without it, and without a TrustGuard firewall JWT, the upgrade stops with an error that names both options. Air-gapped installs, which cannot reach the hosted Firewall, keep deploy: true.

An install with TrustGuard and neither a firewall JWT nor deploy: true fails at render time, so the ML detectors never go dark silently. A Firewall you run yourself is also supported: deploy: false with global.firewall.baseURL and its JWT_SECRET in global.firewall.existingSecret.

​

In-cluster Firewall workers

With the Firewall in your cluster, no further values are needed. The chart renders two gateway replicas and one replica for each of the five default workers — toxicity, indirect-prompt-injections, prompt-jailbreak, prompt-moderation, and response-jailbreak — all on the firewall-cpu image pinned by your chart version.

Default worker requests are 1 CPU and 3 GiB, with 2 CPU and 4 GiB limits; prompt-moderation overrides memory to 4 GiB requested and 6 GiB limited, and topic-guard raises its memory limit to 5 GiB. Official images bundle their models, so HUGGINGFACE_TOKEN is optional. This is the largest memory consumer in the data path, so it is the first thing to right-size if you run a subset of detectors.

TrustGuard then derives NEURAL_TRUST_FIREWALL_BASE_URL as http://firewall.<namespace>.svc.cluster.local and maps firewall-secrets/JWT_SECRET to its client secret. Both sides are wired by the chart, so there is nothing to configure, and a trustguard.firewall.jwt is ignored.

firewall.enabled, firewall.firewall.enabled, and trustguard.firewall.enabled have no effect on whether Firewall renders; only global.firewall.deploy does. To reduce its in-cluster footprint, size the workers instead.

​

GPU Firewall workers

Chart defaults are CPU. GPU mode needs a NeuralTrust-provided firewall-gpu image plus explicit GPU resources and scheduling, and a separate GPU node pool. It also needs global.firewall.deploy: true, since the Firewall otherwise runs at NeuralTrust. Keep the gateway on the CPU image:

firewall:
  firewall:
    gateway:
      image:
        repository: registry.example.com/neuraltrust/firewall-cpu
    workerDefaults:
      image:
        repository: registry.example.com/neuraltrust/firewall-gpu
      resources:
        requests:
          cpu: "1"
          memory: 4Gi
          nvidia.com/gpu: "1"
        limits:
          cpu: "2"
          memory: 8Gi
          nvidia.com/gpu: "1"
      nodeSelector:
        accelerator: nvidia
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      hostIPC: true
    # prompt-moderation and topic-guard carry their own resources in the chart
    # defaults, which replace workerDefaults.resources, so restate the GPU.
    workers:
      prompt-moderation:
        resources:
          requests:
            nvidia.com/gpu: "1"
          limits:
            memory: 8Gi
            nvidia.com/gpu: "1"
      topic-guard:
        resources:
          requests:
            memory: 4Gi
            nvidia.com/gpu: "1"
          limits:
            memory: 8Gi
            nvidia.com/gpu: "1"
    config:
      cudaMpsActiveThreadPercentage: "25"
      cudaMpsPinnedDeviceMemLimit: "6000M"

Each of the seven workers requests one GPU. Configure the GPU node pool to share every GPU among four CUDA MPS clients, so that two L4 nodes can host all seven workers. On GKE, set the node pool’s GPU sharing strategy to MPS with max_shared_clients_per_gpu = 4; on EKS, enable MPS sharing in the NVIDIA device plugin with four replicas. Four is the most an L4 can hold: each client may pin up to 6000 MB of device memory, and the L4 has 24 GB. Without sharing, every worker needs a GPU of its own. Node counts for each deployment model are in Capacity.

This matches values-dataplane-gpu.yaml.example, which ships with the chart. Install the vendor device plugin and validate node labels first. CUDA MPS and hostIPC may require extra security approval, especially on OpenShift. If GPU pods stay Pending, inspect resource availability, taints, node labels, and the NVIDIA device plugin with kubectl describe pod.

​

Central control plane values

These apply only on the central cluster, under global.deploymentMode: saas. Data-plane clusters need none of them — they set global.controlPlane.domain and are otherwise ordinary Hybrid installs.

Value	Guidance	Effect
global.controlPlane.domain	Required	Bare DNS suffix every cross-cluster endpoint derives from. No scheme, port, or path.
databridge.auth.mode	introspect	How DataBridge identifies each data plane. jwt also works; token and dev are rejected because they share one credential across every agent.
databridge.tls.existingSecret	One of three	kubernetes.io/tls Secret covering databridge.<domain>.
databridge.tls.certManager.enabled	One of three	cert-manager issues it from an Issuer you already run.
databridge.tls.autoGenerate	One of three	Chart mints a self-signed CA and keypair. The route for a control plane on a private network; distribute the CA with scripts/export-controlplane-ca.sh.
databridge.service.southbound.annotations	Provider-specific	Free-form annotations on the LoadBalancer, for example an internal NLB on EKS.
databridge.service.southbound.loadBalancerSourceRanges	Set in production	Restrict to your data-plane egress ranges. Empty means anyone who can reach the load balancer can open a connection.
agentgateway.configSync.expose.enabled	true	Publishes the TrustGate config-sync listener. false keeps it ClusterIP behind a private link.
agentgateway.configSync.grpcTls.existingSecret	One of two, when exposed	Certificate for agentgateway-configsync.<domain> from a CA the data planes already trust.
agentgateway.configSync.expose.selfSignedTls	One of two, when exposed	Publish with the chart’s own certificate and distribute its CA as configuration.
trustguard.configSync.expose.enabled	true	Same for TrustGuard.
trustguard.configSync.grpcTls.existingSecret	One of two, when exposed	Certificate for trustguard-configsync.<domain>.
trustguard.configSync.expose.selfSignedTls	One of two, when exposed	Same for TrustGuard.
clickstack-ingest-gateway.ingress.tls.secretName	One of two	Certificate for telemetry.<domain>. This endpoint terminates at the ingress, so ACM works here.
clickstack-ingest-gateway.ingress.tls.autoGenerate	One of two	Chart mints a self-signed CA and leaf for the telemetry host.

The chart refuses to render an endpoint with no certificate at all, rather than publishing one nothing outside the cluster can verify. The self-signed CA it generates is not in any remote cluster’s trust store until you put it there.

​

Trusting a private control plane

Set these on a remote cluster when the central control plane serves chart-generated or private-PKI certificates. Each replaces the system roots for that connection, so the bundle must carry every CA that leg needs.

Value	Guidance	Effect
global.customCaCert.enabled / .secretName	Required	Mounts the bundle’s ca.crt into every pod, by default at /etc/ssl/certs/custom-ca.crt.
dataagent.databridge.tlsCa	Path	CA bundle DataAgent verifies DataBridge against. Also required by the binary when tlsMode: mtls.
agentgateway.configSync.tlsCa	Path	CA bundle for the TrustGate config-sync endpoint.
trustguard.configSync.tlsCa	Path	CA bundle for the TrustGuard config-sync endpoint.
global.clickstack.egress.tlsCaSecretName	Secret name	CA for the telemetry endpoint. A Secret name, not a path: the collector configures TLS from its own config and ignores the mount above.

​

Wizard-generated setup

The private gateway wizard’s Kubernetes output is credential and setup input, not an install-ready chart contract. Map its values into the maintained chart’s interfaces rather than applying it unchanged, and move every credential into pre-created Secrets — see Console setup and Secrets.

Docker is for local evaluation of the LLM/proxy path. Its generated Compose command injects a generated CONFIG_SYNC_LKG_KEY and the two wizard-issued tokens, and needs three more values from you:

• SERVER_SECRET_KEY — a random value of at least 32 bytes
• CONFIG_SYNC_GRPC_ENDPOINT — the config-sync endpoint as host:port
• DATABRIDGE_ADDR — the DataBridge endpoint as host:port

That path starts TrustGate’s LLM/proxy process on 8081 and does not start or expose MCP on 8082. Use Kubernetes for production MCP support.

Manual returns CONTROL_PLANE_JWT and DATA_AGENT_JWT for fully custom manifests, plus FIREWALL_JWT for the NeuralTrust-hosted Firewall, and no deployment command. Pass FIREWALL_JWT to the TrustGuard data plane under that name.

TrustGate listens on these ports by default:

Entry point	Port
Admin (External and Central only)	8080
LLM/proxy	8081
MCP	8082

​

TrustGate data-plane environment

Optional variables you may set on the TrustGate proxy and MCP pods, beyond what the chart and the wizard generate.

Variable	Guidance	Effect
MCP_OAUTH_CLIENT_NAME	One name per environment	The client_name TrustGate registers with upstream MCP authorization servers through dynamic client registration — what users see on the upstream consent screen. Defaults to TrustGate MCP Gateway. Changing it re-registers the cached clients, and grants held by the previous registration can no longer be refreshed.
PLAYGROUND_TOKEN_PUBLIC_KEYS	Usually empty in Hybrid	RS256 public keys that verify playground and diagnostics tokens minted by the control plane; a bare PEM or a JSON array of {kid, pem}. Falls back to ADMIN_M2M_PUBLIC_KEYS when unset. Config-sync data planes also receive these keys in the snapshot.
PROXY_SERVE_HYBRID_GATEWAYS	Leave the default	Whether this proxy serves gateways entitled as data_plane=hybrid. Defaults to the value of CONFIG_SYNC_DATA_PLANE_ENABLED, so a config-sync data plane serves them and a hosted proxy answers 421 for them instead. Set true only on a customer-run data plane that is not DB-less.
PROVIDER_ALLOW_PRIVATE_NETWORKS	Leave unset on your own install	Whether gateways may reach model providers and guardrail services such as Azure Content Safety on private, loopback or link-local addresses. Defaults to true, because a self-run gateway normally reaches your private model hosts and private endpoints. Set false if people you do not fully trust can configure gateways, so they cannot aim TrustGate at your internal network.
MODEL_ARMOR_ALLOW_AMBIENT_IDENTITY	Leave unset on your own install	Whether Model Armor policies may authenticate as the gateway’s own cloud identity (Workload Identity, application default credentials or service-account impersonation) instead of a service-account key. Defaults to true. Set false under the same condition as above, so nobody who configures a gateway can borrow its identity.

​

Related

Secrets

Key contracts for every Secret you supply.

Requirements

Dependencies, ports, and capacity.