Detectors

Configure reusable detector instances and attach them to TrustGuard policies

A detector is a reusable, named instance you create from one entry in the detector catalog, such as prompt_guard, plus its settings. Settings can include thresholds, entity lists, and allow or deny lists. You create and edit detectors in the console’s Detectors screen, and the same detector can be referenced by many policies.

Detectors report what they find and their confidence. They do not decide whether to block, mask, or allow traffic. That decision lives on the policy that uses the detector (its Gates and Detectors tabs). This separation lets you reuse one well-tuned detector across many policies with different enforcement.

What defines a detector

Property	Values	Meaning
Type	one entry from the catalog	The catalog detector, such as prompt_guard or data_loss_prevention. Its type is fixed after creation; its settings remain configurable. Sent to the API as plugin_slug.
Name	free text	A label that distinguishes configured instances of the same detector type.
Settings	type-specific	Thresholds, entity lists, keyword or regular-expression lists, and other detector-specific values. The console renders and validates the form.
Enabled	on / off	A disabled detector is skipped everywhere it’s referenced.

A detector does not carry a mode, a direction, or a protocol. Those belong to the policy rule that puts the detector to work (the Input / Output phase). At request time, the collector must send the matching direction on /v1/evaluate. TrustGate sets it automatically; application SDKs and other collectors must set it themselves.

Settings

Every catalog detector exposes its own settings schema (the catalog API, GET /v1/plugins, returns each detector type and its fields). Examples:

• prompt_guard, toxicity: a threshold in [0, 1].
• data_loss_prevention: which PII entities to detect or mask, plus custom keyword/regex rules.
• Moderation (prompt_moderation): keyword or regular-expression lists and NeuralTrust topic thresholds.

See each detector’s full settings on its category page.

Mutable (transform-capable) detectors

Most detectors only read the payload. A mutable detector can rewrite it. Currently, only data_loss_prevention which masks matched values in flight and populates transformed_payload.

Only a mutable detector can be used with the Transform action in a policy; choosing Transform for any other detector is rejected when you save the policy.

Putting a detector to work

Creating a detector doesn’t run it. To evaluate traffic you reference the detector from a policy:

1. Open a policy and select the Detectors tab.
2. Pick an evaluation phase: Input (prompt/request) or Output (completion/response).
3. Add a rule that selects the detector and an action: Monitor (record a finding only), Block, or Transform (mutable detectors).
4. Optionally add conditions so the rule only runs for certain consumers, models, collectors, protocols, sessions, directions, or tools.

Then attach the policy to a collector so its traffic is evaluated.