Content detection

CID222 exposes its detection engine directly, so you can scan any text for PII, secrets, toxicity and prompt injection without sending it to a model. The same engine runs on every chat request.

Detect content

POST /api/v1/guardrails/detect

Runs the full detection pipeline — PII, secrets, toxicity, jailbreak and injection — over a block of text and returns the entities found, the decided action, and a masked copy of the text.

This is the only surface on the gateway that carries an /api/v1 prefix. Every other endpoint sits at the root, for example /chat/completions and /models.

The endpoint returns 200, not 201. It accepts either a JWT or a gateway API key (Authorization: Bearer cid_key_<64 hex>). A request that arrives unauthenticated from loopback or an RFC1918 address is admitted with no tenant context, which is how the bundled red-team service reaches it; per-tenant filter overrides do not apply to those calls.

Request body

Unknown fields are stripped silently rather than rejected, because the gateway runs a global validation pipe with whitelist: true. A misspelled field name produces no error.

Example request

curl -X POST https://<appliance-fqdn>/api/v1/guardrails/detect \
  -H "Authorization: Bearer cid_key_0123456789abcdef" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "My name is John Smith and my email is john@example.com",
    "check_type": "prompt"
  }'

Response

The response reports the overall action, a count, the list of detected entities, and a masked copy of the input.

{
  "action": "mask",
  "detectionCount": 2,
  "maskedText": "My name is [PERSON_NAME] and my email is [EMAIL]",
  "detectedEntities": [
    {
      "type": "PERSON_NAME",
      "value": "[PERSON_NAME]",
      "action": "mask",
      "confidence": 0.95,
      "source": "ml",
      "filterName": "ML Detector (ONNX NER)",
      "start": 11,
      "end": 21
    },
    {
      "type": "EMAIL",
      "value": "[EMAIL]",
      "action": "mask",
      "confidence": 0.95,
      "source": "regex",
      "filterName": "Regex Detector",
      "start": 39,
      "end": 55
    }
  ],
  "processingTimeMs": 142,
  "normalization": { "applied": [], "originalText": "" }
}

normalization.applied lists the evasion decoders that ran on the input — rot13, base64, leetspeak, unicode, case — and is an empty array when none applied. normalization.originalText is always an empty string: the controller blanks it so the raw input is never echoed back.

Detected entity fields

source takes one of these values:

filterName reports the detector or the filter group, not the rule that fired. A regex detection reports Regex Detector and carries the seed rule's name internally; a toxicity detection reports the filter group, for example Content Safety (HAP Model - 13 Categories).

Detection actions

On the chat surface a rejection is not an HTTP error. The stream emits {"type":"content_rejected"} for a blocked prompt or {"type":"output_content_rejected"} for a blocked reply, then [DONE].

PII entity types

The seeded PII filter group covers 17 rules. The ONNX NER model emits 21 native labels; the regex layer adds Turkish formats and validators the model does not carry. Where both fire on the same span, the detections are merged.

Secret and credential detection

A separate DLP filter group covers secrets and credentials. Nine of its rules are regex-only.

Safety categories

Three detectors classify content beyond PII: a 13-label toxicity model, a 2-label attack model, and a deterministic injection scan.

The toxicity and attack models each cover eight languages: en, tr, de, fr, es, ar, it and nl. The injection scan is language-independent — it parses the string rather than classifying it — and a low attack-intent score from the attack model demotes its verdict from reject to flag.

Toxicity thresholds are per label, in three levels (block, flag, log-only), and ship tuned per label rather than at one global value. Attack-model thresholds are likewise per label and three levels. Both sets are baked into their service image and have no environment override, so changing them means rebuilding the image.

Confidence scores

Every detection carries a confidence between 0 and 1. Regex detections are fixed at 0.95, because a compiled pattern either matched or did not. Model detections carry the model's own score.

A detection is boosted by 0.1, clamped at 1.0, when a context keyword registered for its entity type appears within 50 characters of the span. The boost is context-keyword driven; it is not awarded for two detectors agreeing.

A validated entity passes only if its final confidence reaches 0.6. A detection that arrives with no confidence at all is assumed to be 0.8.

Query stored detections

GET /admin/detections and GET /admin/detections/stats read what the pipeline recorded. Both require the admin_user or auditor role and the detections.view capability, and both are scoped to the tenants the caller can already read.

curl -X GET "https://<appliance-fqdn>/admin/detections?entity_type=EMAIL&action_taken=masked" \
  -H "Authorization: Bearer <admin-jwt>"

The response is paginated:

{
  "data": [],
  "meta": { "total": 42, "page": 1, "limit": 10, "totalPages": 5 }
}

Related

• The content safety pipeline — what runs, in what order, and what decides the action.
• PII detection — entity coverage, validators and masking.
• Chat API — how a detection surfaces on the stream.