Skip to main content
A policy is how TrustGate turns signals from detectors into a decision you can enforce. Every prompt, response, document, or tool call that crosses a TrustGate surface is evaluated against the policies scoped to it. A policy always answers three questions:

Where

Which surface and filters this policy applies to. Defines the traffic the policy can see.

When

Which signals must match before the policy fires. Defines the subset of traffic that triggers it.

Then

Which action to take — Log, Mask, or Block. Defines what enforcement does on the wire.
You can read any policy as: “On Where, if When, then Then.”

​
Authoring policies from the UI

Policies are authored from Runtime → Policies → Create Policy. The modal has four blocks.

​
1. Name

A human-readable identifier — for example, Block PII in customer support. The name appears in lists, logs, alerts, and audit trails, so keep it descriptive and specific.

​
2. Where

Where has two parts: Surface — exactly one of:
SurfaceTraffic it covers
GatewayA gateway integration created in the platform. Routes can target LLM providers directly (embedded AI Gateway) or sit on top of a third-party AI gateway or custom backend.
BrowserPrompts in web-based LLMs via the browser extension.
APIAn API engine (Serverless or Dedicated) your backends call directly, per-engine API keys.
EndpointAI traffic from managed devices routed through a transparent MITM proxy via an MDM-pushed PAC file (no software on the device).
Filters (optional) — narrow the scope inside the surface using + Add filter. Each surface exposes a different catalog:
SurfaceAvailable filters
GatewayGateways · Routes · Tags · Use Cases
BrowserApplications
APIEngines · Tags · Use Cases
EndpointEndpoints · Applications · Tags
With no filters, the policy applies to all traffic on the surface. Filters intersect — adding two filters means both must match. See Enforcement surfaces for a full per-surface breakdown.

​
3. When

When expresses conditions on the detections TrustGate produces. Each condition has three parts:
PartWhat it is
FieldWhere on the traffic the condition evaluates — for example Input (what the user typed or sent). The set of fields depends on the surface.
OperatorTriggers or Does not trigger.
ValueOne or more detections picked from a catalog, grouped by category.

​
Detections catalog (Browser surface)

For the Browser surface, the Value picker shows two categories:
CategoryDetections
PII & ConfidentialEmail Address · Phone Number · Social Security Number · Credit Card · API Key / Secret
File SecurityFile Upload · PII in Files
Other surfaces expose their own catalogs (for example, Gateway adds jailbreak, toxicity, prompt injection, tool-call detections). The condition shape — Field · Triggers / Does not trigger · Detections — is the same everywhere.

​
Combining conditions

Add more rows with + Add Condition. Conditions always combine with AND — every row must match for the policy to fire. There is no OR operator. For OR semantics, create multiple policies that share the same Then action. Leaving When empty means the policy fires on every request in the Where scope — useful for blanket Log rules while you tune more specific policies.

​
4. Then

Then is the action when the conditions match:
ActionEffect
LogRequest passes through; the event is recorded for audit, review, and alerting.
MaskSensitive fragments (PII, secrets, custom entities) are redacted or tokenized before the request continues.
BlockRequest is rejected before the upstream call; the caller receives an error and the upstream is never reached.
Exactly one action is required. Action semantics vary slightly per surface — see Enforcement surfaces for how Mask and Block translate on Browser and Endpoint.
Allow is the implicit default. A request that doesn’t match any policy’s conditions is allowed.

​
Precedence when multiple policies match

A single request usually matches more than one policy — a narrow team policy and a broad org-wide policy, for example. TrustGate resolves all matches to a single outcome:
  1. Most restrictive action wins — block ▶ mask ▶ log ▶ allow.
  2. Masks compose — if two policies mask different fields, both masks are applied before the request continues.
  3. Order in the list is authoring-only — it does not change the precedence rules above.
This is what makes layering safe: a permissive team policy never overrides a stricter organization policy, and a new detector can be rolled out under a broad Log policy without loosening existing Block rules.

​
Example policies

Three patterns you’ll see in most deployments. Block PII pastes into ChatGPT
  • Where — Browser + filter Apps = ChatGPT
  • When — Input · Triggers · Email Address, Phone Number, Credit Card, Social Security Number, API Key / Secret
  • Then — Block
Log file uploads with PII into web LLMs
  • Where — Browser + filter Apps = ChatGPT, Claude, Gemini
  • When — Input · Triggers · PII in Files
  • Then — Log (plus alert via SIEM)
Mask credentials on provider routes
  • Where — Gateway + filter Routes = /openai/*, /anthropic/*
  • When — Input · Triggers · API Key / Secret
  • Then — Mask

​
Lifecycle

Policies live under Runtime → Policies alongside Logs and the Playground.
StageWhat you do
DraftAuthor the policy in Log mode to observe impact without affecting traffic.
ReviewInspect hits in Logs, replay traffic in Playground, confirm false-positive rate.
EnforceFlip the action to Mask or Block.

​
Best practices

  • Start in Log. Every new policy should be born as Log, reviewed against real traffic, and only then promoted to Mask or Block.
  • Write one concern per policy. “Block PII on /openai/*” and “Log PII on /anthropic/*” are two policies, not one with conditional logic. Easier to version, review, and audit.
  • Prefer filters over conditions for routing. Use Where → filters to scope by app or route; reserve When for signal-driven logic. Keeps policies readable.
  • Layer across surfaces. The same policy intent (for example, “block credentials”) is cheap to replicate on Gateway, Browser, and Endpoint — write it once per surface, not as one giant policy.
  • Name for audit. [Compliance] Block PII — EU providers reads better in a SIEM than policy-42.