Skip to main content
A policy turns detection into a decision. Detectors say what is in the traffic; a policy says what to do about it. You build policies in the console’s Policies screen, then attach them to collectors. A policy has five tabs: Gates, Detectors, Collectors, Test, and History — plus a policy-wide Enforcement mode.

​
Enforcement mode — Report vs Enforce

A single switch controls whether the policy can act: Report mode maps to the API’s report_only flag. A typical rollout runs a new policy in Report first, reviews findings, then flips to Enforce.

​
Gates: match before you detect

Gates are evaluated before any detector runs. A gate matches on request attributes (not content) and takes an action. Because they run first, gates are how you cheaply allow, block, or waive traffic without spending detection. Each gate is a set of conditions joined by And/Or, and a Then action: All gates are evaluated and the most restrictive outcome wins; if any gate blocks, the request is blocked and detection is skipped.

​
Condition attributes

Conditions target these request attributes: Operators: Equals (eq), Not equals (neq), Greater than (gt), Less than (lt), Contains (contains), Does not contain (not_contains), In (in — a comma‑separated list), Matches (match — a regular expression). The consumer.*, model.* and collector.type values come from the guard request’s attributes; collector.id, session.id and protocol are resolved by TrustGuard.

​
Detectors — run detectors and decide the action

The policy’s Detectors tab holds its detector rules, split by evaluation phase:
  • Input — evaluate the prompt/request.
  • Output — evaluate the completion/response.
At runtime TrustGuard only runs the rules for the phase that matches the request’s direction (input or output). The phase you configure here and the direction on each /v1/evaluate call must line up — otherwise those detectors never fire.
Who sets direction?
  • TrustGate sets it for you (input on the request path, output on the response path).
  • Any other collector (SDK, REST, browser, edge/WAF) must send direction explicitly on each call — typically two evaluates per turn (prompt then completion). Omitting it defaults to input, so Output-phase rules never run.
See Application integrations for SDK/REST examples, Integrations overview for the shared call shape, and How it works for how rules are filtered by direction.
Each rule references one detector, an action, and optional conditions (same attribute model as gates): All matching rules for the phase are evaluated. A block finding cuts the detection chain — the remaining detector rules in that phase are skipped. Otherwise, the completed rules reduce to the most restrictive action.

​
Verdict precedence

TrustGuard reduces everything that fired into one top‑level status, from most to least restrictive:
allow means nothing fired (or everything was waived). The caller enforces the verdict — see the Evaluate API.

​
Test and History

  • Test runs a sample input or output through the last saved version of the policy and shows the decision (Blocked / Transformed / Reported / Allowed) and every finding — without touching production or emitting telemetry.
  • History is the policy’s change log: created/updated/deleted events for the policy, its gates, its detector rules, and collector routing.

​
Routing: attaching policies to collectors

A policy runs when a collector routes traffic to it. On the policy’s Collectors tab you attach collectors with a routing mode:
  • Default — the collector’s fallback policy for all its traffic.
  • Consumer ID — the policy only applies to requests from a specific consumer, letting one collector send different consumers to different policies.
If a collector has no policy for a request, that request is unguarded (no gates, no detectors) and returns status: "allow" with no findings.