Skip to main content

DLP for AI: Extending Data Loss Prevention to LLM Interactions

DLP for AI: Extending Data Loss Prevention to LLM Interactions

Traditional DLP programs were designed for email, endpoints, web uploads, and cloud storage. AI adds a different leakage path: prompts, retrieved context, tool arguments, and generated text that can all carry sensitive information through a conversational interface. Keeptrusts does not pretend that one detector solves all of this. Instead, it gives you an operator-defined DLP layer for custom secrets and codenames, a separate PII redaction layer for structured identifiers, and a way to test those controls before deployment.

Use this page when​

  • You need to extend an existing DLP program to LLM prompts and governed AI traffic.
  • You want to block custom secrets and internal terms that generic detectors will never know about.
  • You need DLP behavior that is testable before it reaches production.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Technical Leaders, AI Agents

The problem​

DLP for AI breaks if you treat AI prompts like email attachments.

The user is not always uploading a document. They may be pasting part of one, mixing it with instructions, and asking the model to summarize or transform it. The most sensitive values may be embedded inside otherwise normal requests. That means the control layer has to reason at the prompt boundary, not just at the file boundary.

There is also a coverage problem. Structured PII detectors are useful, but they do not know your internal codename, sealed case label, or proprietary project marker. At the same time, custom pattern rules alone are weak at common identifiers such as email addresses and payment-card data. AI DLP therefore needs more than one detector kind.

The last problem is trust. Security teams build DLP rules, deploy them once, and then discover weeks later that they block the wrong content or miss the real risk. AI changes quickly enough that untested rules become stale faster than teams expect.

The solution​

Keeptrusts already separates the two most important DLP questions.

DLP Filter is for the content your organization defines: API key regexes, codenames, sealed-case markers, internal hostnames, and literal blocked phrases. The docs are explicit that it does not ship with a giant built-in regulated-data catalog. That is a strength if you treat it honestly.

PII Detector is the shared redaction control for structured identifiers. It handles the common patterns and redaction behavior that you do not want to rebuild with custom regexes.

Conditional Chains Configuration lets you scope those controls to the routes or traffic classes that need them, and Testing Configuration lets you codify expected behavior before deployment.

Implementation​

This policy combines custom DLP, structured redaction, and inline tests in one deployable config.

pack:
  name: ai-dlp
  version: "1.0.0"
  enabled: true

policies:
  chain:
    - dlp-filter:
        stage: pre-request
        when:
          path: "/v1/chat/completions"
    - pii-detector:
        stage: pre-request
        parallel: true
        when:
          path: "/v1/chat/completions"
    - audit-logger

policy:
  dlp-filter:
    detect_patterns:
      - 'AKIA[0-9A-Z]{16}'
      - 'CASE-[0-9]{4}-SEALED-[0-9]{5}'
    blocked_terms:
      - Project Atlas
      - acquisition war room
      - export control annex
    action: block
    fuzzy_matching: true
    max_distance: 1
    sensitivity_level: restricted

  pii-detector:
    action: redact
    pci_mode: true
    redaction:
      marker_format: label
      include_metadata: true

  audit-logger: {}

testing:
  suites:
    - name: dlp-ai-suite
      target: dlp-filter
      cases:
        - name: blocks-codename-and-key
          input:
            messages:
              - role: user
                content: "Share Project Atlas notes and AKIA1234567890ABCDEF"
          expected:
            verdict: block
        - name: redacts-common-identifier
          input:
            messages:
              - role: user
                content: "Email jane@finneuron.com about invoice 42"
          expected:
            verdict: redact

This is a good AI DLP pattern because it does not overload one policy with two incompatible jobs.

dlp-filter decides whether organization-specific content should block. pii-detector decides whether structured identifiers should redact or block. The inline tests prove that both kinds of expectations survive configuration changes.

Run the tests before rollout:

kt policy lint --file policy-config.yaml
kt policy test --json

The testing step matters more in AI than in many older DLP programs because prompt traffic changes constantly. A new support workflow, new codename, or new document marker can make last quarter's rules incomplete. The right response is not to abandon DLP. It is to make DLP rules small, explicit, and easy to test.

You should also be clear about scope. dlp-filter is operator-defined. If your team never adds the internal terms and regexes that actually matter, the policy will not invent them for you. That is not a weakness in the product. It is the correct boundary between platform capability and organizational classification knowledge.

Results and impact​

AI DLP becomes much more effective when teams stop expecting one policy to do everything.

Custom secrets and codenames are blocked with deterministic rules. Common identifiers are redacted with the shared detector. Tests make policy updates safer because security teams can show the exact cases that should still fail or still pass after a change.

The result is a DLP program that fits AI traffic instead of fighting it.

Key takeaways​

Next steps​