Configuration

This is the values reference the model guides link into. Start from your model’s page — Hybrid, External, 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. Firewall follows.
`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 External. 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
Helm

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.

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.

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 workers

Firewall deploys with TrustGuard: no values are needed to get it. 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 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.

firewall.enabled, firewall.firewall.enabled, and trustguard.firewall.enabled have no effect on whether Firewall renders. Setting all three to false with TrustGuard on still produces the gateway and all five workers. To reduce its 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. 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, and no deployment command. 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.

Secrets

Key contracts for every Secret you supply.

Requirements

Dependencies, ports, and capacity.

Overview

Organization

Identity & Access

Telemetry

Audit & Compliance

Deployment

Values cheat sheet

Operational telemetry

What it contains

Where it goes

Why turn it on

Turn it on or off

What happens when you switch it

Managed stores

Ingress

Firewall workers

GPU Firewall workers

Central control plane values

Trusting a private control plane

Wizard-generated setup

TrustGate data-plane environment

Secrets

Requirements

​Values cheat sheet

​Operational telemetry

​What it contains

​Where it goes

​Why turn it on

​Turn it on or off

​What happens when you switch it

​Managed stores

​Ingress

​Firewall workers

​GPU Firewall workers

​Central control plane values

​Trusting a private control plane

​Wizard-generated setup

​TrustGate data-plane environment

​Related

Secrets

Requirements

Values cheat sheet

Operational telemetry

What it contains

Where it goes

Why turn it on

Turn it on or off

What happens when you switch it

Managed stores

Ingress

Firewall workers

GPU Firewall workers

Central control plane values

Trusting a private control plane

Wizard-generated setup

TrustGate data-plane environment

Related