Data loss prevention (DLP)

The DLP layer is a configurable workflow gate. It runs whenever a workflow wants to validate input or output content against a defined policy — organization-owned PII detection, hallucination scoring, JSON validation, or regex match.

This page documents the Guardrails block and the four validation types it supports.

When to use it

Typical placements:

• Input gate — scan a user message for PII before it reaches an LLM.
• Output gate — scan an LLM response for PII before returning it to the user.
• Hallucination gate — score an answer against a knowledge base before exposing it.
• Format gate — assert that an LLM produced valid JSON / matches a regex before piping it downstream.

The Guardrails block is part of the scrydon:guardrails product — see Vendors → Scrydon.

Four validation types

PII detection

The governed Guardrails PII operation uses the rule set maintained by organization administrators under Settings → Governance → DLP. A workflow cannot choose a separate entity list, detector method, or enforcement action. This keeps capability scanning and workflow validation on one policy.

When a rule matches, the Guardrails validation fails and the workflow follows its failure branch. The result contains rule metadata and character spans for routing and diagnostics, but never the matched raw text:

{
  "passed": false,
  "evaluated": true,
  "validationType": "pii",
  "policyMode": "enforce",
  "findings": [
    {
      "ruleId": "email-address",
      "entityType": "EMAIL",
      "detector": "builtin",
      "confidence": "HIGH",
      "channel": "tool_call",
      "start": 8,
      "end": 21
    }
  ]
}

The policy must be available and enabled for the tool_call channel. Direct execution outside Scrydon's governed host is refused because it cannot load the trusted organization policy.

Hallucination detection

Validates an LLM output against a knowledge base using RAG plus LLM scoring:

Confidence scale:

Example output

{
  "passed": false,
  "score": 2,
  "reasoning": "The claim about Q4 revenue is not mentioned in any knowledge base document",
  "error": "Low confidence: score 2/10 is below threshold 3"
}

Configuration

The Guardrails block exposes these fields in the workflow editor:

PII rule selection, detector configuration, and policy mode are organization settings, not Guardrails block inputs.

The underlying Guardrails integration also exposes the hallucination-check tool with model and knowledge-base parameters. It is not currently listed in the workflow block's validation-type dropdown.

Pairing with the Evaluator block

The Guardrails block is fail-closed — if it fails, the workflow takes the failure branch. The Evaluator block is scoring — it returns a score the workflow can branch on however it wants. Use Guardrails for hard gates, Evaluator for quality checks that drive retries or fallback paths.

How we benchmark the platform DLP engine

Beyond the Guardrails block, Scrydon runs the organization DLP policy on covered platform capability calls (including LLM completions, transcription, and embeddings). Governed tool execution separately applies trusted endpoint classification and blocks no-write-down violations when classification mode is Enforce. Detection-quality claims are easy to make and hard to verify, so we measure the shared engine the same way we measure retrieval quality: against a public, third-party benchmark, with the harness in CI as a release gate — a release that regresses below the floors does not ship.

Measured on a 2,661-prompt English slice of ai4privacy/pii-masking-300k (pinned dataset revision, evaluated at build time — the dataset itself is never redistributed) plus an in-repo clearance-escalation bank:

Per graded entity type: email 99.6%, IP address 99.5%, phone number 86.1% recall.

What we don't claim. The report carries a mandatory out-of-scope section listing detection categories the engine does not cover, with measured evidence rather than silence: free-text person names (NER territory — the regex heuristic measured 14% recall, so we do not grade it), free-form date-of-birth formats (3% — the engine claims ISO 8601 only), and format-generic national identifiers (27% — the engine claims specific jurisdictional formats such as US_SSN or BE_NRN, not arbitrary digit runs). Each is documented in the signed report artifact so auditors see the boundary, not a marketing number.

Organization DLP policy and blocked LLM calls

The Guardrails workflow operation and platform LLM calls use the same organization DLP policy (Settings → Governance → DLP). When that policy is in Enforce mode and an LLM input scan produces a finding — a PII/secret pattern match or a prompt-injection classification — the call is blocked before anything reaches the model vendor:

HTTP 422 Unprocessable Entity

{
  "error": "llm_blocked_by_dlp",
  "detail": "Your input contained content that could not be processed.",
  "dlpReason": "input_blocked"
}

• detail is the admin-configured Blocked input message from the DLP policy editor.
• dlpReason distinguishes an input block (input_blocked) from a fail-closed classifier or policy-load denial (classifier_unavailable, policy_not_loaded).
• Workflow agent steps fail with Blocked by DLP policy: <message>; SDK and API callers receive the typed policy denial on unary and streaming Base Platform operations.
• A 422 means the block is deterministic — retrying the same input re-blocks. Review the matching rule under Settings → Governance → DLP → Hits or adjust the policy mode.

The semantic prompt-injection classifier is enabled when an organization has not explicitly opted out. Under Advanced Settings, administrators can also configure the canonical pre-action policy: an external destination allow/deny list and maximum data-classification ranks per tool category.

Related

• Architecture → Cortex — where Cortex can apply guardrails on every LLM call as a workflow-independent layer.
• Knowledge base clearance — clearance is a separate axis from DLP, not a replacement.
• Compliance — how DLP maps to framework controls (GDPR, EU AI Act, ISO 42001).