Skip to content
Arbitex Docs

Smart Rule Builder

The Smart Rule Builder lets administrators create org-specific DLP rules without writing regex by hand. Describe what you want to detect in plain English, provide examples, and the platform generates a regex pattern automatically. When regex cannot capture the pattern, the builder recommends an AI detector rule that uses NLI or LLM classification at scan time.

Overview

Section titled “Overview”

Every organization inherits the platform’s default DLP rules (credit cards, SSNs, API keys, etc.). The Smart Rule Builder adds three capabilities on top of that baseline:

Rule Type Purpose Detection Engine
Custom Pattern Detect org-specific data with a regex pattern (hand-written or AI-generated) Regex (Tier 1)
Suppress Default Disable a platform default rule that produces false positives for your org N/A — removes the rule from evaluation
AI Detector Detect concepts that cannot be expressed as regex — described in natural language NLI (DeBERTa) or LLM (Haiku)

All org rules are scoped to the organization. They do not affect other tenants.

Prerequisites

Section titled “Prerequisites”
  • Admin role — all Smart Rule Builder endpoints require org-admin or platform-admin.
  • Anthropic provider configured — the AI-assisted regex generator calls Claude models. If no Anthropic provider is available, the generate-regex endpoint returns HTTP 503.
  • DeBERTa validator running — AI detector rules with the nli engine require the DeBERTa validator service at http://deberta-validator:8201/validate.

Creating Rules

Section titled “Creating Rules”

AI-Assisted Regex Generation

Section titled “AI-Assisted Regex Generation”

The fastest path to a custom pattern rule:

  1. Describe what you want to detect in natural language (up to 2,000 characters).
  2. Provide examples — at least one string that should match and one that should not.
  3. Submit the request to the generate-regex endpoint.

The platform runs a three-tier LLM escalation chain:

Tier Model When Used
1 Claude Haiku First attempt — fast and cheap
2 Claude Sonnet If Haiku’s regex fails any example
3 Claude Opus If Sonnet’s regex also fails

Each generated regex is mechanically tested against every example using Python’s re module. If all examples pass, the endpoint returns the regex and which model produced it. If all three models fail, the response recommends creating an AI detector rule instead.

Response fields:

Field Description
candidate_regex The generated regex pattern, or null if all models failed
model_used Which escalation tier succeeded: haiku, sonnet, opus, or null
pass_rate Fraction of examples the best candidate passed (0.0–1.0)
recommendation regex if a pattern was found, ai_detector if not

After receiving a successful regex, create a custom_pattern rule with that pattern. The auto_regex_candidate and auto_regex_model fields on the rule store which model generated the pattern, for audit purposes.

Custom Pattern Rules

Section titled “Custom Pattern Rules”

Custom pattern rules run in the regex tier (Tier 1) of the DLP pipeline — they are evaluated on every request and response with sub-millisecond overhead.

Required fields:

  • name — a human-readable label (max 255 characters).
  • pattern — a valid Python regex. The platform validates the pattern on creation; invalid regex is rejected.
  • action_tier — what to do when the pattern matches.

Optional fields:

  • custom_entity_type — a label for matches (e.g., internal_project_code). Defaults to org_custom_pattern if not set.
  • auto_regex_candidate / auto_regex_model — set automatically if the pattern came from the AI generator.

Suppress Default Rules

Section titled “Suppress Default Rules”

If a platform default rule produces false positives for your organization, you can suppress it:

  • Set rule_type to suppress_default.
  • Set target_rule_id to the name or ID of the platform rule to suppress.

The suppressed rule is excluded from your org’s effective rule set. Other orgs are unaffected.

AI Detector Rules

Section titled “AI Detector Rules”

For patterns that regex cannot express — internal jargon, domain-specific concepts, contextual sensitivity — use an AI detector rule.

Required fields:

  • ai_description — a natural language description of what to detect (e.g., “References to Project Aurora internal milestones or codenames”).
  • ai_engine — the classification engine:
    • nli — DeBERTa NLI validator. Faster, lower cost, runs locally. Uses the first 500 characters of the content as the premise. Match threshold controlled by the AI_DETECTOR_NLI_THRESHOLD environment variable (default: 0.7).
    • llm — Claude Haiku few-shot classifier. More flexible, handles nuanced descriptions. Evaluates up to 2,000 characters. Match threshold: confidence >= 0.5.

Optional fields:

  • ai_examples_positive — example strings that should match (improves accuracy for both engines).
  • ai_examples_negative — example strings that should not match.

In the DLP pipeline, AI detector matches appear with a detector name of org_ai_nli:{rule_name}:{action_tier} or org_ai_llm:{rule_name}:{action_tier}.

Action Tiers

Section titled “Action Tiers”

Every rule specifies an action tier that determines what happens when the pattern matches:

Action Tier Behavior
log_only Record the match in the audit log; pass the request through unchanged
redact Replace matched text with redaction markers before forwarding
prompt Pause the request for human-in-the-loop review
block Reject the request or response with HTTP 400

When multiple rules match the same content, the highest-severity action wins: block > redact > prompt > log_only. Default action tier is log_only.

Testing Rules

Section titled “Testing Rules”

After creating a rule, test it against sample text before relying on it in production:

  1. Send a POST request to the rule’s test endpoint with sample_text (up to 10,000 characters).
  2. The platform evaluates the rule using the appropriate engine (regex, NLI, or LLM).
  3. The response includes every match: the matched text, character offsets (start, end), and a confidence score.

For regex rules, confidence is always 1.0 (exact match). For AI detector rules, confidence reflects the engine’s certainty.

Viewing Effective Rules

Section titled “Viewing Effective Rules”

The effective rules endpoint merges your org’s custom rules with the platform defaults, showing exactly what the DLP pipeline evaluates for your organization:

  • Platform default rules that are active (not suppressed).
  • Platform default rules that are suppressed, with the ID of the org rule doing the suppressing.
  • Your org’s custom pattern and AI detector rules.

This is the authoritative view of what runs in your DLP pipeline.

Scan Level Configuration

Section titled “Scan Level Configuration”

Administrators can adjust the DLP scan depth for their organization:

Scan Level Behavior
full All five tiers: TF-IDF, regex, NER, DeBERTa, and CredInt (default)
regex_only Tier 1 only — fastest, lowest resource usage
off Skip DLP scanning entirely

Scan level is stored per-org and applies to all requests routed through that organization.

Rule Caching

Section titled “Rule Caching”

Org rules are cached in-memory for 60 seconds per organization. After creating, updating, or deleting a rule, the cache is invalidated immediately for that org. Other orgs’ caches are unaffected.

Audit Trail

Section titled “Audit Trail”

Every rule mutation is recorded in a dedicated audit table:

Action Trigger
created New rule created
updated Rule fields modified
enabled Rule re-enabled after being disabled
disabled Rule disabled
deleted Rule soft-deleted

Each audit record captures the actor, old values, and new values. Deleted rules are soft-deleted (retained in the database with a deleted_at timestamp) and excluded from active rule evaluation.

Best Practices

Section titled “Best Practices”

  1. Start with the AI generator. Describe your pattern in natural language and let the escalation chain find a regex. Only fall back to hand-written regex or AI detectors when the generator recommends it.

  2. Provide diverse examples. The generator tests every candidate regex against your examples mechanically. More examples (especially edge cases) produce better patterns.

  3. Use log_only first. Deploy new rules in log_only mode, monitor the audit log for false positives, then escalate to redact or block once you are confident.

  4. Prefer NLI over LLM for AI detectors. The NLI engine runs locally on DeBERTa with no external API calls. Use the LLM engine only when NLI cannot capture the concept.

  5. Review effective rules periodically. Platform defaults may change across upgrades. Use the effective rules view to confirm your org’s active rule set after each platform update.

  6. Test before enforcing. Always use the test endpoint with representative sample text before switching a rule from log_only to block.

Section titled “Related”