Transformers
Each data instance in the sample configuration uses a different transformer technique. The values below are real output from a Protect call as the HR Specialist role.
AES deterministic encryption: (employees, first_name)
Deterministic encryption always maps the same input to the same ciphertext, so equality checks, joins, and uniqueness constraints keep working on protected data.
| Cleartext | Protected |
|---|---|
Laura | EgkCwvPv4cZJ6ECAzG6zKQ== |
Order-preserving tokenization: (employees, last_name)
Order-preserving tokenization replaces the value with a short token while still letting the engine search over protected data.
| Cleartext | Protected |
|---|---|
Smith | 5GVVTV8-AB |
To find a record without exposing cleartext, run a Search (action: search) on the value you are looking for. The engine returns a search token that you match against the stored protected column. Partial inputs produce a prefix token, so a begins-with lookup works too:
| Search input | Search token |
|---|---|
Smi | 5GV |
Email tokenization: (employees, email)
Email tokenization replaces the local part with a token while preserving the @domain, so the result is still a syntactically valid email.
| Cleartext | Protected |
|---|---|
laura.smith@company.com | 7d7341c0-6941-3f60-baf9-ffcc6c18eead@company.com |
IBAN format tokenization: (salaries, iban)
Format-preserving tokenization replaces an IBAN with a tokenized IBAN of the same structure, so length and format validation keep working downstream.
| Cleartext | Protected |
|---|---|
CH9300762011623852957 | ZW0556459705462108999 |