The problems this exists to solve.
How it works for your team, day to day.
Inspection at the prompt, before the model
Prompt DLP evaluates the text itself — 40+ built-in classifiers for PII, PHI, payment data, credentials, and source code — inline at sub-38ms, before transmission. It reads fragments the way people actually leak data: a name, an SSN, six rows of a table inside a paragraph of context.
Redact by default, block when it matters
The default action is surgical: strip the sensitive field, let the task proceed. The employee gets their summary, the model never sees the raw value, and adoption survives because the tool keeps working. Hard blocks are reserved for the cases that deserve them.
Your data types, not just ours
Custom classifiers — regex, keyword, and ML — cover what generic packs can't: internal project codenames, proprietary schemas, customer-ID formats. They deploy through the same policy pipeline, versioned and staged like everything else.
The questions we hear most.
How is this different from our network DLP?
Network DLP inspects files and traffic patterns; Prompt DLP reads the prompt text at the application boundary, where fragments leak. They complement — this covers the layer yours structurally can't.
Can we detect our internal data formats?
Yes — custom classifiers for project names, ID schemas, and proprietary patterns deploy alongside the built-ins.
Does redaction break the user's task?
No — that's the point. The model receives masked values and completes the task; the employee usually can't tell anything was redacted.
What record exists of a redaction?
Every redaction logs the classifier fired, the field type, the policy applied, and the timestamp — exportable for SOC 2 or GDPR review.