Policy controls

A project’s runtime policy controls which classifiers run, how strict they are, and what recovery steps the gateway may take. Edit it on the policy screen or through the policy API.

Where policy lives#

Runtime classifier and guardrail settings are stored per project under detector_config.proxy_runtime. The custom blocklist is stored beside that config as custom_blocklist. The dashboard writes both for you; this page documents the shape so you understand what each control does.

Classifier thresholds#

Each blocking guard has an enabled toggle and two thresholds on a 0 to 1 scale. Flagged means a score at or above is flagged (observed risk). Unsafe means a score at or above returns an unsafe verdict. In Enforce, configured steering runs first; the gateway blocks if the effective verdict remains unsafe.

These are gateway defaults, not thresholds used by direct SDK or REST checks. Project threshold tuning is manual. The runtime does not fit new values from traffic. See Thresholds and calibration.

INT-CoT is different. It is off by default and uses a static source-model threshold returned by the classifier. Its sole project threshold is a fallbackflagged_threshold for older or incomplete classifier responses; there is no CoTunsafe_threshold. INT-CoT never blocks by itself; material, rising divergence can escalate an already-flagged tool or output result into the normal retry and block path.

How scores map to thresholds#

Each gateway guard compares a different result field with the project thresholds:

Policy controls#

Beyond the classifiers, the cascade offers configurable policy controls. See Steering for their request order, mode behavior, and endpoint boundaries.

• Global max attempts. Caps total provider calls per request (1 to 5, default 3).
• Custom blocklist. Up to 256 case-insensitive literal terms, each at most 256 characters, match at word boundaries in the latest user request. Enforce blocks a match before any provider call; Observe records the simulated block. Configured terms are not copied into trace attributes.
• Tool interception. Allow and block lists plus per-tool actions: allow, block, sanitize_args, or retry_without_tool, plus argument redaction.
• Tool-result quarantine. Screens inbound tool results. Can fail closed (see modes).
• Context splicing. Neutralizes trusted localized spans while preserving the genuine task, or quarantines an unsafe turn behind a safe continuation bridge when prior workflow context exists.
• Sampling constriction. Tightens explicitly supplied temperature, top-p, and token limits on elevated-risk turns. It does not inject missing temperature or top-p fields, preserving reasoning-model compatibility. A separate opt-in can impose the token cap when no limit was supplied.
• Model escalation. Routes a flagged attack class to a stricter model.
• Output gating and informed retry. Re-attempt generation with fresh constraints when the output guard trips.

Content mode#

The observability content mode controls how much request/response content is retained on traces:

See Security & data handling for the details.

Example policy#

{
  "detector_config": {
    "proxy_runtime": {
      "classifiers": {
        "input":  { "enabled": true, "flagged_threshold": 0.8, "unsafe_threshold": 0.9 },
        "tool":   { "enabled": true, "flagged_threshold": 0.4, "unsafe_threshold": 0.8 },
        "output": { "enabled": true, "flagged_threshold": 0.7, "unsafe_threshold": 0.9 },
        "cot_integrity": { "enabled": false, "flagged_threshold": 0.5 }
      },
      "guardrails": {
        "global_max_attempts": 3,
        "sampling_constriction": {
          "enabled": true,
          "temperature": 0.0,
          "top_p": 0.5,
          "max_tokens_cap": 1024,
          "enforce_max_tokens_when_absent": false
        }
      },
      "observability": { "content_mode": "metadata_only" }
    }
  },
  "custom_blocklist": ["ignore previous instructions", "reveal system prompt"]
}