Use this file to discover all available pages before exploring further.
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.”
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.
A 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.
Browser
Prompts in web-based LLMs via the browser extension.
API
An API engine (Serverless or Dedicated) your backends call directly, per-engine API keys.
Endpoint
AI 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:
Surface
Available filters
Gateway
Gateways · Routes · Tags · Use Cases
Browser
Applications
API
Engines · Tags · Use Cases
Endpoint
Endpoints · 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.
For the Browser surface, the Value picker shows two categories:
Category
Detections
PII & Confidential
Email Address · Phone Number · Social Security Number · Credit Card · API Key / Secret
File Security
File 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.
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.
Request passes through; the event is recorded for audit, review, and alerting.
Mask
Sensitive fragments (PII, secrets, custom entities) are redacted or tokenized before the request continues.
Block
Request 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.
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:
Masks compose — if two policies mask different fields, both masks are applied before the request continues.
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.
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.
