Data Loss Prevention for Agentic AI Environments
This document describes Gentrice's multi-layer DLP architecture for agentic AI systems — covering detection mechanisms, rule categories, action policies, and compliance mapping. Intended for both technical evaluators and procurement compliance personnel.
Executive Summary
The autonomous execution capabilities of agentic AI systems create data exfiltration risks far exceeding those of traditional Q&A AI. Agents can invoke tools, read and write databases, and generate documents without human intervention — every step a potential exfiltration node. This document describes Gentrice's five-tier progressive DLP system, designed for on-premises and air-gapped deployment, validated in government and enterprise environments. It achieves comprehensive detection and action on PII, classified content, prompt injection, and sensitive output — with minimal latency impact.
Background: The DLP Challenge of Agentic AI
Traditional DLP systems were designed for static data flows — a user uploads a file, the system scans it, and decides whether to allow it. Agentic AI breaks this assumption: agents executing a task may make dozens of tool calls within milliseconds, each carrying different data types in and out.
Traditional AI Data Flow
- User → single request → LLM → single output
- Predictable data flow with clear boundaries
- Static rules cover most risks
Agentic AI Data Flow
- Goal → multi-step planning → tool call chain → multi-source data synthesis → output
- Every tool call is a potential data I/O node
- Attackers can hijack agent behavior via prompt injection
Agentic AI also faces attack vectors traditional systems never encountered — prompt injection lets malicious users control agent behavior through input content, context exfiltration can steal system prompts and API keys, and tool poisoning can make agents execute malicious tool responses. These threats require DLP not just at the entry point, but throughout the entire agent execution pipeline.
Five-Tier Progressive Detection Architecture
We follow a 'speed-first, precision-increasing' design principle — fast rules intercept clear threats in milliseconds, while slow but precise models activate only when necessary. This keeps the system operational at high throughput (e.g., concurrent multi-user government deployments).
System-level hard constraints that no request can bypass. Includes a keyword blacklist of absolutely prohibited patterns and invariant rules that block on format mismatch. Latency is negligible with zero UX impact.
Regex matching against known sensitive data formats: Taiwan national ID ([A-Z][12]\d{8}), unified business number (\d{8}), mobile numbers, credit card numbers, and more. Highest throughput for PII protection at scale.
For requests that deliberately rephrase or obfuscate to bypass regex, embedding models compute semantic similarity. Detects variants of 'ignore previous instructions' regardless of spelling or word order variations.
Cross-request behavioral analysis: a user issuing a high volume of sensitive data queries in a short window, request patterns deviating from normal baselines, or systematic probing of DLP boundaries — all flagged as anomalous.
For requests flagged as high-risk but not conclusive by earlier tiers, a local LLM (e.g. Gemma 4) acts as judge for deep semantic analysis. This tier offers the highest flexibility — techniques such as KV caching can improve response speed — but is still triggered only when necessary to preserve throughput.
Detection Categories & Rules
DLP rules are organized into four categories by data type and threat nature. Each rule specifies its detection tier, matching pattern, and recommended action.
Personally Identifiable Information (PII)
| Rule | Pattern | Tier |
|---|---|---|
| Taiwan National ID | [A-Z][12]\d{8} | Tier 2 |
| Unified Business Number | \d{8} | Tier 2 |
| Phone Numbers | 09\d{8} / 0[2-8]\d{7,8} | Tier 2 |
| Credit Card Number | \d{4}[- ]?\d{4}[- ]?\d{4}[- ]?\d{4} | Tier 2 |
| Email Address | [^\s@]+@[^\s@]+\.[^\s@]+ | Tier 2 |
Confidential & Access Control
| Rule | Pattern | Tier |
|---|---|---|
| Classified Document Keywords | 上下文語意 | Tier 2.5 |
| External Org Confidentiality | 上下文語意 | Tier 2.5 |
| Internal Credential Patterns | Regex + Tier 2.5 | Tier 2 / 2.5 |
Prompt Injection Attacks
| Rule | Pattern | Tier |
|---|---|---|
| Instruction override (ignore prev) | Regex + Embedding | Tier 2 / 2.5 |
| Jailbreak (DAN / JAILBREAK) | 黑名單 + Embedding | Tier 0–1 / 2.5 |
| Encoded attacks (Base64/ROT/Unicode) | 解碼後比對 | Tier 2 |
| Role-play bypass | LLM-as-Judge | Tier 4 |
Output Filtering
| Rule | Pattern | Tier |
|---|---|---|
| Auto-mask PII in LLM output | Regex post-output | Tier 2 |
| Block output containing classified content | 上下文語意 | Tier 2.5 |
| Credential detection in code output | Regex + Tier 2.5 | Tier 2 / 2.5 |
Detection Direction & Action Policy
DLP operates in two directions: input detection (pre-input) scans before the request reaches the LLM; output detection (post-output) filters after the LLM responds. Each rule independently specifies its direction and the action to take on trigger.
Fully reject the request without forwarding to the LLM. For high-certainty, severe-risk events such as confirmed ID number exfiltration or jailbreak attempts.
Allow the request to proceed but log the event and notify administrators in real time. For borderline cases requiring human review, such as semantically ambiguous confidential queries.
Preserve request or output structure but replace sensitive fields with placeholders (e.g. [MASKED-ID]). Users still receive partial responses while raw sensitive values are prevented from entering LLM context or external systems.
Route the request to an on-premises deployed model instead of a cloud model. For requests containing sensitive content that still requires processing — data stays within organizational boundaries while service availability is maintained.
Management Console
The following is an actual screenshot of the DLP management console, showing the event inbox (with trace IDs, detection tier, and action result), event trend charts, and protection rule configuration. Administrators can view all DLP events in real time and adjust rule settings through the interface.
Every event has a unique TRC-YYYYMMDD-XXXXXXXX trace code for audit queries
Events label the triggering tier (pre_input / post_output / semantic) for analysis
Event trend chart uses color to distinguish Block (red), Warn (orange), Mask (blue) for instant risk situational awareness
Compliance Mapping
This DLP architecture covers Taiwan's major information security regulations and international AI security standards. The following maps each regulation to relevant provisions and system coverage.
| Regulation / Standard | Scope | Article / Requirement | System Coverage |
|---|---|---|---|
| Personal Data Protection Act (PDPA) | Taiwan | Art. 27: Appropriate security measures to prevent PII leakage | Tier 2 PII detection, masking, audit logs |
| Cybersecurity Management Act | Taiwan Government Agencies | Art. 16: Access control and audit mechanisms required | RBAC, full audit trail, trace IDs |
| OWASP Agentic AI Top 10 | International Standard | 10/10 category coverage: Prompt Injection, Context Exfiltration, Tool Poisoning, etc. | Tier 0–4 full coverage, including Agent Threat Rules ruleset |
| Healthcare Data Security Regulations | Healthcare Providers | Medical records and diagnostic info must not be transmitted to unauthorized systems | Bidirectional input/output detection, redirect-to-local action |
Deployment Model
The DLP engine is deployed as a microservice, embedded in the LLM request routing middleware layer. All components run within the client's physical environment with no external network connections required.
LDAP / AD Integration
DLP events are bound to user identity; audit logs trace back to specific operators.
DLP Rule Assistant
Built-in AI-assisted rule authoring — administrators describe requirements in natural language; the system auto-generates regex or semantic rules.
Need a DLP Assessment for Your Environment?
Our engineering team can analyze your existing system data flows, assess DLP deployment scope, and provide customized rule recommendations.