Skip to main content

​
DLP scanner — data classes & strict mode

The outbound message scanner runs on every channel (SMS, MMS, WhatsApp, email, RCS, and IM routes) and flags regulated identifiers in a message body before it dispatches. This page covers the data classes it detects, why its false-positive rate is deliberately low, how a finding becomes a send gate, and how it differs from the transcript scrubber that strips personal data out of stored agent conversations.
The scanner is a tenant-owned control. Its categories and response mode are scoped to your organization, and on a send the policy enforcement mode you picked (warn, strict, or off) decides what a finding does. HIPAA and PCI-DSS define the obligation; this control is one way to enforce part of it on the message lane.

​
What the scanner detects

Four categories ship, each built to avoid false positives: The default set is credit_card, ssn, and iban — the payment and identity data most likely to put a message outside PCI, HIPAA, or GDPR policy. passport is added on request. You keep the default unless you opt into passport or narrow the set for a conversation you have already vetted.

​
Why checksum validation matters for a strict-mode organization

strict mode turns every scanner block verdict into a refused send. A loose detector would take legitimate messages down with it. Every category above validates a candidate twice — shape, then checksum or the registry ranges — before it counts, so grouped digits, order ids, and tracking codes don’t trip the gate. The one class that shape alone can’t pin (a bare alphanumeric token) is kept out of the default set entirely rather than risked on vague matching. This is why strict is safe to leave on for the whole workspace: the scanner refuses actual card/identity data, not numerals or account-shaped strings.

​
How a finding becomes the verdict

The DLP rule rolls its hits up through the policy scanner, the pre-send gate that also checks TCPA quiet hours, SHAFT content, spam keywords, opt-out phrasing, and country sender rules. All channels run it, because a card number is sensitive on SMS, WhatsApp, email, and RCS alike. The scanner emits a dlp violation on a hit, and in its default block mode the violation raises the verdict to block. What happens next depends on two settings:
  • Your organization’s policy enforcement mode (the warn / strict / off switch covered in the policy scanner page): in warn (default) the send proceeds and the finding is recorded; in strict it is refused with POLICY_VIOLATION.
  • The DLP category mode (block / redact / warn / off): block (default) raises the block verdict; warn flags without raising the verdict; redact strips the sensitive value before dispatch as a flagged send; off turns the DLP check out for your organization.
The DLP scanner ships as the dlp-scanner module in the @devotel/compliance package; the send-path verdict comes from the sibling policy scanner that folds every rule into one outcome.

​
Privacy posture

A finding tells you where and what, not the matched value. Each hit carries a character span (start and end offsets) and a category label only — the scanner never returns the offending text. The same is true when you run redact: matched spans are substituted with typed sentinel tokens ([REDACTED_CARD], [REDACTED_SSN], [REDACTED_IBAN], [REDACTED_PASSPORT]). The detector therefore can’t leak a card or identity number into logs, response headers, or the audit trail, and it stays safe to run on every send and on every keystroke of the compose-time linter.

​
Putting it to work

Enable a category. By default the floor is credit_card, ssn, iban. A HIPAA tenant that collects identity documents can opt into passport; a PCI tenant who has already vetted a lane can reduce the categories to exactly the cards and accounts its policies allow. The scanner accepts only the four shipped categories. Compose a clean message. A marketing body must not carry a PAN. When a customer’s payment or identity data is pasted in, the pre-send POST /api/v1/messages/lint call flags it as block before anything dispatches, so the author rewrites the body. In strict mode the same refusal comes back on the send call itself, so the message never got sent. Live linting and agent drafts. The agent or dashboard compose UI calls /messages/lint debounced as text is typed, and gets the same verdict and violations back without sending anything. An AI agent draft goes through the same call, so a generated card or identity number is caught before it ever reaches a customer.

​
DLP vs. the transcript scrubber

The DLP scanner is a send gate: it refuses or flags regulated data at send time. The transcript scrubber (@devotel/shared/utils/pii, the redactPii family) is a storage gate: it strips personal data from agent conversation transcripts as they are inserted so the stored record never holds the original text. The tradeoffs differ with the job:
  • The transcript scrubber is destructive — the original text is gone from the stored row — so it tolerates some false positives rather than hold up a conversation write.
  • The DLP send gate must stay precise and auditable, so it validates twice and keeps the scan synchronous and offset-only; an AI agent or customer gets a block/warn verdict it can act on, not a silent rewrite.
Use both: the transcript scrubber keeps stored agent conversations clean, and the DLP rule stops regulated data from leaving in the first place. The two scopes meet only inside the scanner’s send-path verdict.