Privacy and masking
Every AI call in FlowLakes, an agent run, a chat turn, or the memory index, goes through the privacy shield before anything leaves your tenant for a model or embedding provider. This page is about what the shield masks, what it does not, and who should turn it on first.
The three tiers
An administrator sets the tier on Admin → Data Map, under What the AI provider sees about your people. It applies tenant-wide.
| Tier | What happens |
|---|---|
| Off | The model sees records as they are, including the people a record points at and their email addresses. A name written into free text and a labelled secret are still masked. Off is a choice an administrator makes, and the platform audits it. |
| Identities | Every person is replaced by a stable handle before anything is sent to the model, and the handle is turned back into the real person when the model’s answer is applied. This covers people a record points at through a field, any field you classified yourself, and names, usernames and addresses of your own people written into free text. |
| Identities and values (the default for a new tenant) | Everything the previous tier covers, plus values that have a recognisable shape and belong to nobody in your directory: email addresses, bank account numbers, payment card numbers, phone numbers, and IP and MAC addresses written into descriptions and comments. |
A labelled secret (a password, a PIN, a CVV or a US social security number typed next to the word that names it) is withheld on every tier, including Off. A credential reaching a model provider is a different risk than a choice about people’s data, so it does not wait for the tier dial: only the field that held it is shown, the value itself never is.
Changing the tier is audited, and it queues your memory index for re-embedding: a vector built under one tier is in a different space from a query masked under another, so the platform clears the old vectors and rebuilds them in the background rather than leaving the mismatch to be discovered as quietly worse search results.
Person names in free text
A person’s name written into a description or a comment is masked on every tier, including Off, even when that person has no user record here: a contractor, an outside caller or a new hire not yet synced. The shield recognises a name by its shape: two or three capitalised words in a row (“Jonas Probewald”), with the particles van, von, de, der and zu between them (“Anna von Berg”), hyphenated surnames, and an honorific in front (Dr., Prof., Herr, Frau, Mr, Ms), which itself stays visible. A person your directory knows keeps their own handle; only a name that matches no user record becomes a hidden value.
Your own words are never treated as a name. The shield keeps a list of words that are not people, built for your tenant from your field labels, choice values, table names, team names and application names, plus a shipped list of common English and German words: days, months, greetings and product words such as Microsoft, Teams, Windows, Service, Desk or Incident. So “In Progress”, “Service Desk” or a team called “Network Ops” stay readable. A single capitalised word is never a name by itself, and neither is a word in capitals or a word with a digit in it. If that list cannot be built, the shield masks with the shipped words alone, so more is masked, not less.
The masked name is turned back into the real name where a tool needs it, for example a user search in Entra or Intune, exactly as a directory person is. What an agent writes down as evidence on a pursuit is stored with the handle, not the name.
This scan runs on every text field of a work record, your incidents,
requests, and tasks: a short field such as a summary or subject is scanned
exactly as a long one, because a name typed into either still identifies
someone. It skips a short field only on a configuration object, such as a
role, a rule, or an application: the name field of a role is text about
the configuration, not about a case, so a name-shaped value there (a role
genuinely called “Jan Berg’s team”) is left alone while a configuration
object’s own long description or notes field is still scanned. A value this
platform cannot place on a record at all is scanned, the safe side.
What is not masked today
- Names written in lower case or as one word. “please ask jonas” or a first name on its own is not recognised: the shield does not guess names from ordinary prose.
- Sensitive words. Health conditions, legal matters and similar free-text content are not detected or replaced.
- Host names, device models and serial numbers that identify what a thing is, not who it belongs to. An agent needs these to triage hardware. IP addresses and MAC addresses are masked at the Identities and values tier; a serial number or an asset tag is masked on an asset record specifically, as one of the declared fields below.
- Local phone numbers and most national identity numbers. Their formats differ by country and most carry no check digit, so the platform does not guess at them, with one exception: a US social security number is recognised by its shape and withheld on every tier. Classify a field that holds another country’s id and it is masked every time, wherever it appears.
- Dates.
- Images. A screenshot sent to a model is sent as it is; masking applies to text.
Asset and configuration records
Four fields on a CMDB asset (IP address, MAC address, serial number and asset tag) always leave as a handle, never the raw value, regardless of the tier. A tool that needs the real value for an outside system, such as an Intune or Entra lookup, still gets it: the platform resolves the handle back at that door. Four more fields (owner, assigned-to, support group and managed-by group) always leave as a reference handle. Purchase cost is withheld entirely. A host name, a device model, a manufacturer and a status stay visible, because an agent that cannot read these cannot triage a device.
None of this changes what is stored in FlowLakes, with one exception: the evidence an agent files on a pursuit is stored masked, as described above. Masking happens only on the copy sent to a provider, and if the masking service itself is unavailable, the call is refused rather than sent unmasked.
Who is covered today
Internal IT service desks are covered as they are. The default tier masks the people your own directory knows about and the recognisable values written into tickets, which is the shape of an internal support queue.
A requester’s conversation with the Service Hub assistant goes to the model provider through this same shield, under the tenant’s masking tier, like every other AI call.
HR, healthcare and public support desks should not rely on it yet. They routinely name people outside the directory (a candidate, a patient, a member of the public), whose names are masked only when written as a name (see above), and sensitive words, which are not masked yet. The default masks the people and values already covered and leaves the rest exposed in the same way as before.
Moving every tenant onto this
A tenant installed before the default moved was never asked, so its tier is explicitly what it was reading at the time: off for a tenant installed before 2026-09-21, identities for one installed between then and 2026-10-10. An operator-run script moves every such tenant up to the default tier, audited, and queues each one’s memory for re-embedding through the same path a manual tier change does. It is run deliberately, tenant by tenant, never silently.
How it connects
- Set the tier on Admin → Data Map.
- See which model providers exist and whose key pays for the call in AI models and provider keys.
- Agent tool permissions, a separate question from what a provider may see, are covered in the safety model.