How the Arbitex DLP Pipeline Detects Sensitive Data

Enterprise AI adoption creates a data protection problem that traditional DLP was never designed to solve. Employees paste sensitive information into AI prompts — customer records, financial data, credentials, healthcare identifiers — and conventional regex-based scanning either misses the data entirely or blocks so many legitimate requests that teams abandon the tool.

Arbitex Gateway takes a different approach. A multi-layer content inspection pipeline combines pattern matching, named entity recognition, and contextual validation, running at sub-2ms p99 latency in production. This post explains how each tier works and why the combination matters.

The problem with single-pass DLP

Most AI gateways scan prompts with a single regex pass. Match a pattern that looks like a credit card number or Social Security Number, flag it, move on.

This approach fails in two directions. False negatives let sensitive data through because regex cannot detect PII written in natural language — a name, an address, a medical record number described in prose rather than formatted as a structured field. False positives block legitimate work because many numeric sequences match credit card patterns without being credit cards.

Organizations lose trust in both directions. Security teams cannot rely on detection coverage, and employees learn to work around the system. The pipeline needs more than pattern matching.

Tier 1: Pattern rules with checksum validation

The first tier runs 80+ regex and structural pattern detectors against every request. These cover formats with well-defined structure: credit card numbers, IBANs, Social Security numbers, government IDs, API keys, database connection strings, and cloud provider secrets.

What separates this from basic regex is checksum validation. A Luhn check confirms a credit card number is structurally valid — not just a sequence of digits that happens to be 16 characters long. Checksum validators eliminate false positives on invoice numbers, order IDs, and arbitrary digit strings that pattern-only matching would flag.

Tier 1 is fast and deterministic. Low-ambiguity matches resolve here without needing more compute. High-ambiguity content — anything that does not match a known structural format — escalates to Tier 2.

Tier 2: Named entity recognition

The second tier runs GPU-accelerated named entity recognition (NER) with 40 recognizers to catch sensitive data in unstructured text. Names, addresses, medical record numbers, financial account identifiers, and other entities that appear in natural language rather than formatted fields.

NER handles the cases regex cannot reach. When someone writes “please summarize the notes for Jordan Smith, MRN 4821903, admitted last Tuesday,” there is no fixed format to match — but the NER layer identifies the patient name and medical record number from context.

Ambiguous or low-confidence NER detections escalate to Tier 3 rather than triggering enforcement directly. This prevents the false positive problem that plagues single-pass systems.

Tier 3: AI-powered contextual validation

The third tier is what makes the pipeline accurate. An AI-powered contextual validator evaluates each detection from Tiers 1 and 2 against its surrounding context using an optimized inference engine for production inference.

An account number in an expense report carries different risk than the same number in a healthcare discharge summary. A name mentioned in a meeting agenda is different from a name attached to a diagnosis. The contextual validator evaluates the semantic context around each detection to confirm or reject it, at sub-2ms p99 latency per validation.

This is not a secondary check that runs offline. Contextual validation executes inline, in the request path, adding negligible latency. Contextual validation executes at production speed without requiring requests to queue.

Why the combination matters

Each tier addresses what the others cannot. Tier 1 catches structured formats fast. Tier 2 catches unstructured entities that have no fixed format. Tier 3 resolves ambiguity so that enforcement actions — block, redact, or log — fire on confirmed detections rather than uncertain pattern matches.

The pipeline is additive, not redundant. Tier 1 resolves the structured identifiers it can validate outright. Tier 2 extends coverage to entities that only appear in free text and have no fixed format. Tier 3 then removes false positives the first two tiers cannot distinguish on their own — which is the difference between a DLP system that security teams trust and one they disable.

Policy engine integration

Detection alone is not enough. The pipeline feeds into a policy engine that maps detections to enforcement actions based on compliance framework requirements. PCI-DSS, HIPAA, GDPR, GLBA, SOX, CCPA, BSA/AML, SEC Reg FD, FERPA, EU AI Act, NIST AI RMF, ISO/IEC 42001 each have pre-built rule bundles that activate the correct detectors and enforcement actions for the data types each regulation covers.

When a detection fires, the policy engine determines the action: block the request before it reaches any model, redact the sensitive content and allow the rest through, or log the detection for audit purposes. Compliance framework rules are non-suppressible — no configuration error creates a regulatory gap.

Entity type coverage

The pipeline covers five broad entity categories across all three tiers:

• PII: Names, addresses, phone numbers, email addresses, dates of birth, government IDs
• PHI: Medical record numbers, diagnosis codes, treatment information, patient identifiers
• PCI: Credit card numbers, CVVs, bank account and routing numbers, IBANs
• Financial: Account numbers, transaction identifiers, tax IDs, financial statements
• Credentials: API keys, database connection strings, OAuth tokens, cloud provider secrets

Each entity type is measured independently for precision and recall. Aggregate accuracy scores that hide weak spots on specific entity types are not used — if one detector underperforms, it is visible in the per-entity metrics.

Air-gap deployment

For organizations that cannot send AI traffic through a cloud gateway, the full multi-layer pipeline deploys as an Outpost — a customer-managed data plane that runs the same detection stack in an air-gapped environment. Detection models, pattern rules, and policy configurations deploy locally. No prompt data leaves the customer’s network.

The Outpost runs the same AI-powered contextual validation model, the same NER recognizers, and the same pattern rules as the cloud pipeline. Accuracy metrics are identical regardless of deployment model.

Measured, not promised

A labeled test corpus covering supported entity types is maintained alongside the pipeline, and detection changes are evaluated against it per entity type rather than as a single blended score.

Detection quality is evaluated per entity type against a labeled, held-out corpus rather than reported as a single blended score. Arbitex does not currently publish per-entity accuracy figures — the evaluation corpus is not yet large enough for those numbers to be meaningful. When they are published, they will carry their corpus size and measurement date.

Related

• DLP Protection — Inspect every AI prompt and response for sensitive data
• DLP Pipeline — 3-tier inspection engine: regex, NER, and contextual validation
• Compliance Frameworks — Pre-built regulatory policy packs for every framework