How We Built a 3-Tier DLP Pipeline for AI Gateway Security
When an employee pastes a customer record into an AI prompt, the question is not whether the data will reach the model — it is whether anything between the user and the model is looking. Most enterprise security stacks were built for email, file transfers, and SaaS applications. AI traffic — outbound HTTPS to model endpoints — passes through these systems unexamined. The data leaves. Nobody knows.
This is the problem we set out to solve. Not with a single detection method, but with a pipeline of four distinct tiers that inspect every prompt and every response before they reach or return from an AI model. Each tier catches what the tier before it cannot. Together, they form a defense that is substantially harder to bypass than any single technique.
Why a Single Detection Method Fails
Start with the most common approach: regular expressions. Regex patterns are excellent at finding structured, predictable data — credit card numbers, Social Security numbers, phone numbers, email addresses. If the data has a fixed format, regex will find it reliably and fast.
But sensitive data is not always structured. A patient diagnosis described in natural language does not match a regex pattern. A financial analyst’s summary of material nonpublic information contains no account numbers — just context that makes it regulated. A research scientist pasting unpublished findings into an AI tool sends no identifiable markers, just prose that happens to be proprietary.
Regex alone misses these cases entirely. And any DLP system that relies solely on pattern matching creates a false sense of security — it catches the easy cases while the nuanced, high-risk cases pass through undetected.
Tier 1: Pattern Matching
The first tier runs 80+ patterns against every prompt and response through an optimized pattern matching engine. These patterns target structured sensitive data: credit card numbers with Luhn validation, Social Security numbers, bank routing numbers, API keys, authentication tokens, passport numbers, and other data types with predictable formats.
Pattern matching is fast. It runs in microseconds, and the full pattern set processes a typical prompt in well under a millisecond. This speed matters because it runs on every request — there is no sampling, no batching, no probabilistic skip. Every character of every prompt and every response is evaluated.
The patterns include checksum validators where applicable. A 16-digit number that fails Luhn validation is not a credit card. A 9-digit number in the wrong format is not an SSN. Checksum validation reduces false positives substantially, keeping the pipeline from flagging benign content that happens to contain long numbers.
What Tier 1 catches: structured PII, financial account numbers, credential strings, government identifiers. What it misses: entity names, medical narratives, contextual business data, anything expressed in natural language.
Tier 2: Named Entity Recognition
The second tier uses NER models to identify entities in unstructured text. Where regex looks for patterns, NER looks for meaning: person names, organization names, locations, medical terms, financial instruments, dates tied to specific individuals.
This tier processes text through trained models that understand linguistic structure. When a prompt contains “Alex Johnson was diagnosed with Type 2 diabetes at Regional Medical Center on March 3,” NER identifies the person name, the medical condition, the organization, and the date as entities — none of which would trigger a regex pattern.
NER runs on GPU infrastructure to maintain throughput. Inference latency adds processing time per request, but stays within the budget required for interactive AI usage. The models are optimized for the entity categories most relevant to enterprise sensitive data: medical entities, financial entities, personal identifiers, and organizational references.
What Tier 2 catches: named entities in natural language, medical narratives, person-organization-location relationships. What it misses: contextual sensitivity — text that is sensitive because of what it means, not because of the entities it contains.
Tier 3: Semantic Classification
The third tier addresses the hardest category: text that is sensitive because of its context, not its content. A sentence like “the acquisition target is valued at $2.1B and we expect to announce next quarter” contains no PII, no medical data, and no credential strings. But it is material nonpublic information — regulated under securities law and subject to strict handling requirements.
This tier runs a contextual validation model that evaluates text against sensitivity categories. The model has been trained to understand that certain combinations of business context, financial language, and temporal references indicate regulated content — even when no individual token would trigger a pattern or entity match.
Semantic classification adds the most latency of any tier, but it catches the cases that matter most: the ones where a human would immediately recognize the sensitivity, but a pattern matcher would see nothing.
What Tier 3 catches: contextually sensitive content, MNPI, strategic business data, regulatory-sensitive narratives. What it misses: credentials that are obfuscated or encoded.
Tier 4: Compromised Credential Detection
The fourth tier takes a different approach entirely. Instead of analyzing what the text says, it checks whether any token in the text matches a known compromised credential. This is not pattern matching and not entity recognition — it is a real-time lookup against a compromised credential dataset.
Lookups are sub-millisecond. When a prompt contains a string that matches a known compromised password, API key, or token, the system flags it — even if the credential does not match any pattern or entity category.
This tier exists because credentials leak into AI prompts more often than most organizations realize. Developers paste API keys into debugging prompts. Analysts include passwords in configuration questions. Support staff copy authentication tokens into troubleshooting requests. Tier 4 catches these cases regardless of format or context.
Why Layering Matters
Each tier addresses a specific category of sensitive data that the others cannot reliably detect. The value of the pipeline is not in any single tier — it is in the combination.
A prompt containing “Jordan Smith, DOB 04/15/1988, MRN 4829371, diagnosed with chronic kidney disease stage 3” triggers all four tiers differently: Tier 1 catches the MRN format, Tier 2 identifies the person name and medical condition, Tier 3 recognizes the clinical context, and Tier 4 checks any embedded tokens. Each tier adds detection confidence. Together, they produce a high-confidence classification with low false positive rates.
The pipeline runs sequentially: Tier 1 first (fastest), then Tier 2, then Tier 3, then Tier 4. If an early tier produces a high-confidence detection, enforcement can act immediately without waiting for slower tiers. This design keeps median latency low while ensuring that every request eventually passes through every tier.
Performance at Scale
A DLP pipeline that adds unacceptable latency to AI interactions will be bypassed — users will find ways around it. The pipeline is designed to keep total scan latency within acceptable bounds for interactive AI usage.
Tier 1 runs in microseconds. Tier 4 runs in sub-millisecond time. Tiers 2 and 3 are the latency-sensitive components, running on GPU infrastructure with inference times optimized for throughput. The total pipeline processes a typical enterprise prompt and returns a detection result within a window that is imperceptible to most users relative to model inference time.
Every request is inspected. There is no sampling mode, no bypass for “trusted” users, and no configuration option to skip tiers. The pipeline is always on, always in-path, and always complete.
From Detection to Enforcement
Detection without enforcement is monitoring, not protection. Each detection event feeds into the policy engine, which applies organization-specific rules: block the request, redact the sensitive content and forward the sanitized version, route to a human reviewer, or log and allow with a compliance flag.
Enforcement actions are configurable per compliance framework, per department, and per data category. A healthcare organization might block PHI entirely from reaching external models while allowing redacted summaries. A financial institution might route MNPI detections to compliance review while blocking credential exposures outright.
Every enforcement action — what was detected, which tier flagged it, what policy rule applied, what action was taken — is captured in the HMAC-chained audit log. This is the evidence trail that regulators, auditors, and incident responders need. It exists because the pipeline was designed for compliance from the start, not retrofitted after the first audit finding.
The Alternative
The alternative to a layered DLP pipeline is what most organizations have today: nothing between the user and the model. AI traffic flows outbound as HTTPS. Existing DLP tools, designed for email and file transfers, do not inspect it. Sensitive data reaches models that were never authorized to receive it. Nobody knows until an auditor asks or an incident surfaces.
Building a DLP pipeline purpose-built for AI traffic is not optional for regulated enterprises. It is the minimum infrastructure required to use AI models without creating compliance gaps that grow with every prompt submitted.
Related
- DLP Protection — Inspect every AI prompt and response for sensitive data
- DLP Pipeline — Multi-layer inspection engine: pattern matching, NER, and contextual validation
- DLP Accuracy — Measured detection precision across all entity types