Skip to main content
A detector is a named, reusable instance you create from one entry in the detector catalog — Prompt Guard, Data Loss Prevention, and so on — plus how you tuned it. 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. They do not decide whether to block, mask, or allow. That decision lives on the policy that uses the detector. The separation is the point: tune one detector well, then enforce it differently in each policy that references it.

​
What defines a detector

A detector carries no phase and no protocol. Those belong to the policy rule that puts it to work — Input for the prompt, Output for the response. Whether both phases actually run depends on the collector. A gateway sees the request and the response, so both do. A hook that only fires on the prompt has nothing to evaluate on Output, and an Output rule there will simply never match.

​
What you actually configure

Far less than people expect. Most detectors have one control: Two consequences worth knowing before you start:
  • There are no thresholds to type. Sensitivity is three cards — Permissive, Balanced, Strict. Balanced is applied by default.
  • Linked detectors are shared, not copied. URL Analyzer and Document Analyzer point at a Prompt Guard detector and a Data Loss Prevention detector you already made. Retuning either one changes the analyzers too, along with every policy using them.
Full detail is on each category page: data loss prevention, content security, and agent and MCP security.

​
Detectors that can mask

Most detectors only read the payload. Data Loss Prevention is the only one that can rewrite it, masking matched values in flight. That is why Transform is available only on a policy rule that references Data Loss Prevention. Choosing Transform for any other detector is rejected when you save the policy.

​
Putting a detector to work

Creating a detector does not run it. Nothing is evaluated until a policy references it and that policy is attached to a collector:
  1. Open a policy and select the Detectors tab.
  2. Pick the phase: Input for the prompt or request, Output for the completion or response.
  3. Add a rule selecting the detector and an action — Monitor to record a finding only, Block, or Transform.
  4. Optionally add conditions so the rule only runs for certain consumers, models, collectors, protocols, sessions, directions, or tools.
  5. Attach the policy to a collector.
Leave the policy in Observe until Activity shows the findings you expected. A detector that looked well-tuned in testing can be noisy on real traffic, and Observe is where you find that out without blocking anyone.