The comparison#
| One-way masking / redaction | Salus tokenization | |
|---|---|---|
| Reversibility | None — information is destroyed | Full — vault restores values inside your perimeter |
| What the provider sees | Redaction markers | Typed tokens |
| Entity consistency | Lost — two redactions are indistinguishable | Preserved — same value, same token, per scope |
| Answer quality | Degraded — answers contain holes | Complete — real values restored in the answer |
| Streaming responses | Compatible (nothing to restore) | Compatible — streaming-safe inline restore |
| Category awareness | Usually lost | Kept — the token carries its data class |
| Audit trail | Redaction events | Tokenization and restore events, per value |
Why redaction fails AI workflows specifically#
Traditional DLP redaction was designed for documents at rest and email in flight — contexts where a blacked-out value is an acceptable loss. AI workflows are different: the value is often load-bearing for the task. A support summary with three indistinguishable [REDACTED] markers cannot say who complained about what. The user either gets a useless answer or retypes the prompt into an unprotected channel — which is exactly the shadow-AI behavior the control was meant to prevent.
Tokenization keeps the protective property — the provider receives no sensitive values — while removing the cost. The model reasons over stable, typed references, and the user reads an answer with the real values in place.
Where the terms get confusing#
Vendors use "masking" loosely, sometimes for reversible schemes. The distinction that matters is not the word but the property: can the original value be restored, inside your perimeter, after the AI has answered? If not, context is being destroyed on every request. Salus's masking is tokenization — reversible by design.
A related but separate question is how tokenization relates to pseudonymization in the GDPR sense — that one is legal terminology, covered in Tokenization vs. Pseudonymization.