Every tool that protects AI traffic has to decide what to do with a name once it has found it. There are three honest answers, and the one a vendor picks tells you what they think the AI is for.
Three ways to handle the same request
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 stops the prompt. The model receives nothing, the colleague gets a policy message, and the data is safe. It is also the moment the work moves to a personal account on a phone, where nothing protects it at all. Blocking is the right default for a payment card number, which no assistant needs. It is the wrong default for a name.
Redact replaces each value with a blank or a fixed placeholder. 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 comes back safe and has to be rebuilt by hand. Most AI security gateways do this, and it is why their users describe the protection as something to work around.
Tokenise replaces each value with a typed, consistent token: [PERSON_81af3c] for Maria and [PERSON_5b90da] for Erik. The model sees that there are two distinct people, one of whom missed payments, and addresses the letter to the first token. On the way back, inside the customer’s network, the token becomes “Maria Sandoval” again. The answer arrives ready to send.
What makes a token useful
Three properties do the work.
Typed. The token says what kind of thing it replaced. A model that sees [IBAN_c412e8] knows to treat it as an account and not as a sentence fragment. It will put it in the right place in a refund confirmation and will not try to reason about its digits.
Consistent. The same person gets the same token for the whole case, across messages, attachments and batch rows. This is what lets the model follow who did what. It is also the property that one-way masking cannot have, because a mask has no memory.
Opaque. The token carries no information about the value. Nothing about 81af3c reveals a name, a length or a first letter. The mapping lives in the customer’s own context store, scoped to the case, and is destroyed when the case closes.
What it costs
Tokenisation is not free, and a vendor who says otherwise is not telling you about the trade.
A context store. Restoration needs the mapping from token to value, so something inside the perimeter has to hold it for the life of the case. In Salus that is the customer’s own PostgreSQL, under a key the customer holds. There is no Salus-side copy.
A restore step. The answer has to pass back through the same layer before anyone reads it. In an application you build, that is one call. In a gateway, it is a streaming stage. On an endpoint, it is the same component that protected the input.
Authorisation. Restoring a value is a privilege. The person who reads the restored answer must be the person entitled to see the original, and the audit log must record that it happened, without reprinting the value. A system that restores for anyone who asks has only moved the leak.
When masking is still right
Two cases.
The first is a value no assistant should ever need. Payment card numbers are the clear example, and the Salus default for them is to stop the request rather than tokenise it, unless the tenant decides otherwise.
The second is a disclosure rather than a value. “The customer is pregnant” is not an identifier that can be swapped and swapped back. A token for it would still tell the model that this person has a health fact, which is the association the law is protecting. That is why Salus’s semantic layer, which is separate and optional, works on stated disclosures with a different treatment, and why tokenisation is the right tool for identifiers and not for everything.
The short version
Blocking keeps data safe and loses the work. Masking keeps data safe and loses the answer. Tokenisation keeps data safe and keeps the answer, at the price of a context store, a restore step and an authorisation model, all of which belong inside the customer’s perimeter. If a vendor cannot show you the restore step, they are masking.