LLM DLP
LLM DLP is data loss prevention applied at the prompt and completion layer of AI traffic. The control reads the decrypted prompt body, classifies the content (PII, PHI, source code, customer records, contract text, model-defined categories), and either blocks the request, redacts the sensitive fields, or routes the request to an approved destination. LLM DLP runs above the TLS termination point because network DLP cannot inspect prompt payloads that travel inside encrypted HTTPS to api.openai.com, api.anthropic.com, or any other LLM endpoint.
How LLM DLP differs from network DLP
Network DLP appliances inspect plaintext traffic on egress. LLM API calls travel over TLS to vendor endpoints, so the appliance sees a destination hostname and an opaque encrypted payload. The 77% of employees who paste sensitive business data into unsanctioned models (Cloud Radix, 2026) move that data through a channel the network DLP cannot read. LLM DLP terminates the TLS at the gateway, reads the prompt in cleartext, runs classification, and applies the policy before the request reaches the model.
What LLM DLP enforces
The control attaches to the AI gateway policy decision point. Per-route rules express the data classes a given LLM endpoint is allowed to receive. A request from a finance role to GPT-4 with customer SSN content gets blocked when the route policy says external models cannot receive PII. A request from a healthcare clinician to a HIPAA-covered Anthropic endpoint with PHI content passes when the BAA is in place and the route is approved. The IBM Cost of Data Breach Report found that shadow AI breaches exposed customer PII at 65%, versus 53% across all breaches. LLM DLP is the control that closes that gap when the AI traffic itself is sanctioned.
Related reading
- AI Inline Enforcement Architecture: Where the Policy Decision Sits and What It Has To Commit
AI inline enforcement runs the policy decision in the request path, before the model API call returns to the calling application. The architecture places a deterministic policy decision point between the application identity and the model endpoint and commits a per-decision audit record before the response forwards. This piece walks through the architectural components, the decision-time data shape, the failure modes the implementation has to handle, and the regulatory profile that the inline placement satisfies (EU AI Act Article 12, NIST AI agent identity and authorization Pillar 2 and Pillar 3, Fannie Mae LL-2026-04, DORA Article 6).