DLP Redaction Visibility

DLP Redaction Visibility

Arbitex enforces Data Loss Prevention (DLP) policies at every stage of the AI pipeline. When a policy modifies your prompt or blocks a response, the interface surfaces clear visual indicators so you always know what happened to your content.

This guide explains each indicator, when it appears, and what it means.

---

The 3-Tier DLP Pipeline

Arbitex runs content through three enforcement stages before and after a model responds:

Stage	When	What it does
Stage 1 — Streaming regex	During output streaming	Fast pattern matching; redacts common PII/PHI formats in real-time
Stage 2a — Input redaction	Before the LLM call	Full NER scan on user input; substitutes detected entities with [REDACTED] tokens
Stage 2b — Output finalization	After stream ends	Full NER scan on complete output; emits output_blocked if policy threshold exceeded
Stage 3 — Post-stream audit	After output_blocked or stream end	Catches entities that streaming regex missed; emits dlp_correction events

Each stage can produce a different visual indicator. All indicators are delivered over the Server-Sent Events (SSE) stream.

---

Input Redaction — input_redacted Banner

When it appears: Your prompt contained PII or PHI that was redacted by Stage 2a before being sent to the AI model.

Banner: “Your message was modified by security policy — 2 items redacted” — appears above the message bubble with entity type pills for each detected type (e.g., SSN, credit_card).

The banner appears above your message bubble and shows:

• The number of items redacted
• The entity types detected (e.g., ssn, credit_card, email)
• The policy name that triggered enforcement (e.g., pii-strict)

What was sent to the model: The message bubble below the banner shows your message as it was actually sent — with [REDACTED] tokens substituted where your original content was removed. This is what the AI model received.

Why this matters: You can confirm what the AI model “saw.” If a [REDACTED] token appears in an unexpected location, it may indicate that the policy matched content you did not intend to protect.

Example SSE chunk (backend)

{
  "type": "input_redacted",
  "original_length": 245,
  "redacted_count": 2,
  "entities": [
    { "entity_type": "ssn", "action": "redact", "confidence": 0.95 },
    { "entity_type": "credit_card", "action": "redact", "confidence": 0.99 }
  ],
  "policy_name": "pii-strict"
}

This chunk is emitted from _stage2_payload_analysis() in the intake pipeline before the LLM stream begins.

---

Output Blocking — output_blocked Banner

When it appears: The AI model’s response was blocked by a DLP policy. The model may have returned content that matched a high-confidence policy rule, or the response triggered a block threshold.

Banner: “DLP ENFORCEMENT — Request blocked — pii-strict” — shield icon, dark amber background, appears in the assistant message bubble position.

The blocked banner shows:

• “DLP ENFORCEMENT” header with a shield icon
• The policy name that triggered the block (e.g., pii-strict, hipaa-strict)
• A blocked explanation: what category of content was detected and why it was blocked

What you see instead of the response: The assistant message bubble shows the blocked explanation text — not an empty bubble. The AI model’s original response is not displayed.

Example: HIPAA enforcement

[CONTEXT ALERT: DLP enforcement — PHI/HIPAA protected data detected]

Detected: 6 PHI entities — DOB, MRN, ICD-10 codes, medication dosages.
All entities redacted per HIPAA compliance profile.

Request blocked — contains protected health information matching
compliance profile 'hipaa-strict'. Contact compliance officer
for authorized access.

Example SSE chunk (backend)

{
  "type": "output_blocked",
  "policy_name": "hipaa-strict",
  "blocked_explanation": "Response contains PHI entities exceeding policy threshold."
}

This chunk is emitted from finalize_pipeline() in chat.py.

---

[REDACTED] Tokens in Message Content

When DLP redacts an entity from a message, the literal text is replaced with a styled inline pill rather than raw text:

Inline pill: lock icon + amber/red background + text “REDACTED — PII/SSN detected”. Appears inline within message content where the original entity was removed.

Token formats

Format	Example	Display
Basic redaction	[REDACTED]	Amber pill with lock icon
Reason included	[REDACTED — PII/SSN detected]	Pill with tooltip showing reason

Hovering over a [REDACTED — reason] pill shows a tooltip with the specific reason. Pills use the active brand theme’s status-error color tokens — they adapt automatically if your organization uses a custom brand theme.

Persistence: [REDACTED] tokens in message content are persisted in the database. If you reload the page, the tokens remain in the message. What does not survive page reload is the DLP metadata (entity counts, policy name, banner state) — that is SSE-transient.

---

Post-Stream Correction — dlp_correction Banner

When it appears: After the AI response finished streaming, the full post-stream scan (Stage 3) found additional entities that the real-time streaming regex missed. The response content was corrected in place.

Banner: “Content modified by security policy — 1 additional entity redacted” — appears above the assistant message after post-stream correction.

The banner appears above the assistant message and shows:

• “Content modified by security policy”
• The count of additionally redacted entities
• Entity type summary

This is a normal part of the 3-tier pipeline. Streaming redaction prioritizes speed; the post-stream scan applies full NER for completeness. Users see the corrected content with [REDACTED] pills in place.

Example SSE chunk (backend)

{
  "type": "dlp_correction",
  "redaction": {
    "entity_count": 1,
    "entity_types": ["email_address"]
  }
}

---

DLP in Compare and Summarize Modes

All three chat modes — Single, Compare, and Summarize — handle DLP SSE chunks identically. Each model stream in Compare mode is independently checked. In Summarize mode, both the source model responses and the synthesizer output are subject to DLP enforcement.

---

SSE-Transient vs. Persisted Data

Data	Persisted?	Survives reload?
[REDACTED] tokens in message content	Yes — stored in messages.content	Yes
Entity counts and types	No — SSE only	No
Policy name	No — SSE only	No
Banner state (input_redacted / output_blocked / dlp_correction)	No — SSE only	No

If you need DLP event history (entity types, policy triggers, timestamps), your administrator can access the full audit log via the Admin Dashboard or the SIEM API.

---

Screenshot Placeholders

Placeholder	Description
_placeholder_dlp_input_banner.png	Input redaction banner above user message bubble
_placeholder_dlp_blocked.png	Output blocked banner with shield icon and dark amber styling
_placeholder_redacted_pill.png	Inline [REDACTED] pill with lock icon
_placeholder_dlp_correction.png	Post-stream correction banner above assistant message

---

Related Documentation

• DLP Pipeline Architecture — technical reference for the 3-tier pipeline
• Admin: DLP Rules — configuring DLP policies
• Outpost Deployment — DLP enforcement in on-premises deployments