Data loss prevention (DLP)
Data loss prevention (DLP) is the control category that inspects data in motion or at rest, classifies it against a sensitivity taxonomy (PII, PHI, source code, financial records, regulated content), and applies an outcome (block, quarantine, redact, alert). Traditional DLP operates at the network gateway, the email gateway, the endpoint, and the cloud storage layer. DLP for AI operates at the prompt and completion layer, since LLM API traffic travels over TLS to vendor endpoints that network DLP cannot inspect.
Where traditional DLP loses visibility on AI traffic
A network DLP appliance reads plaintext SMTP, plaintext HTTP, and decrypted HTTPS where the corporate proxy holds the TLS keys. A call to api.openai.com from a browser plugin or a desktop client terminates TLS at OpenAI, not at the corporate proxy. The 77% of employees who paste sensitive business data into unsanctioned models (Cloud Radix, 2026) push that data through a channel the appliance reads as an opaque outbound HTTPS session. The DLP control catches none of the content because it has none of the content in cleartext.
What DLP looks like at the AI layer
An AI-layer DLP control sits at the AI gateway, terminates the caller TLS, reads the prompt body in cleartext, classifies the payload, and applies the policy. The control then forwards a sanitized request to the LLM or returns a block. The PII exposure rate in shadow AI breaches rose to 65% in the IBM Cost of Data Breach study, compared to 53% across all breaches. The gap is the prompt content the network DLP cannot read. AI-layer DLP closes that gap when the AI route is sanctioned and the gateway is in the path.
Related reading
- Shadow AI Monitoring: What You Can Actually See and Where the Inspection Layer Has To Sit
Most shadow AI monitoring stops at the DNS layer or the CASB. Both miss the actual data leaving the organization because the prompt is the data, and the prompt sits inside an encrypted POST body. This piece walks through the four monitoring layers, what each one sees, where each one is blind, and the inspection architecture that produces evidence an EU AI Act or HIPAA auditor will accept.
- 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).