Skip to main content
Runtime security cannot live in a single place. The same employee who calls your production LLM through a proxy also pastes prompts into ChatGPT in a browser tab, and their laptop runs a desktop app that calls an LLM directly. TrustGate enforces on four distinct surfaces so one policy library covers every path. When you create a policy, the first thing you pick is the Where → surface. That choice determines:
  • What traffic is visible to the policy.
  • Where enforcement physically happens — inside a gateway proxy, a browser extension, an API engine, or a transparent MITM proxy devices route to via a PAC file.
  • Which filters are available to narrow the scope further.
  • How Log, Mask, and Block translate into a concrete action on the wire.
All four surfaces are provisioned as Integrations in the platform (Integrations → Add Integration). Gateway and API integrations additionally let you pick a Deployment Type — Serverless or Dedicated — and issue their own per-engine API keys.

Gateway

LLM traffic through a TrustGate gateway. Routes decide whether it acts as an embedded AI Gateway or a pure security layer on top of a third-party gateway or backend.

Browser

A signed browser extension that enforces on web-based LLMs (ChatGPT, Claude, Gemini, Copilot, Mistral Le Chat). The surface for shadow AI and copy-paste exfiltration.

API

An API engine (Serverless or Dedicated) your backends call directly. For workloads that can’t be placed behind a proxy but can afford one extra HTTP round trip.

Endpoint

A transparent MITM proxy that managed devices route AI traffic to via an MDM-pushed PAC file. Zero software on the device; covers desktop apps, IDE plugins, and CLIs.

At a glance

SurfaceTraffic it seesRuns inIntegration?Filters
GatewayLLM traffic sent through a TrustGate gatewayGateway engine (Serverless or Dedicated); routes point at LLMs, third-party gateways, or custom backendsGateway (per-engine API keys)Gateways · Routes · Tags · Use Cases
BrowserPrompts typed or pasted into web-based LLMsTrustGate browser extension on the user’s browserBrowsersApplications
APIWhatever the caller sends to the Actions APIAPI engine (Serverless or Dedicated) exposing the Actions APIAPI (per-engine API keys)Engines · Tags · Use Cases
EndpointAI traffic from managed devices (IDEs, desktop apps, CLIs) to covered AI providersA transparent MITM proxy the device reaches via an MDM-pushed PAC file (no software on the device)EndpointEndpoints · Applications · Tags

Surfaces and actions

All four surfaces share the same detector catalog and the same policy language. Only the enforcement mechanics of Log, Mask, and Block differ — which is why the per-surface pages spell out each verb explicitly.
ActionGatewayBrowserAPIEndpoint
LogEvent recorded; traffic unchanged.Event recorded; UX unchanged.Decision + evidence returned; caller proceeds.Event recorded; traffic unchanged.
MaskPayload rewritten before upstream and on response.Input field / paste / upload rewritten in place before submit.Rewritten payload returned to the caller to use instead of the original.Request body (and non-streaming response bodies) rewritten by the proxy before they reach the upstream or the client.
BlockUpstream never called; client receives an error.Submit cancelled in the browser; content never leaves the machine.Decision = block returned; caller is expected to abort.Request blocked with a 403 JSON error; non-streaming responses replaced. Streaming responses can only be alerted (already delivered to the client).
Log, Mask, and Block on the Gateway and Browser surfaces are hard guarantees. On the Endpoint surface they are hard guarantees on requests and non-streaming responses; streaming responses can only be alerted. On the API surface enforcement is a contract the caller must honor.

Layering surfaces

Surfaces are not mutually exclusive. A mature deployment layers them so the same detection (for example PII) is blocked wherever a prompt can leave the perimeter:
  • Gateway for owned apps and agents — hard guarantee on your own traffic.
  • Browser for shadow AI in web chat apps.
  • Endpoint for desktop apps, IDE plugins, and CLIs.
  • API for backend jobs that can’t be proxied, or as a second-line check on another surface.
Because every surface shares the same detectors and policy language, writing Block PII on all four is cheap and consistent. The control plane aggregates decisions from every surface into a single log stream.

Decision guide

Use this table to pick a starting point; then add overlapping surfaces as your threat model grows.
Your concernStart with
Apps you built calling LLMs through an AI gateway (NeuralTrust or a third-party one)Gateway
Employees pasting data into ChatGPT / Claude / GeminiBrowser
Backend jobs that can’t be proxiedAPI
Desktop apps, IDE plugins, CLI tools talking to AIEndpoint