DLP rule testing — admin workflow

Before deploying DLP rule changes to production, use the two built-in testing tools to validate that your rules behave as expected across representative input samples and organizational contexts.

• Test panel — validates a single rule’s pattern against sample text in the DLP rule editor. Use it during rule authoring to iterate quickly on patterns.
• Evaluate endpoint — simulates the complete DLP rule chain for a specific org/group context. Use it to validate full rule stack behavior and produce evidence for compliance reviews.

This guide focuses on the admin workflow for compliance validation. For the underlying API reference, see DLP pipeline testing guide.

---

Test panel — rule authoring workflow

The test panel is embedded in the DLP rule editor. It evaluates the rule’s current configuration (pattern, detector type, action tier) against sample text you provide, without saving the rule.

Workflow: authoring a new regex rule

1. Navigate to Admin > DLP Rules > New Rule.
2. Set Detector type to regex, enter your pattern (e.g., \b\d{3}-\d{2}-\d{4}\b for SSNs), set Entity type and Action tier.
3. Scroll to Test Rule at the bottom of the form and click to expand the panel.
4. Paste representative sample text in the Sample Text field. Include both matching content (expected to match) and non-matching content (expected to pass through cleanly).
5. Click Run Test.
6. Review the results:
   • Match count badge — amber if matches found, green if clean.
   • Entity type chips — entity types detected.
   • Action badge — the action that would fire (block / redact / log_only / prompt), color-coded by severity.
   • Highlighted text — matched regions highlighted in action-tier color.
7. Adjust the pattern and re-run until matches are correct. Then save the rule.

Checking for false positives

A rule that matches too broadly will produce unnecessary blocks or redactions. Test against content you do not want to match:

• Generic numeric strings (e.g., phone numbers, postal codes) if your pattern targets SSNs
• Product IDs or reference numbers that share structural similarity with PII patterns
• Content from the user groups that will be affected most heavily by this rule

The goal is a clean run (0 matches) against non-PII content and accurate matches against PII content.

Detector type behavior summary

Detector type	Pattern field	What it tests
regex	Regular expression	Pattern matching against the sample text
ner	Entity type label (e.g., PERSON, ORG)	NER model entity detection
llm / gliner	Entity type label	GLiNER contextual entity detection

The test panel maps frontend detector types to backend rule types automatically (llm → gliner).

---

Evaluate endpoint — full rule chain validation

The evaluate endpoint runs the complete DLP rule chain for an org context and returns a decision trace. Use this to:

• Validate that rule priorities are correct (the right action wins)
• Confirm that org-level rule suppressions work as intended
• Produce evidence of rule coverage for compliance reviews
• Test how changes to a group context affect the outcome

Endpoint

POST /api/admin/dlp-rules/evaluate
Authorization: Bearer $ADMIN_TOKEN
Content-Type: application/json

Request

{
  "text": "Please process payment card 4532-0151-1234-5678 for account holder Jane Doe (SSN 123-45-6789).",
  "org_id": "org_01abc123",
  "group_id": "grp_01finance",
  "user_id": null
}

Field	Required	Description
text	Yes	Text to evaluate (max 50,000 characters)
org_id	Yes	Organization UUID — determines which rules and suppressions apply
group_id	No	Group UUID — applies group-level rule overrides when set
user_id	No	User UUID — reserved for future user-level overrides

Response

{
  "text_length": 92,
  "org_id": "org_01abc123",
  "rules_evaluated": 18,
  "rules_matched": 2,
  "final_action": "block",
  "matched_rules": [
    {
      "rule_id": "rule_01cc2d3e",
      "rule_name": "credit-card-pci",
      "detector_type": "regex",
      "entity_type": "credit_card",
      "action_tier": "block",
      "match_count": 1,
      "matches": [
        { "start": 28, "end": 47, "matched_text": "4532-0151-1234-5678", "entity_type": "credit_card" }
      ],
      "source": "platform"
    },
    {
      "rule_id": "rule_01dd4e5f",
      "rule_name": "ssn-pii-block",
      "detector_type": "regex",
      "entity_type": "ssn",
      "action_tier": "block",
      "match_count": 1,
      "matches": [
        { "start": 79, "end": 90, "matched_text": "123-45-6789", "entity_type": "ssn" }
      ],
      "source": "platform"
    }
  ],
  "suppressed_rule_ids": [],
  "custom_org_patterns": 0,
  "decision_trace": [
    "Loaded 18 active platform rules for org org_01abc123",
    "Loaded 0 suppressed rule IDs",
    "Filtered 0 suppressed platform rules",
    "Platform rule evaluation complete: 18 evaluated, 2 matched",
    "Org custom pattern evaluation complete: 0 evaluated",
    "Final action determined: block"
  ]
}

Interpreting the response

final_action — the highest-priority action across all matched rules. The action hierarchy is:

block > redact > prompt > log_only > none

If one rule matches with block and another with redact, the final action is block.

matched_rules — each rule that produced at least one match, including:

• rule_id — use this to navigate to the rule in the admin UI
• source — platform (built-in platform rules), org_custom (org-added patterns), or org_suppress (suppressed by the org)
• action_tier — the action this individual rule contributes

suppressed_rule_ids — platform rule IDs that were excluded because the org has configured a suppression for them.

decision_trace — ordered evaluation log showing each step. This is the primary artifact for compliance review.

---

Compliance validation test scenarios

Use the evaluate endpoint to build a test matrix that demonstrates rule coverage for your compliance framework. Run these tests after any rule configuration change and before promoting to production.

PCI DSS test scenarios

Validate that payment card data is blocked in all required contexts:

# Test 1: Visa card number triggers block
curl -s -X POST https://api.arbitex.ai/api/admin/dlp-rules/evaluate \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Card number 4532015112345678 expiry 12/28 CVV 123",
    "org_id": "'$ORG_ID'"
  }' | jq '{final_action, rules_matched}'
# Expected: { "final_action": "block", "rules_matched": 1 }

# Test 2: Non-PCI text passes cleanly
curl -s -X POST https://api.arbitex.ai/api/admin/dlp-rules/evaluate \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Please summarize Q3 earnings from the annual report.",
    "org_id": "'$ORG_ID'"
  }' | jq '{final_action, rules_matched}'
# Expected: { "final_action": "none", "rules_matched": 0 }

HIPAA test scenarios

Validate that protected health information is identified:

# Test: PHI content triggers redact or block
curl -s -X POST https://api.arbitex.ai/api/admin/dlp-rules/evaluate \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Patient Jane Doe DOB 1985-04-12 diagnosis: Type 2 diabetes MRN 00123456",
    "org_id": "'$ORG_ID'"
  }' | jq '{final_action, "matched": [.matched_rules[].rule_name]}'

Group-scoped testing

Validate that group-level rule overrides apply correctly. Some groups may have stricter or more permissive rules:

# Test finance group — should trigger ALLOW_WITH_OVERRIDE for card numbers
curl -s -X POST https://api.arbitex.ai/api/admin/dlp-rules/evaluate \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Test card 4532015112345678 (synthetic QA data)",
    "org_id": "'$ORG_ID'",
    "group_id": "'$FINANCE_GROUP_ID'"
  }' | jq .final_action
# Expected: "prompt" (if finance group has ALLOW_WITH_OVERRIDE rule)

Suppression validation

Confirm that org-level rule suppressions don’t unintentionally widen coverage:

curl -s -X POST https://api.arbitex.ai/api/admin/dlp-rules/evaluate \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "NPI 1234567890 provider John Smith",
    "org_id": "'$ORG_ID'"
  }' | jq '{final_action, suppressed_rule_ids}'

If suppressed_rule_ids is non-empty, verify that the suppressed rules were intentionally suppressed and that sufficient alternative coverage exists.

---

Producing compliance evidence

The evaluate endpoint response is suitable as compliance evidence that DLP rules are configured to detect specific data types. To produce a test evidence package:

1. Define a test case matrix (input text, expected final_action, expected rules_matched).
2. Run each test case and capture the full response JSON.
3. Store the responses alongside the rule configuration export (see Config backup and restore).
4. Include the decision_trace array in your evidence — it provides an auditable chain showing which rules evaluated and in what order.

For SOX: demonstrate that rules covering financial data types (credit_card, bank_account, iban) produce block or redact actions in the production org context.

For GLBA: demonstrate that customer financial information patterns are covered and that override actions (ALLOW_WITH_OVERRIDE) produce audit log entries (test the override flow end-to-end; see ALLOW_WITH_OVERRIDE governance).

---

See also

• DLP pipeline testing guide — technical reference for the test panel and evaluate endpoint API
• DLP overview — understanding DLP rules, detector types, and action tiers
• ALLOW_WITH_OVERRIDE governance — testing override workflows end-to-end
• Config backup and restore — exporting the rule configuration as test environment documentation
• Compliance frameworks — framework-specific requirements for DLP coverage evidence