Skip to content
Arbitex Docs

RAG Context DLP

RAG Context DLP adds context source attribution to the standard DLP pipeline. When a caller submits an assembled prompt built from multiple sources — user input, retrieval chunks, tool responses — the platform tags each DLP finding with the segment it came from, so policy rules and audit records distinguish a violation typed by a user from one introduced by a retrieval system.

Configuration requires the Org Admin role.

How It Works

Section titled “How It Works”

The intake pipeline receives an optional context_sources list alongside the prompt. Each entry identifies a segment of the assembled prompt text: its type (user, retrieval, tool_output), its raw text, and an optional source_id that maps back to a registered retrieval source.

The DLP scan runs once across the full assembled prompt — all five tiers execute as normal. After scanning completes, the attribution step walks the character offset map of the prompt and stamps each detected entity with a context_source field matching the segment where the match fell. The distinct source types present in the request are collected as context_source_types and stored in the policy context for rule evaluation.

Caller submits assembled prompt
         │
         │  context_sources:
         │    [{type: "user",      text: "...", source_id: null},
         │     {type: "retrieval", text: "...", source_id: "kb-finance-001"},
         │     {type: "tool_output", text: "...", source_id: null}]
         │
         ▼
┌─────────────────────────────────────┐
│  Tier 1: Regex matching              │  runs on full assembled prompt
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│  Tier 2: NER (spaCy)                 │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│  Tier 3: DeBERTa NLI                 │
└──────────────────┬──────────────────┘
                   │
                   ▼
┌─────────────────────────────────────┐
│  _attribute_context_sources()        │
│  Build char-offset map → stamp each  │
│  entity with context_source field    │
└──────────────────┬──────────────────┘
                   │
                   ▼
         Policy engine evaluates
         (context_source condition available)
                   │
                   ▼
         Audit log written
         (context_sources + context_source_findings)

Configuration

Section titled “Configuration”

RAG Context DLP is active whenever context_sources is passed by the caller. There is no org-level toggle to enable or disable attribution — if the field is absent the pipeline behaves identically to a standard DLP scan with no attribution overhead.

Callers must be authenticated API keys with the dlp:write scope. The source_id values in context_sources entries should reference UUIDs from the retrieval source registry (see Retrieval Source Management below).

Context Source Types

Section titled “Context Source Types”
Type Description
user Text entered directly by the end user
retrieval Chunks fetched from a knowledge base or vector store
tool_output Structured or unstructured output returned by a tool call

These are the three recognized type strings. Any unrecognized type value is accepted but does not match predefined policy conditions — create a custom condition if additional types are required.

Policy Conditions

Section titled “Policy Conditions”

The policy engine exposes a context_source condition that filters rule evaluation based on where a violation was found. This lets you apply stricter actions to retrieval-introduced violations without blocking user input that triggers the same entity type.

Example policy rules:

# Block any PII that came in through a retrieval source
- name: block-retrieval-pii
  conditions:
    - field: entity_type
      operator: in
      value: [PERSON, EMAIL, SSN, CREDIT_CARD]
    - field: context_source
      operator: eq
      value: retrieval
  action: BLOCK


# Redact credentials from tool output, log for review
- name: redact-tool-credentials
  conditions:
    - field: entity_type
      operator: in
      value: [API_KEY, AWS_KEY, BEARER_TOKEN]
    - field: context_source
      operator: eq
      value: tool_output
  action: REDACT
  audit: true


# Warn on user-typed PII without blocking
- name: warn-user-pii
  conditions:
    - field: entity_type
      operator: in
      value: [PERSON, EMAIL]
    - field: context_source
      operator: eq
      value: user
  action: ALLOW
  audit: true

See the Policy Engine guide for the full condition syntax and available action types.

Retrieval Source Management

Section titled “Retrieval Source Management”

The retrieval source registry tracks the knowledge bases, vector stores, and external data sources your RAG pipelines draw from. Registering a source lets you correlate audit findings back to the originating system and apply anomaly detection.

List retrieval sources

Section titled “List retrieval sources”
Terminal window
curl -s https://api.arbitex.ai/api/v1/admin/retrieval-sources/ \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq .

Create a retrieval source

Section titled “Create a retrieval source”
Terminal window
curl -s -X POST https://api.arbitex.ai/api/v1/admin/retrieval-sources/ \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Finance Knowledge Base",
    "source_type": "knowledge_base",
    "access_level": "restricted",
    "description": "Internal financial procedures and policy documents"
  }' | jq .

Get a retrieval source by ID

Section titled “Get a retrieval source by ID”
Terminal window
curl -s https://api.arbitex.ai/api/v1/admin/retrieval-sources/{source_id} \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq .

Update a retrieval source

Section titled “Update a retrieval source”
Terminal window
curl -s -X PATCH https://api.arbitex.ai/api/v1/admin/retrieval-sources/{source_id} \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "access_level": "confidential",
    "description": "Upgraded sensitivity — contains M&A documents"
  }' | jq .

Delete a retrieval source

Section titled “Delete a retrieval source”
Terminal window
curl -s -X DELETE https://api.arbitex.ai/api/v1/admin/retrieval-sources/{source_id} \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Deleting a source does not purge historical audit records that reference its UUID. Past findings retain their source_id for forensic traceability.

Access Levels

Section titled “Access Levels”

Retrieval sources carry an access_level field that describes the sensitivity of the data they hold. The hierarchy from least to most sensitive is:

Level Use case
public Publicly available content (product documentation, marketing copy)
internal Internal company knowledge not classified above public (default)
restricted Regulated or sensitive data (HR records, customer PII, financial data)
confidential Highly sensitive (M&A, litigation hold, board materials)

Access level is informational metadata for policy authoring and reporting — the platform does not enforce access control on retrieval itself. Use it in policy conditions to apply tighter actions when findings originate from higher-sensitivity sources.

Anomaly Detection

Section titled “Anomaly Detection”

The attribution layer detects two anomaly conditions per request and includes them in the audit record:

Signal Condition Field
new_source A source_id appears for the first time in the organization anomalies
high_volume A single source contributes more than 50 attributed findings in one request anomalies

Both signals are logged as entries in the anomalies array on the audit event. They do not automatically trigger policy actions — add a policy rule referencing anomaly conditions if you want to block or alert on these events.

Audit Log Fields

Section titled “Audit Log Fields”

Context attribution adds the following fields to every audit log entry for requests that include context_sources.

{
  "event": "dlp.finding",
  "request_id": "req_01HZ9XKPQR3VBT7MN8C",
  "timestamp": "2026-04-01T14:32:08.441Z",
  "org_id": "org_finance_prod",
  "action": "BLOCK",
  "context_sources": [
    {"source_type": "user",      "source_id": null},
    {"source_type": "retrieval", "source_id": "kb-finance-001"},
    {"source_type": "tool_output", "source_id": null}
  ],
  "context_source_findings": {
    "user":        {"PERSON": 1, "EMAIL": 2},
    "retrieval":   {"SSN": 1, "CREDIT_CARD": 3},
    "tool_output": {}
  },
  "anomalies": ["new_source"],
  "entities": [
    {
      "entity_type": "SSN",
      "context_source": "retrieval",
      "source_id": "kb-finance-001",
      "confidence": 0.97,
      "offset_start": 412,
      "offset_end": 423,
      "redacted": true
    }
  ]
}

context_source_findings is a map of source type to entity-type count. Use this field in SIEM queries to build per-source violation trend dashboards without joining against the entity array. See the SIEM Integration guide for Splunk and Sentinel field mapping examples.

Limitations

Section titled “Limitations”

  • Single scan pass. Attribution does not run a separate DLP pass against each retrieval chunk in isolation. The scan runs once on the fully assembled prompt, and findings are attributed back to source segments using character offsets. A violation that spans a segment boundary is attributed to the segment containing its start offset.

  • Caller-supplied boundaries. Segment boundaries are derived from the text lengths in the context_sources list as supplied by the caller. If the caller assembles the prompt differently from what the text fields describe, attribution offsets will be incorrect.

  • No RAG isolation policy. If the same entity type appears in both a user segment and a retrieval segment, both findings are attributed and evaluated independently. There is no merged deduplication across sources.

  • source_id validation. The pipeline does not reject requests with unknown source_id values — it logs them and flags new_source as an anomaly. Strict enforcement of registered-only source IDs requires a policy rule.

Section titled “Related Pages”