Why Salus does not anonymise

Anonymisation solves a different problem

Anonymisation is the right tool when data will be released and never needs to point back at a person: research datasets, published statistics, long-term archives. Its defining property is that re-identification is no longer reasonably possible, for anyone, including you.

An AI workflow is the opposite situation. A support agent asking a model to summarise a complaint needs the answer to say which subscriber and which account, inside the perimeter, where that information is legitimate. If the pipeline anonymised the prompt, the answer would come back permanently incomplete, and no vault or key could fix it.

Reversible, but not casually reversible

“Reversible” describes the architecture, not the ease of access. Restoration requires three things that all live inside your environment: the vault holding the mapping, the vault key that decrypts it, and an API key in the right tenant with the recover_text permission. Every restoration is a logged security event. An external provider, or anyone without those three, holds tokens with no path back.

This is why the terminology matters. Calling reversible tokenisation “anonymisation” would claim a property the system deliberately does not have. The accurate frame: Salus tokenisation keeps detected sensitive values inside your perimeter while external models work with tokens, and supports pseudonymisation-style controls.

Where irreversibility still appears

Two mechanisms give you one-way behaviour where you want it. Protect without a context_id, and the tokens are ephemeral: nothing is stored and nothing can be restored, which suits classification and routing tasks. And a value that first appears in a model’s output is stored with restore disabled, so a provider cannot introduce a value and have it restored into your systems. Both are choices per workflow, not a global property of the pipeline.