Tokenisation versus masking
Why reversible tokens beat one-way redaction for AI workflows.
Take a request a collections team might type into an assistant:
Maria Sandoval missed three payments. Her guarantor Erik Lindqvist missed none. Draft a reminder letter to the right person.
Block. The model receives nothing. The colleague gets a policy message, and the work moves to a personal account where nothing protects it.
Redact. The model receives “▮▮▮ missed three payments. Her guarantor ▮▮▮ missed none.” It writes a letter addressed to nobody, and it cannot tell which of the two people the letter is for, because both became the same blank. The answer is safe and has to be rebuilt by hand.
Tokenise. The model receives “PERSON_kxmrqa missed three payments. Her guarantor PERSON_tzrwlo missed none.” It sees two distinct people, addresses the letter to the first token, and inside your network that token becomes Maria Sandoval again. The answer arrives ready to send.
The comparison
| One-way masking | Salus tokenisation | |
|---|---|---|
| Reversibility | None, information is destroyed | Full, inside your perimeter |
| What the provider sees | Redaction markers | Typed tokens |
| Entity consistency | Lost, two redactions are indistinguishable | Preserved, same value, same token, per context |
| Answer quality | Degraded, answers contain holes | Complete, real values restored |
| Class awareness | Usually lost | Kept, the token carries its class |
| Audit trail | Redaction events | Detection and restore events, per request |
Why redaction fails AI workflows specifically
Traditional DLP redaction was designed for documents at rest and email in flight, 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 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 behaviour the control was meant to prevent.
Tokenisation keeps the protective property, the provider receives no sensitive value, while removing the cost.
Where the terms get confusing
Vendors use “masking” loosely, sometimes for reversible schemes. The distinction that matters is the property, not the word: can the original value be restored, inside your perimeter, after the AI has answered? If not, context is destroyed on every request. How tokenisation relates to pseudonymisation in the legal sense is a separate question, covered in Tokenisation versus pseudonymisation.
All example values in this documentation are synthetic.