Skip to content
Arbitex Docs

About DLP

What it does

Section titled “What it does”

About DLP is a conceptual overview — it changes no configuration. It walks through the mental model behind every other panel in this group, top-down: the chain is an ordered list of policy packs, a pack is an ordered list of chain entries, and a chain entry is a detector applied with filters and an action. Each concept links to the panel where you actually author it.

Configure in the UI

Section titled “Configure in the UI”
The About DLP panel showing the composition diagram (detector to chain entry to policy pack to chain) above seven numbered concept cards, each with an out-link to its authoring panel.
Security & DLP → About DLPCitadel synthetic data on a non-production Arbitex demo instance. Never client data.

  1. Open Security & DLP → About DLP. The panel opens with a composition diagram showing how a detector becomes a chain entry, entries compose into a pack, and packs compose into the chain.

  2. Read “DLP is a configurable chain” — every request runs against an ordered list of policy packs plus a combining mode:

    • Most-restrictive (deny_overrides) — the safe default and maximum protection. Every applicable entry is evaluated and the strictest action wins (block beats redact beats log beats allow). This mode enforces end-to-end today.
    • First-match (first_applicable) — the deliberate exception mode. Evaluation stops at the first matching entry, so a specific rule authored earlier can override a broader one. This is the designed model for sanctioned carve-outs, but it is not yet live-enforced at request time — the panel badges it “enforcement coming.”

  3. Read “The chain is made of policy packs” — a pack’s lineage is Applied (an Arbitex compliance bundle, read-only and kept in sync), Cloned (a static, editable snapshot of a bundle), or Custom (authored by you). Arbitex-managed packs default to the top of the chain, but their position is reorderable.

  4. Read “Policy packs are ordered chain entries” and “Detectors are reusable match definitions” — a detector only defines what to match (regex, NER, or DeBERTa). It carries no action and no filters of its own; those are set only when the detector is applied to a pack as a chain entry, so the same detector can redact in one pack and block in another.

  5. Read the capstone, “Exceptions are scoped to request context” — the worked example of a narrow, sanctioned carve-out (for example, an internal HR model authorized to see personnel data that would normally be blocked everywhere else), and the guardrail against an unscoped allow.

  6. Follow any concept’s out-link (for example, Configure the chain or Policy Packs) to jump straight to the panel where that piece is authored.

API equivalent

Section titled “API equivalent”

This panel performs no reads or writes — it is a static, in-console explainer, not a form. There is no API equivalent for the panel itself; each concept links to the panel whose own API equivalent is documented on that page (Chain, Policy Packs, Detectors).

Plan & availability

Section titled “Plan & availability”

About DLP is available on every plan — it is documentation inside the console, not a gated capability.

Deployment notes

Section titled “Deployment notes”

No deployment differences. The panel’s content is identical whether your organization runs entirely on Arbitex Cloud or on a Hybrid Outpost — it describes the model, not a specific deployment’s data.

Section titled “Related”