Data protection

Detection modes, the 60-detector library, entity detection, the model notice, and retention.

Data protection runs on every request before dispatch. The default mode is tokenize: every detected value is swapped for a stable typed token like «EMAIL_1». Only tokens reach the provider, and the response is restored to the real values on its way back to you, streamed or not. The token map lives in memory for the life of the request and is never persisted.

# tokenize mode (the default): what you send
curl https://api.sluis.ai/v1/chat/completions \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "model": "sluis/auto", "messages": [{ "role": "user",
        "content": "Mail j.devries@acme.nl that IBAN NL91ABNA0417164300 is active." }] }'

# what the model provider receives — only stable typed tokens
{ "role": "user",
  "content": "Mail «EMAIL_1» that IBAN «IBAN_1» is active." }

# what you get back — restored at the single client egress, streaming included
{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "Draft: Dear j.devries@acme.nl, your account NL91ABNA0417164300 is active…"
    }
  }]
}

Other modes: mask rewrites detected values irreversibly, block refuses the request with 422, and allow_log passes it through while flagging the audit row.

60 built-in detectors ship out of the box: 28 for personal data, from the US Social Security number to a national-ID pack that checksum-validates 12 EU countries, and 32 for secrets and credentials. Each one can be toggled per organisation, and custom terms (plain or regex) cover anything specific to your business:

Entity detection

Persons, organizations and locations are hard to catch by pattern alone. Sluis adds four opt-in layers: context heuristics (honorifics, salutations, signatures; persons only), email correlation (derives names from addresses in the same text), a tenant name directory, and NER: a multilingual recognition model that ships inside the deployment (spaCy xx_ent_wiki_sm weights, operated by Sluis as a network-internal sidecar), so text never leaves your perimeter to be scanned. NER finds persons, organizations and locations in plain prose.

Model notice

When tokenization rewrote a request, Sluis injects a leading system message telling the model the «…» tokens are opaque placeholders it must keep intact; that is what keeps the restore reliable. On by default; customise or disable it per organisation.

Retention & audit fidelity

Content retention (request and response bodies for the audit log) is on by default and encrypted at rest; audit fidelity chooses whether retained content stores the tokens or the original values. Turn retention off for a metadata-only ledger; that also disables the response caches.

Document anonymization

Send a docx, pdf, image, or text file to POST /v1/documents/anonymize and the same document comes back with PII and secrets replaced by merge tags like «PERSON_NAME_1» in text, and blurred out of images and PDF pages. Processing is local to the gateway, OCR included; the operation is sealed in the audit chain and metered per page/image. The token mapping is returned only when you ask for it and never stored. Redacted PDFs keep an invisible searchable text layer built from the anonymized text. For large documents, enqueue an async job and collect the result later via a time-limited signed URL.

The same protection works in transit: with the dlp_documents policy on, files uploaded through /v1/files and inline OCR documents are anonymized before they leave toward a provider, refused under block, and scanned under allow_log.

# enqueue a large document (202 + job id; Idempotency-Key honoured)
curl https://api.sluis.ai/v1/documents/anonymize/jobs \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -F file=@archive.pdf

# poll until succeeded; the signed download_url then needs no API key
curl https://api.sluis.ai/v1/documents/anonymize/jobs/9c31… \
  -H "Authorization: Bearer $SLUIS_KEY"

{
  "id": "9c31…",
  "state": "succeeded",
  "filename": "archive.pdf",
  "summary": { "pages": 12, "images": 3, "categories": ["PERSON_NAME", "EMAIL"], "downgraded": false },
  "download_url": "https://api.sluis.ai/v1/documents/deliverables/9c31…?tenant=…&exp=…&sig=…"
}

Embeddings

Pseudonymized tokens are stable within one request, not across requests, so embeddings of tokenized text may not match between calls. The dlp_embeddings policy setting controls whether the scan covers /v1/embeddings: it is on by default, and setting it to off sends embedding inputs to the provider unscanned. Every exempted call is recorded in the audit trail.

Per-key overrides

An owner or admin can mint an API key with allow_dlp_override. Requests with such a key may override the organisation's data-protection mode for that one call via the x-sluis-dlp header: off, allow_log, mask, block or tokenize.

# a key minted with allow_dlp_override may swap the mode for one call
curl https://api.sluis.ai/v1/embeddings \
  -H "Authorization: Bearer $SLUIS_KEY" \
  -H "x-sluis-dlp: off" \
  -H "Content-Type: application/json" \
  -d '{ "model": "mistral/mistral-embed", "input": "raw text, embedded verbatim" }'
# keys without the grant get 403; every override is sealed in the audit trail

A key without the grant gets a 403 when it sends the header, and that refusal is sealed in the audit trail too. Every override in effect is disclosed on the sealed audit row, so the trail always shows which mode actually ran.