Skip to main content
This page explains what is inside TrustGate Runtime and how a single request, tool call, or document upload becomes a security decision.

​
Two planes

TrustGate is organized as a control plane and one or more data planes. You interact with the control plane; traffic flows through the data plane.

Control plane

The console, policy store, detector registry, and APIs that you use to author policies, manage gateways, and explore logs. Managed by NeuralTrust in SaaS and hybrid deployments; self-hosted on-prem.

Data plane

The runtime components that sit on the traffic path — gateway-side proxies, browser extensions, API workers, and device-side local proxies. Always runs close to your traffic so prompts never leave your perimeter in hybrid and on-prem modes.
The control plane distributes policies to every data-plane component and aggregates signals back. That is what lets the same policy (for example, “Block PII in customer support”) enforce consistently across apps, browsers, and endpoints.

​
Enforcement surfaces

The data plane is not a single component. TrustGate enforces on four surfaces, each tuned to a different traffic source. Picking a surface is the first question the policy editor asks (Where).

Gateway

A gateway integration that applications send LLM traffic through. Routes can point at an LLM directly (acting as an embedded AI Gateway) or at a third-party AI gateway or custom backend (acting as a pure security layer on top).

Browser

The browser extension. Enforces on web-based LLMs (ChatGPT, Claude, Gemini, Copilot, Mistral Le Chat). Ideal for shadow AI and copy-paste exfiltration.

API

An API engine (Serverless or Dedicated) your backends call directly. For workloads that can’t be re-routed through a proxy but still want policy evaluation before the upstream call.

Endpoint

A transparent MITM proxy that managed devices route AI traffic to via an MDM-pushed PAC file. Zero software on the device; enforces on traffic from desktop apps, IDE plugins, and CLIs that never hit a central gateway or the browser.
All four surfaces share the same policy language, detector catalog, and decision model — only the enforcement mechanics differ. See Enforcement surfaces for the in-depth breakdown.
Routing objects (gateways, upstreams, routes) are not part of the Runtime Security architecture — they live in whichever AI gateway the Gateway surface sits on top of. For the NeuralTrust AI Gateway’s primitives, see AI Gateway → Overview and Routes & forwarding.

​
Plugins and the policy engine

Two concepts drive every decision:
  • Plugins are the detectors and transforms — jailbreak detectors, PII entity detection, toxicity, moderation categories, rate limiter, size limits, and more. Plugins run before (request) and after (response) the upstream call.
  • The policy engine consumes plugin output and decides an action. It evaluates the When conditions and resolves the final Then action using the precedence block ▶ mask ▶ log ▶ allow.
Plugins are stateless and composable; the policy engine is the single source of truth for decisions. You can always add a new detector without changing policies, or change a policy without touching detectors.

​
Request lifecycle

For an inline request through the Gateway surface: 
 client ─▶ gateway ingress ─▶ auth / identity ─▶ route match ─▶ request plugins
                                                                      │
                                                                      ▼
                                                              policy engine (request)
                                                                      │
                                                            allow │ mask │ log │ block
                                                                      │
                                                                      ▼
                                                                 upstream call
                                                                      │
                                                                      ▼
                                                               response plugins
                                                                      │
                                                                      ▼
                                                             policy engine (response)
                                                                      │
                                                                      ▼
                                                                   client
  1. Ingress — TLS termination, HTTP hardening, request normalization, size limits.
  2. Auth / identity — API key, mTLS, or token is validated.
  3. Route match — the first matching route selects the upstream(s) and plugin chain.
  4. Request plugins — detectors run: injections, jailbreaks, PII, moderation categories and more.
  5. Policy engine (request) — conditions are evaluated against plugin output; the request is allowed, masked, logged, or blocked.
  6. Upstream call — if allowed, an upstream is picked (load balancing, health check, failover) and the request is forwarded — streaming or not.
  7. Response plugins — detectors run on the response: PII, disallowed content, sensitive data, moderation categories and more.
  8. Policy engine (response) — the same action vocabulary applies on the response side.
  9. Egress — the response is returned to the client; the decision and evidence are emitted to the analytics pipeline.

​
Inline vs asynchronous

Deployment answers “where does it run”; enforcement answers “is it on the critical path”.

Inline (enforce)

TrustGate sits on the critical path. It can block or mask in real time. Recommended for production traffic where control is required.

Asynchronous (observe)

Traffic is mirrored to TrustGate without blocking. Use for rollout, baselining, or read-only audit environments before flipping to inline.
A common rollout is hybrid + asynchronous → hybrid + inline once policies are tuned. See Deployment modes.

​
Data & observability pipeline

Every decision emits a structured event. The data plane ships events through a message queue to analytical storage, and the control plane reads from that storage for dashboards, logs, and alerts. 
data-plane component ─▶ event bus (Kafka) ─▶ worker ─▶ analytical store (ClickHouse)
                                                                │
                                                                ▼
                                                 control plane (console / API)
                                                                │
                                                                ▼
                                                   dashboards · logs · SIEM export
  • Event bus decouples the critical path from analytics — a slow consumer never slows down traffic.
  • Analytical store powers logs, usage, and anomaly baselines.
  • Application store holds policy definitions and audit trails.
The pipeline is also how observability dashboards, alerts, and SIEM integrations are fed.

​
Policy scope and precedence

A policy’s scope is what the Create Policy editor builds in the Where and When steps.

Where — surface + filters

Pick exactly one surface — Gateway, Browser, API, or Endpoint — then optionally add filters to narrow the scope inside that surface. Each surface exposes its own filter set.

When — conditions

Signal-level rules: detections, categories, identities, or metadata that must match before the policy fires. Empty means every request in the scope.

​
Filters per surface

The + Add filter control inside Where exposes a different filter catalog per surface:
SurfaceAvailable filters
GatewayGateways · Routes · Tags · Use Cases
BrowserApplications
API— (no filters; applies to all API traffic on the surface)
EndpointDevice groups · Users · Tags · Use Cases
Filters intersect. A Gateway policy with Gateways = prod-eu and Routes = /openai/* applies only to requests matching both. A Where with no filters applies to all traffic on that surface.

​
Precedence when multiple policies match

A single request frequently matches more than one policy (a narrow team policy and a broad organization policy, for example). TrustGate evaluates all matches and resolves to a single outcome with two rules:
  1. Most restrictive action wins — block ▶ mask ▶ log ▶ allow.
  2. Masks compose — when several policies mask different fields, all masks apply before the request moves on.
This is what lets you safely layer: a permissive team-level policy never overrides a stricter organization-wide one, and a new detector can be rolled out with a broad log policy without loosening existing block rules.

​
Order in the console

Policies appear in a single ordered list per surface in the console. Order is for authoring clarity (recency, grouping); it does not change the precedence rules above — the action resolver is deterministic regardless of list position.

​
Multi-surface topology

Across all four surfaces, the topology is: 
┌───────────────┐   ┌────────────────┐   ┌────────────┐   ┌─────────────────┐
│  App / Agent  │   │ Browser tab    │   │  Backend   │   │ Managed device  │
└──────┬────────┘   └──────┬─────────┘   └─────┬──────┘   └────────┬────────┘
       │ gateway proxy     │ extension         │ API call          │ PAC → MITM proxy
       ▼                   ▼                   ▼                   ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                           TrustGate Data Plane                              │
│  Gateway  │  Browser workers  │  API engines  │  Endpoint (MITM proxy)      │
└───────────────────────────────┬─────────────────────────────────────────────┘
                                │ policies · signals
                                ▼
                        ┌──────────────────┐
                        │  Control Plane   │
                        │  (console · API) │
                        └──────────────────┘
The same policy, authored once, lands on whichever surfaces it targets. A single Block PII policy can protect your apps (Gateway), your users’ browser sessions (Browser), a partner integration (API), and a fleet of laptops (Endpoint) — all with the same detectors and the same log output.

Enforcement surfaces

The four surfaces in detail — when to pick each, how actions differ.

AI Gateway

The routing and interception layer inside the Gateway surface.

Policies & Enforcement

Conditions, plugins, actions, and scope.

Deployment modes

SaaS, hybrid, and on-prem options for the control and data planes.